[Openswan dev] Re: questions based on the VPN behind the NAT Box.

[Paul Wouters]

On Wed, 18 Jan 2006, Shi Lang wrote:

> On NAT1 Pure Linux PC I did:
>
> 1. ifconfig eth0:1 192.168.252.104        * 192.168.252.104 is the mapping
> ip of 192.168.11.1, the VPN1's external interface eth0.
>
> 2. iptables -t nat -I POSTROUTING 1 -s 192.168.11.1 -j SNAT --to-source
> 192.168.252.104
>
> 3. iptables -t nat -I POSTROUTING 1 -d 192.168.252.104 -j DNAT --to-dest
> 192.168.11.1
>
> I also did settings on NAT2, mapping 192.168.22.2 to 192.168.252.105.
>
> I have successfully established the tunnel between VPN1 and VPN2.

So you first encrypt/sign the packet, then mangle it "broken" by SNAT,
then "break it some more" with DNAT. If it works, I guess you should count
yourself lucky, and thank Arkoon networks for their NAT-T patch we include.
I am assuming this only works because you are rewriting UDP packets containing
the IPsec pacets.

> 1.  But my first try is without Leftid and Rightid in the ipsec.conf in VPN1
> and VPN2,
>
> it failed to establish the M3 negotiation (m1 and m2 in Main Mode is ok, i
> checked with 'ipsec auto --status').
>
> IKE RFC 2409 says: Main Mode, the last two messages authenticate the DH
> exchange.

The default id if not specified is the IP address. So the Id within the
IKE packets contain the original non-NAT'ed IP address. These do not
match the SNAT'ed IP address.

> 2.  But if VPN1 direct to VPN2 (without NAT Box), then without leftid and
> rightid can establish the tunnel at this time.

Yes, because you are not rewriting the IP address you sent as ID.

You can explicitely set a leftid= and rightid=, but the ideal situation is
to not use this NAT approach.

Paul