[Firewall] Unwanted NAT on OpenVPN connection
sebastian.suchanek at gmx.de
Thu Oct 13 20:09:36 CEST 2016
Am 12.10.2016 um 22:26 schrieb Lonnie Abelbeck:
first of all, thank you for your reply!
>> INT_IF="eth0 tun0"
>> INTERNAL_NET="10.1.0.0/16 10.2.0.0/16 10.255.1.0/24"
> I'm a little puzzled why you have three subnets off two interfaces, how is 10.2.0.0/16 attached to the interfaces ?
- 10.1.0.0/16 is the LAN physically connected to the server.
- 10.255.1.0/24 is the internal transfer net of the OpenVPN system.
(In case you're not familiar with OpenVPN: it uses an internal
transfer net with its own IP range to route traffic from one VPN peer
to another. Usually, this is transparent to the routed traffic.)
- 10.2.0.0/16 is a LAN a second location which is connected via an
OpenVPN connection. So far, this is the only remote LAN, but more
might follow in the future.
But inspired by your question, I've just changed my configuration to
| INTERNAL_NET="10.1.0.0/16 10.2.0.0/16 10.255.1.0/24"
It seems that the NAT'ing of accesses from the remote 10.2.0.0/16 LAN to
the local 10.1.0.0/16 LAN is gone now, but so far I'm not yet sure for
the opposite direction. Hopefully I can test this in more depth during
the upcoming weekend...
> If the 10.255.1.0/24 OpenVPN traffic is directly routed to the 10.1.0.0/16 LAN, you should not see any NAT'ing.
Yes, it is:
| # ip route
| default dev ppp0 scope link
| 10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.0.1
| 10.2.0.0/16 via 10.255.1.2 dev tun0
| 10.255.1.0/24 via 10.255.1.2 dev tun0
| 10.255.1.2 dev tun0 proto kernel scope link src 10.255.1.1
| 188.8.131.52 dev ppp0 proto kernel scope link src 184.108.40.206
> A traceroute from LAN(eth0) to LAN(tun0) and reverse may be useful.
No problem - accessing a host in local LAN from the remote LAN:
| # traceroute 10.1.7.3
| traceroute to 10.1.7.3 (10.1.7.3), 30 hops max, 60 byte packets
| 1 10.255.1.1 (10.255.1.1) 31.123 ms 40.863 ms 40.609 ms
| 2 10.1.7.3 (10.1.7.3) 39.872 ms 38.872 ms 38.194 ms
And vice versa:
| # traceroute 10.2.0.1
| traceroute to 10.2.0.1 (10.2.0.1), 30 hops max, 60 byte packets
| 1 10.255.1.6 (10.255.1.6) 33.087 ms 34.516 ms 35.437 ms
| 2 10.2.0.1 (10.2.0.1) 38.277 ms 39.985 ms 43.189 ms
> Also, suggestion ...
>> TRUSTED_IF="eth0 tun0"
> Instead I would use:
> IF_TRUSTS="eth0 tun0"
> This should not be a functional change for your case, but should you
> add additional interfaces, additional OpenVPN tunnels, VLAN's or such
> the IF_TRUSTS variable is a better (more precise) choice.
Thanks for the hint, I'll keep that in mind.
More information about the Firewall