[Firewall] Unwanted NAT on OpenVPN connection

Lonnie Abelbeck lists at lonnie.abelbeck.com
Thu Oct 13 21:31:27 CEST 2016


HI Sebastian, inline comments...

On Oct 13, 2016, at 1:09 PM, Sebastian Suchanek <sebastian.suchanek at gmx.de> wrote:

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

Ahhh, this is a remote subnet via OpenVPN.  Then 10.2.0.0/16 should not be part of INTERNAL_NET on the server, instead define it using "ccd" files in OpenVPN so it is routed ...

In this case on your OpenVPN server I'd suggest:
--
client-config-dir /etc/openvpn/ccd"
route-gateway 10.255.1.1
route 10.2.0.0 255.255.0.0
--

Then assuming the remote OpenVPN client's certificate CommonName is "remote1" create the file "/etc/openvpn/ccd/remote1" with:
--
iroute 10.2.0.0 255.255.0.0
--

BTW, I use "topology subnet".


> 
> 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"
> | [...]

That looks the same as you had before. ??

On the remote "remote1" OpenVPN client side INTERNAL_NET can contain 10.2.0.0/16, but not on the OpenVPN server side.

Lonnie



> 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
> 
> _______________________________________________
> Firewall mailing list
> Firewall at rocky.eld.leidenuniv.nl
> http://rocky.eld.leidenuniv.nl/mailman/listinfo/firewall
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl



More information about the Firewall mailing list