questions based on the VPN behind the NAT Box.

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
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev