[Firewall] Unwanted NAT on OpenVPN connection

Sebastian Suchanek sebastian.suchanek at gmx.de
Thu Oct 13 20:09:36 CEST 2016


Am 12.10.2016 um 22:26 schrieb Lonnie Abelbeck:

Hi Lonnie,

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
| 87.186.224.164 dev ppp0  proto kernel  scope link  src 84.160.228.198
| #

> 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"
>> IF_TRUSTS=""
> 
> Instead I would use:
> --
> TRUSTED_IF=""
> 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.


Best regards

Sebastian



More information about the Firewall mailing list