On 8 March 2018 18:39:15 CET, "Jason A. Donenfeld" <[email protected]> wrote: >Hi Toke, > >On Thu, Mar 8, 2018 at 6:23 PM, Toke Høiland-Jørgensen <[email protected]> >wrote: >> >> I have a gateway device with two interfaces, one public and one >private. >> This device performs NAT, and is also the one running wireguard (as >the >> 'server'). The client roams. So I have two cases: >> >> >> C (public IP) --- (public IP) GW (private IP) -- [LAN] >> >> In this case, C talks to GW on GWs public IP; everything works fine. >> >> Second case: >> >> [internet] --- (public IP) GW (private IP) -- [LAN] -- C (private IP) >> >> Here, C talks to GW; it still tries to send packets to the public IP >of >> GW (because that is what it's configured to do), but because GW sees >> that the source IP is on its internal subnet, it replies with a >source >> address in the private subnet. This works fine as long as the client >is >> on the LAN; but once it roams outside, it now thinks that the >wireguard >> server lives on the private IP of the GW, which is obviously can't >reach >> from its shiny new public IP. >> >> So what I'd want to happen is that GW should keep using its public >> IP as the source of the wireguard packets, even when talking to a >client >> on a directly-connected internal subnet. Or, alternatively, that C >> should ignore the source address change of the packets coming from GW >> and keep sending its packets to the public IP it was first configured >to >> use... >> > >In this case, WireGuard is indeed supposed to make the right decision. >Namely, it should continue replying using the correct source address. >It's not supposed to switch to the internal one. I have the exact same >setup at home, so I just tried things out again to verify, and from my >end it seems to be working fine: > >zx2c4@thinkpad ~ $ wg >interface: martino > public key: 4HUj8boJyeZI70WVxmKhHfGAohtoyFQpWk96OpuFcVY= > private key: (hidden) > listening port: 53249 > fwmark: 0xca6c > >peer: GMvmorUa9WzHAkOVOxQKSrw3F1JruA4bTN1NkWN0T3E= > preshared key: (hidden) > endpoint: 129.228.12.33:10000 > allowed ips: 0.0.0.0/0, ::/0 > latest handshake: 48 seconds ago > transfer: 1.06 KiB received, 19.50 KiB sent >zx2c4@thinkpad ~ $ ip link set wwan0 down >zx2c4@thinkpad ~ $ ip link set wlan0 up >zx2c4@thinkpad ~ $ pingg >PING google.com (172.217.19.142) 56(84) bytes of data. >64 bytes from mrs08s04-in-f14.1e100.net (172.217.19.142): icmp_seq=1 >ttl=53 time=20.1 ms >64 bytes from mrs08s04-in-f14.1e100.net (172.217.19.142): icmp_seq=2 >ttl=53 time=19.1 ms >^C >--- google.com ping statistics --- >2 packets transmitted, 2 received, 0% packet loss, time 1001ms >rtt min/avg/max/mdev = 19.181/19.666/20.151/0.485 ms >zx2c4@thinkpad ~ $ wg >interface: martino > public key: 4HUj8boJyeZI70WVxmKhHfGAohtoyFQpWk96OpuFcVY= > private key: (hidden) > listening port: 53249 > fwmark: 0xca6c > >peer: GMvmorUa9WzHAkOVOxQKSrw3F1JruA4bTN1NkWN0T3E= > preshared key: (hidden) > endpoint: 129.228.12.33:10000 > allowed ips: 0.0.0.0/0, ::/0 > latest handshake: 5 seconds ago > transfer: 113.70 KiB received, 85.43 KiB sent > >I wonder what might be different about your configuration...
Well, I do generally setup routing in a somewhat unusual manner. I can try to capture some packet dumps tomorrow to poke into it a bit more. Anything in particular I should look for? -Toke _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
