Linux as NAT gateway to IPSEC server

I've been running linux since SLS and kernel .97 and have never had
problem with it, until now.

I have two windows boxes behind the linux box running kernel 2.6.11.8
(self-compiled) and have everything working. I could ipsec into my
work (cisco client) and the other computer could ipsec into a different
work server running the nortel networks client. All was well in the
world.

Sometime last week, the nortel network client wouldn't connect any
longer. I've changed nothing. I called up that work location and they
claim to have changed nothing. If I plug the windows machine directly
into the cable modem, I can connect with the Nortel client! The cisco
client works fine either way.

What's the problem? I'm not firewalling anything, my iptables script
just looks like:

/sbin/iptables -F
/sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

I found a blurb on the internet to change the postrouting line to:

/sbin/iptables -t nat -A POSTROUTING -p ! esp -o eth1 -j MASQUERADE

(exclude the esp (protocol 50)) but it didn't help.

Suggestions on how to troubleshoot?

deja3-(E-Mail Removed) wrote in news:1125498388.716809.89570
@z14g2000cwz.googlegroups.com:

> I've been running linux since SLS and kernel .97 and have never had
> problem with it, until now.
>
> I have two windows boxes behind the linux box running kernel 2.6.11.8
> (self-compiled) and have everything working. I could ipsec into my
> work (cisco client) and the other computer could ipsec into a different
> work server running the nortel networks client. All was well in the
> world.
>
> Sometime last week, the nortel network client wouldn't connect any
> longer. I've changed nothing. I called up that work location and they
> claim to have changed nothing. If I plug the windows machine directly
> into the cable modem, I can connect with the Nortel client! The cisco
> client works fine either way.
>
> What's the problem? I'm not firewalling anything, my iptables script
> just looks like:
>
> /sbin/iptables -F
> /sbin/iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
> /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j
> ACCEPT
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> I found a blurb on the internet to change the postrouting line to:
>
> /sbin/iptables -t nat -A POSTROUTING -p ! esp -o eth1 -j MASQUERADE
>
> (exclude the esp (protocol 50)) but it didn't help.
>
> Suggestions on how to troubleshoot?

Protocol 50 (e)ncapulated (s)ecurity (p)protocol does have issues with NAT.
Excluding it from the masqarade though, means there is no chance at all of
it working, as it means that you are then sending a packet out onto the
internet with a source ip address that is not routable on the public
network. (e.g say the PC running the VPN client has a private address of
192.168.?.?). However -see the NAT-Traversal section of this IPSec howto
doc:

http://www.ipsec-howto.org/x185.html

As far as figuring out what is going on, I suggest starting with using
tcpdump or ethereal to capture the traffic to give you a pointer as to what
is going on.

Klazmon.



>
>

Llanzlan Klazmon wrote:
>
> Protocol 50 (e)ncapulated (s)ecurity (p)protocol does have issues with NAT.
> Excluding it from the masqarade though, means there is no chance at all of
> it working, as it means that you are then sending a packet out onto the
> internet with a source ip address that is not routable on the public
> network. (e.g say the PC running the VPN client has a private address of
> 192.168.?.?). However -see the NAT-Traversal section of this IPSec howto
> doc:
>
> http://www.ipsec-howto.org/x185.html
>
> As far as figuring out what is going on, I suggest starting with using
> tcpdump or ethereal to capture the traffic to give you a pointer as to what
> is going on.
>
> Klazmon.

I ran a tcpdump on the connection to determine what was happening.
What I saw was a ESP protocol 50 coming back from the server I'm trying
to auth with and the linux box apparently didn't know what to do with
the packet, so it send an icmp type 20 "denied" back to the server.
What I had to do was to forward all protocol 50 to the internal ip
address of the Win2K client that originates from the server I'm trying
to connect to.

What's interesting is that using a Linksys router, this wasn't
necessary. Why doesn't the linux box handle this connection properly?
Surely it knows that my internal box made the connection to a
particular ip, so when it sees a connection come back from that ip, it
should KNOW to route it correctly.

Am I missing something?

Here's the line I had to add to iptables:

/sbin/iptables -t nat -A PREROUTING -p 50 -i eth1 -d $external_ip -j
DNAT --to $internal_win2k_ip --src $vpn_server_ip

Then it worked.

deja3-(E-Mail Removed) wrote in
news:(E-Mail Removed) ups.com:

> Llanzlan Klazmon wrote:
>>
>> Protocol 50 (e)ncapulated (s)ecurity (p)protocol does have issues with
>> NAT. Excluding it from the masqarade though, means there is no chance
>> at all of it working, as it means that you are then sending a packet
>> out onto the internet with a source ip address that is not routable on
>> the public network. (e.g say the PC running the VPN client has a
>> private address of 192.168.?.?). However -see the NAT-Traversal section
>> of this IPSec howto doc:
>>
>> http://www.ipsec-howto.org/x185.html
>>
>> As far as figuring out what is going on, I suggest starting with using
>> tcpdump or ethereal to capture the traffic to give you a pointer as to
>> what is going on.
>>
>> Klazmon.
>
> I ran a tcpdump on the connection to determine what was happening.
> What I saw was a ESP protocol 50 coming back from the server I'm trying
> to auth with and the linux box apparently didn't know what to do with
> the packet, so it send an icmp type 20 "denied" back to the server.
> What I had to do was to forward all protocol 50 to the internal ip
> address of the Win2K client that originates from the server I'm trying
> to connect to.
>
> What's interesting is that using a Linksys router, this wasn't
> necessary. Why doesn't the linux box handle this connection properly?
> Surely it knows that my internal box made the connection to a
> particular ip, so when it sees a connection come back from that ip, it
> should KNOW to route it correctly.
>
> Am I missing something?
>
> Here's the line I had to add to iptables:
>
> /sbin/iptables -t nat -A PREROUTING -p 50 -i eth1 -d $external_ip -j
> DNAT --to $internal_win2k_ip --src $vpn_server_ip
>
> Then it worked.
>
>

Protocol 50 isn't stateful I guess. I.e you have to have a specific rule
each way, you can't get by with ESTABLISHED or RELATED because of that. I
would say that Linux netfilter is working correctly and the Linksys router
firewall implementation is doing a kludge.

Klazmon.