Another roaming problem

[Toke Høiland-Jørgensen]

On 8 March 2018 18:39:15 CET, "Jason A. Donenfeld" <Jason at zx2c4.com> wrote:
>Hi Toke,
>
>On Thu, Mar 8, 2018 at 6:23 PM, Toke Høiland-Jørgensen <toke at toke.dk>
>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 at 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 at thinkpad ~ $ ip link set wwan0 down
>zx2c4 at thinkpad ~ $ ip link set wlan0 up
>zx2c4 at 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 at 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