bind to specific ip address

bind to specific ip address

[Bryce Allen]

Hi,

I have run into several wifi networks that block almost all traffic,
allowing only 80/443 and 53. To work around this, I got a second IP
address for my linode server, intending to run ssh on port 80 and
wireguard on 53. This works for ssh, which I set up to bind on port 80
to the new IP only, so it doesn't interfere with nginx on my main IP.

It looks like wireguard doesn't support binding to a specific address?
I understand the security and routing do not require binding to a
specific address, but I think it is useful for scenarios like this.
When I try to bring up the wg interface with ListenPort 53 in my
config, with unbound already running on 53 at other addresses, I get
"RTNETLINK answers: Address already in use\nFailed to bring up
wg-server.". The interface is still created, but the tunnel doesn't
work. I also had to manually delete the interface with "ip link del
wg-server" before I could bring it back up with the config changed back
to the original port.

I'm guessing that doing deep packet inspecion is too expensive /
overkill for a mall wifi, so I do think this workaround of using
port 53 would work. Is this address binding a feature that you would
consider adding to wireguard, or would accept a patch for? Any other
ideas for working around obnoxious firewalls?

Thanks,
Bryce
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: bind to specific ip address

[Ivan Labáth]

Hi,

as has been noted on a thread by Tomas Herceg on 2018-06-22,
a workaround is to internally listen on a different port,
and use NAT so it appears as the desired port on the outside.

If you really wanted to, with some iptables magic (e.g. u32 match),
you could match and split wireguard traffic from normal dns traffic,
all on a single ip.


While Jason says the behaviour is by design, I would like to note
that there are legitimate use cases for listening only on specific
interfaces/IPs and (at least I) would expect such functionality
from serious server software.

Mentioned multiple services on different IPs requiring use of NAT
scenario is a good use case.

An undesired effect might be, for instance, if a server is serving
a wireguard tunnel on a specific ip, a potentially malicious peer
could use wireguard to confirm ownership of different IP on the
same server, or confirm server's access to a different network.
Also, faults and/or transient states could lead wireguard to
inadvertently leak other IPs to the peers, leak presence of wg
tunnels to other networks, or divert the path of wireguard
connection to an alternate path even when policy says it shouldn't.

A malicious network operator might even try delaying/dropping
initiation (or rather rekey) packets, forwarding them to different
IPs with possibly spoofed headers and use it to .. de-anonymize?

A properly configured firewall should filter all these undesired
packets and avoid the effects, but it rarely is.

Regards,
Ivan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard