[Openswan Users] overlapping networks with nat-t

[John A. Sullivan III]

On Thu, 2006-01-19 at 12:29 +0100, Marco Berizzi wrote:
> John A. Sullivan III wrote:
> 
> >On Wed, 2006-01-18 at 19:09 +0100, Paul Wouters wrote:
> > > On Wed, 18 Jan 2006, Marco Berizzi wrote:
> > >
> > > > I have successfully deployed NAT-T on my various
> > > > linux 2.6 (netkey) gateways with OSW 2.4.4. It's
> > > > working good with Windoze XPsp2. Now, mobile
> > > > users are able to connect to my private lan (which
> > > > is a 172.16.0.0/23) from others company private
> > > > networks. My osw box is also tunnelling ipsec traffic
> > > > from/to a (very common) 192.168.1.0 network. This
> > > > prevent roadwarriors which are connected to a
> > > > 192.168.1.0 network to connect to my network. I
> > > > cannot change any network ip address. Is there any
> > > > solution to this problem? DHCP over IPsec? Does
> > > > windows XPsp2 support it?
> > >
> > > an ugly hack is to setup a tunnel for another range,
> > > eg 127.168.1.0/24 and then run SNAT / DNAT on the
> > > packets. Be careful not to NAT the ipsec packets
> > > though. This will be very hard using netkey.
> > >
> ><snip>
> >This can be a real pain in the neck.  For example, we built the ability
> >to do this with a mouse click and few keystrokes into the ISCS network
> >security management project (http://iscs.sourceforge.net) but it still
> >breaks certain protocols, e.g., network neighborhood browsing (as an
> >aside, this is one of the very few things that iptables can't do that a
> >PIX can, i.e., NAT NetBIOS packets with embedded IP information in the
> >NetBIOS header).
> 
> There is also another obvious issue. My company network
> is 172.16.0.0/12 + some other branch offices with 192.168.x.0
> Hopefully 172.16.0.0/12 isn't a common used pool. What happens
> if a roadwarrior connect to an other company network which is
> 172.16.0.0/12? ;-)
Hopefully there will still be some room left on the 10.0.0.0/8
network! :)
> 
> >We finally opted for a slightly different solution for most of our
> >production installations.  Not to take anything away from openswan -- a
> >truly great project -- but we went with openswan for our LAN-to-LAN
> >connections and OpenVPN for our RoadWarriors now that it has matured
> >from its early days.  We have been very pleased with the results and,
> >since it uses virtual IP addresses for the RoadWarriors, it almost
> >doesn't matter what real address they have.
> 
> >2) There is no need to regulate the home IP address space.  All
> >addresses are virtualized.  This gets us around the problem of multiple
> >users behind the same NAT gateway when using L2TP or multiple users with
> >the same internal address behind different NAT gateways when using
> >IPSec.
> 
> IMHO virtual addresses is the only proper solution.
> Again: but ipsec doesn't handle virtual IP?
DHCP-over-IPSec was a nice solution but appears to have died.  On the
other hand, all IPSec virtual adapter implementations that I have seen
had the limitation of only allowing one virtual adapter.  If one had to
completely different networks to attach to (e.g., 10.1.1.0/24 and
172.16.10.0/24), one was stuck.  The OpenVPN approach is much more
elegant.
> 
> >Hope this helps - John
> 
> Sure. I will take a look at openvpn.
> Thanks John.
> 

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net