[Openswan Users] Nat-t Openswan

[Paul Wouters]

On Mon, 19 Apr 2004, Filipe Mota wrote:

>   iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

You must exclude packets with destination through a tunnel:
Assuming 192.168.39.0/24 is one of the local parts of the
tunnel:
 
iptables -t nat -A POSTROUTING -o eth1 -j RETURN -d 192.168.39.0/24
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

This will skip MASQ for packets destined to be crypted.

> 192.168.39.0/24   LAN
>        |
> 192.168.40.132    Client Freeswan
>        |
>        |
> 192.168.39.198
>        |          Firewall with nat
> 212.13.39.71
>        |
>        |
>    INTERNET  
>        |
>        |
> 212.13.39.72
>        |         Server Freeswan
> 192.168.39.1
>        |
>        |
> 192.168.39.0/24   LAN      

You simply CAN NOT have the same IP range on both ends of the tunnel.
Where is 192.168.39.1 ? There are now two locations where these can be 
found. This must be changed. 

> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.39.0/16,%v4:192.168.40.0/24  strictcrlpolicy=yes

You have an overlap here too, 192.168.39.0/16 and 192.168.40.0/24
You also need to say !%v4:192.168.39.0/16 to actually exclude that ip from
being considered a valid NAT range.

The idea of the virtual_private line is to dinstinguish between private IP
space LAN networks in use, versus the private IP space that might be used
be some NAT device. Obviously, just like you cannot have the same network
at both ends of a tunnel, you cannot establish a tunnel from a ADSL/home
NAT network with the same internal IP space range as the subnet at the remote
office LAN.

>  leftsubnet=192.168.69.0/24

So you MUST exclude this range in the virtual_private range.

Paul