MASQUERADE/SNAT before IPsec

MASQUERADE/SNAT before IPsec

[RUMI Szabolcs]

Hello!

I'm trying to achieve the following:

I would like to connect a LAN behind a NAT gateway to an IPsec VPN.
The IPsec VPN gets connected to via IPsec tunnelmode by the NAT
gateway that is getting a single dynamic IP address valid on the
VPN and this is what the LAN machines had to be MASQUERADEd to.

On the NAT gateway a WAN address is assigned to eth0 and the
dynamic IPsec VPN address is assigned to eth0:0. I can ping hosts
on the IPsec VPN through the tunnel from the NAT gateway itself
but I cannot ping them from any LAN hosts behind the gateway.

The problem is that when I set up proper FORWARD and MASQUERADE rules
for the LAN network, the MASQUERADEd packets seem to go out on eth0
unencrypted without ever getting into the IPsec tunnel. I have also
tried -j SNAT --to-source <address of eth0:0 valid on IPsec VPN>
just to be sure and the same thing happens as with MASQUERADE.

Environment: linux-2.6.22, iptables-1.3.8

Is this behaviour intentional?
How could I achieve what I described above?

Thanks in advance!

Best regards,
Sab

Re: MASQUERADE/SNAT before IPsec

[RUMI Szabolcs]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Sat, 2 Feb 2008 22:42:57 +0100
"Marco Berizzi" <pupilla@hotmail.com> wrote:

> RUMI Szabolcs wrote:
> 
> > Hello!
> > 
> > I'm trying to achieve the following:
> > 
> > I would like to connect a LAN behind a NAT gateway to an IPsec VPN.
> > The IPsec VPN gets connected to via IPsec tunnelmode by the NAT
> > gateway that is getting a single dynamic IP address valid on the
> > VPN and this is what the LAN machines had to be MASQUERADEd to.
> > 
> > On the NAT gateway a WAN address is assigned to eth0 and the
> > dynamic IPsec VPN address is assigned to eth0:0. I can ping hosts
> > on the IPsec VPN through the tunnel from the NAT gateway itself
> > but I cannot ping them from any LAN hosts behind the gateway.
> > 
> > The problem is that when I set up proper FORWARD and MASQUERADE
> > rules for the LAN network, the MASQUERADEd packets seem to go out
> > on eth0 unencrypted without ever getting into the IPsec tunnel. I
> > have also tried -j SNAT --to-source <address of eth0:0 valid on
> > IPsec VPN> just to be sure and the same thing happens as with
> > MASQUERADE.
> > 
> > Environment: linux-2.6.22, iptables-1.3.8
> > 
> > Is this behaviour intentional?
> > How could I achieve what I described above?
> 
> may draw your network schema?

Well the actual setup is much more complicated but I tried
to simplify and visualize the problem (see attached image).
The green arrows show where the NATed traffic should go and
the red ones show what actually happens.

Best regards,
Sab

[-- Attachment #2: ipsec_nat_2.png --]
[-- Type: image/png, Size: 20945 bytes --]

Re: MASQUERADE/SNAT before IPsec

[Marco Berizzi]

RUMI Szabolcs wrote:

> Well the actual setup is much more complicated but I tried
> to simplify and visualize the problem (see attached image).
> The green arrows show where the NATed traffic should go and
> the red ones show what actually happens.

please post your iptables rules and the 'ip -s x p' output.

Re: MASQUERADE/SNAT before IPsec

[RUMI Szabolcs]

On Sun, 3 Feb 2008 14:18:12 +0100
"Marco Berizzi" <pupilla@hotmail.com> wrote:

> RUMI Szabolcs wrote:
> 
> > Well the actual setup is much more complicated but I tried
> > to simplify and visualize the problem (see attached image).
> > The green arrows show where the NATed traffic should go and
> > the red ones show what actually happens.
> 
> please post your iptables rules and the 'ip -s x p' output.

Well, this is a corporate production system so everything is a
bit more complicated as if it were just a testbed machine...
But here are the relevant rules:

iptables -A INPUT -i eth+ -s "!" $MYIP -p ah -j ACCEPT
iptables -A INPUT -i eth+ -s "!" $MYIP -p esp -j ACCEPT
iptables -A OUTPUT -o eth+ -s $MYIP -p ah -j ACCEPT
iptables -A OUTPUT -o eth+ -s $MYIP -p esp -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/8 -i "!" eth+ -d 164.99.192.0/22 -j ACCEPT
iptables -A FORWARD -d 10.0.0.0/8 -o "!" eth+ -s 164.99.192.0/22 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -d 164.99.192.0/22 -j SNAT --to-source 164.99.195.8

$MYIP is the static IPv4 WAN address of the server.

The IP address in --to-source 164.99.195.8  is the one that was
dynamically allocated by the remote corporate VPN concentrator
(not under my control) at the time I've tested the setup.
I've also tried -j MASQUERADE with the same result (would be more
appropriate than SNAT as the address is dynamically allocated).

The -i/-o "!" eth+ rules are there because the 10.0.0.0/8 network
is actually not connected through eth1 as pictured in my drawing
but through our own VPN whose traffic comes in on tap+ devices.

I cannot make an iproute2 dump because I'm using the oldskool
net-tools and RTNETLINK is not compiled in the kernel. Static
routes for networks available through the remote corporate VPN
are added like that:

route add -net a.b.c.d/m dev eth0:0

where eth0:0 is configured to 164.99.195.8/22 via ifconfig in
this particular case.

This setup does work in terms that from the server I can ping
and reach any host on the corporate VPN. The problem seems to
be that after a packet comes in from our own VPN (10.0.0.0/8)
and goes through iptables and gets NATed in the POSTROUTING
chain it goes straight out to eth0 and it does not get
reevaluated whether it should be handled by IPsec.

Thanks!

Best regards,
Sab

Re: MASQUERADE/SNAT before IPsec

[Marco Berizzi]

RUMI Szabolcs wrote:

> iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -d 164.99.192.0/22 -j
SNAT --to-source 164.99.195.8

> The IP address in --to-source 164.99.195.8  is the one that was
> dynamically allocated by the remote corporate VPN concentrator
> (not under my control) at the time I've tested the setup.

> I cannot make an iproute2 dump because I'm using the oldskool

which ike/ipsec implementation are you using?

> and goes through iptables and gets NATed in the POSTROUTING
> chain it goes straight out to eth0 and it does not get
> reevaluated whether it should be handled by IPsec.

mhhh which kernel version?

Re: MASQUERADE/SNAT before IPsec

[RUMI Szabolcs]

On Mon, 4 Feb 2008 10:48:51 +0100
"Marco Berizzi" <pupilla@hotmail.com> wrote:

> RUMI Szabolcs wrote:
> 
> > iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -d 164.99.192.0/22 -j
> SNAT --to-source 164.99.195.8
> 
> > The IP address in --to-source 164.99.195.8  is the one that was
> > dynamically allocated by the remote corporate VPN concentrator
> > (not under my control) at the time I've tested the setup.
> 
> > I cannot make an iproute2 dump because I'm using the oldskool
> 
> which ike/ipsec implementation are you using?

On the kernel level I'm using the one that comes with the 2.6 kernel,
so USAGI I guess.

On the userspace level I'm using ipsec-tools-0.6.3_turnpike which is
a special version maintained by Novell that allows us to use their
proprietary Nortel Contivity binary IPsec plugins which are needed
to connect to the corporate VPN. It is using some nasty non-standard
proprietary authentication mechanism in order to be non-compatible
with free implementations but I doubt that my problem is caused by
this.

http://forge.novell.com/modules/xfcontent/downloads.php/turnpike/ipsec-tools-0.6.3/

> > and goes through iptables and gets NATed in the POSTROUTING
> > chain it goes straight out to eth0 and it does not get
> > reevaluated whether it should be handled by IPsec.
> 
> mhhh which kernel version?

To be exact it's 2.6.22-gentoo-r9 from Gentoo Linux.
You can find patch information here:

http://dev.gentoo.org/~dsd/genpatches/patches-2.6.22-9.htm

Thanks!

Best regards,
Sab