[Openswan Users] VPN and NAT issues

John A. Sullivan III jsullivan at opensourcedevelopmentcorp.com
Wed Oct 27 21:12:03 CEST 2004


On Wed, 2004-10-27 at 18:31, Chris Lyon wrote:
> So, I am trying to use NAT to solve the problem below because of an IP
> addressing conflict issue but I am not having much luck. Basically all of
> the Site A needs to get to only a few devices at each site B&C so I am
> trying to do PREROUTING NAT on the far end systems. I have the tunnels up
> and I can see the traffic getting to the remote side on ipsec0 but I just
> can't get it to NAT from the 1.1.1.1 to the real 10.10.1.1. 
> 
> Command that I think should work
> iptables -t nat -A PREROUTING -d 1.1.1.1 -j DNAT --to 10.10.1.1
> 
> 
> Any ideas? Layout and configs are below.
> 
> 
> Site A eth0 - 192.168.254.0/24----------Internet------Site B eth0 -
> 10.10.0.0/16
> 					 \
> NAT FROM 1.1.1.1 10.10.1.1 example
> 					  \--------Internet------Site C eth0
> - 10.10.0.0/16
> 	
> NAT FROM 1.1.1.1 10.10.1.1 example
> 
> 
> So here are the configurations:
> 
> Site A
> 
> conn site_a-to-site_b
>         #---------(local side is left side)
>         left=<public site a>
>         leftsubnet=192.168.254.0/24
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site b>
>         rightsubnet=1.1.0.0/16
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
> 
> 
> Site B
> 
> conn site_b-to-site_a
>         #---------(local side is left side)
>         left=<public site b>
>         leftsubnet=1.1.0.0/16
>         leftnexthop=%defaultroute
>         #---------(remote side is right side)
>         right=<public site a>
>         rightsubnet=192.168.254.0/24
>         #---------Auto Key Stuff
>         pfs=yes
>         auth=esp
>         authby=secret
>         esp=3des-md5-96
>         keylife=8h
>         keyingtries=0
<snip>

This can indeed be done.  We do it in the ISCS project
(http://iscs.sourceforge.net).  In fact, in ISCS, one merely checks the 
Internet NAT check box on the NATting interface and enters the new
network range.

I believe your openswan configuration is correct.  All NAT should occur
on the site B gateway.  I would suggest using the NETMAP patch to NAT
the entire range, restrict the NAT to just the ipsec interfaces and use
an SNAT/DNAT pair so that you can initiate traffic from site B.  Thus,
the iptables rules on site B would be (assuming eth1 is your Internet
facing interface):

iptables -t nat -A PREROUTING -i ipsec1 -d 1.1.0.0/16 -j NETMAP --to
10.10.0.0/16
iptables -t nat -A POSTROUTING -o ipsec1 -s 10.10.0.0/16 -j NETMAP --to
1.1.0.0/16

This solves the routing problems but you may need a split DNS to handle
name resolution issues.  Also be aware that some protocols with embedded
layer three information in their layer seven payload may break.

There is also a way to do this by NATting site A if one does not have
control of site B but it is a little more complicated.  We hit that for
an ASP who had conflicting IP addresses for clients but could not touch
their gateway.

Hope this helps - John
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com



More information about the Users mailing list