[eduVPN-deploy] different IPs for client traffic/mgmt: one issue

Stefan Winter stefan.winter at restena.lu
Fri Aug 21 11:19:07 CEST 2020


Hi,


> I'd recommend making the default gateway the interface where you NAT
> over. The management interface can be separate without default gateway
> as mentioned before. Then everything will just automatically work as
> far as I can see.


Following your initial advice, that is actually what I did.


> Is there any reason why you make it more complicated then it needs to
> be? Maybe I am missing some (deployment) requirements on your end?


I'm not trying to be complicated :-)


After thinking about this for a bit, I guess my issue is that the DNS
name still points to the IP address of eno1, the management NIC that
doesn't have a default gateway.


I initially thought that's good - it makes eno2 a pure "data plane"
interface with VPN payload traffic. While the "control plane" of
actually establishing the session is on the management(y) side.


But with routing in mind, the more I think about this, this is probably
rubbish. I'll change the DNS name to eno2, which is then on the default
gw interface, and I guess then things are going to come back to normal.


I'll do that change today and will see next week when all TTLs in DNS
have expired.


Greetings,


Stefan


>
>> So, it appears like the server chooses to send its reply from the wrong
>> source interface - incoming to eno1 IP address; outgoing via eno2's IP
>> address. (see tcpdump at end)
>
> This can be mitigated by following the above. There are some hacks
> that can be implemented in OpenVPN, i.e. binding to a specific IP
> address, or hacking the server config with `--multihome` option. That
> last thing is not supported through eduVPN because we never needed it
> and probably indicates something you shouldn't be doing in the first
> place. However, as said above, maybe I am missing some requirements on
> your end...
>
> Cheers,
> François



More information about the eduVPN-deploy mailing list