[Openswan Users] VPN and NAT issues

John A. Sullivan III jsullivan at opensourcedevelopmentcorp.com
Thu Oct 28 08:22:08 CEST 2004


On Thu, 2004-10-28 at 01:47, Chris Lyon wrote:
> > -----Original Message-----
> > From: John A. Sullivan III
> > [mailto:jsullivan at opensourcedevelopmentcorp.com]
> > Sent: Wednesday, October 27, 2004 5:12 PM
> > To: Christopher Lyon
> > Cc: users at openswan.org
> > Subject: Re: [Openswan Users] VPN and NAT issues
> > 
> > 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):
> 
> Agreed that the NAT should be on the site B gateway but I don't want to NAT
> the entire network and would rather just to a bi-directional nat
> 
> Say, 1.1.1.1 to 10.10.10.10
> 
> So I would have thought that the commands would have been, internet is eth1,
> this:
> 
> iptables -t nat -A PREROUTING -i ipsec1 -d 1.1.1.1 -j DNAT --to 10.10.10.10
> iptables -t nat -A POSTROUTING -o ipsec1 -s 10.10.10.10 -j SNAT --to 1.1.1.1
> 
> 
> This doesn't seem to work. Should it?
> > 
<snip>
Hmmm . . . I would think that should work although I have always used
NETMAP.  So from site A you send an ssh packet to 1.1.1.1.  It actually
does make it out of gateway B but still has the address 1.1.1.1 rather
than 10.10.10.10?
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com



More information about the Users mailing list