Another roaming problem

[Toke Høiland-Jørgensen]

"Jason A. Donenfeld" <Jason at zx2c4.com> writes:

> On Thu, Mar 8, 2018 at 5:59 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> and so I wonder if a simpler solution would also
>>>involve NAT -- namely, configuring "hair pin" NAT?
>>
>> What's that?
>
> It's the terrible vendor term for hitting the gateway through one of
> its IPs (say, the public one) and having it forward packets for you to
> another machine on the same LAN. The idea here, being, you'd get to
> keep using the same IP address for communicating, even when you're
> behind NAT in the private network. (This seems to work well for me at
> my house.)
>
> Wikipedia describes it in terms of the p2p discovery issue, which is
> slightly different, but still the same underlying concept:
> https://en.wikipedia.org/wiki/Hairpinning

Ah, right. In that case I think I probably didn't explain my setup well
enough. Let me try again:


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...

This is all orthogonal to NAT, as far as I can tell :)

-Toke