Re: NAT/pf before IPSEC

[Nick Suckling <nsuckling_(_at_)_cmedresearch_(_dot_)_com>]

No the other side does not need to know about this additional section if
you are using NAT as described.

Nick

On Wed, 2005-12-21 at 14:06 +0100, Christoph Leser wrote:
> If you add this extra section to your isakmpd.conf, do you need to add it to the remote site too? Does this extra section change the negotiation between the two endpoints.
> 
> Thanks 
> 
> > -----Urspr|ngliche Nachricht-----
> > Von: owner-misc_(_at_)_openbsd_(_dot_)_org [mailto:owner-misc_(_at_)_openbsd_(_dot_)_org]Im Auftrag
> > von Nick Suckling
> > Gesendet: Mittwoch, 21. Dezember 2005 12:52
> > An: misc_(_at_)_openbsd_(_dot_)_org
> > Betreff: Re: NAT/pf before IPSEC
> > 
> > 
> > One easier way I have had this working is to add an additional section
> > to your isakmpd.conf. Something like the following. Your NAT 
> > then takes
> > care of the rest.
> > 
> > 
> > [VPN-1]
> > Phase=                                          2
> > ISAKMP-peer=                    remote
> > Configuration=                  Default-quick-mode
> > Local-ID=                       ip-10.0.20.254
> > Remote-ID=                      network-192.168.60.0/255.255.255.0
> > 
> > [VPN-2]
> > Phase=                                          2
> > ISAKMP-peer=                    remote
> > Configuration=                  Default-quick-mode
> > Local-ID=                       network-192.168.20.0/255.255.255.0
> > Remote-ID=                      network-192.168.60.0/255.255.255.0
> > 
> > [ip-10.0.20.254]
> > ID-type= IPV4_ADDR
> > Address= 10.0.20.254
> > 
> > [network-192.168.20.0/255.255.255.0]
> > ID-type= IPV4_ADDR_SUBNET
> > Network= 192.168.20.0
> > Netmask= 255.255.255.0
> > 
> > [network-192.168.60.0/255.255.255.0]
> > ID-type= IPV4_ADDR_SUBNET
> > Network= 192.168.60.0
> > Netmask= 255.255.255.0
> > 
> > Nick
> > 
> > 
> > On Wed, 2005-12-21 at 04:09 -0500, Matthew Closson wrote:
> > > Hello,
> > > 
> > > I'm running into an issue which was brought up on the list 
> > before, the 
> > > last reference I found was in 2004:
> > > 
> > > http://archive.openbsd.nu/?ml=openbsd-pf&a=2004-10&m=430206
> > > 
> > > I have an OpenBSD 3.8 machine.
> > > dc0  is an internal NIC assigned 192.168.20.250
> > > fxp0 is an external NIC assigned a.b.c.d public_IP_address
> > > 10.0.20.254 is an inet alias on fxp0
> > > 192.168.20.0/24 is my internal network.
> > > 
> > > 192.168.20.0/24
> > >  	|
> > >  	|
> > >  	|
> > > 192.168.20.250 - dc0
> > > 10.0.20.254 - inet alias on fxp0
> > > a.b.c.d - fxp0 public_IP
> > >  	|
> > >  	|
> > >      IPSEC Tunnel
> > >  	|
> > >  	|
> > > e.f.g.h - public_IP tunnel endpoint
> > > 192.168.60.0/24 remote network
> > > 
> > > 
> > > According to the parameters of the tunnel setup (of which I 
> > cannot change) 
> > > the remote IPSEC tunnel endpoint expects traffic from my 
> > network to look 
> > > like it is coming from 10.0.20.254/32.
> > > 
> > > This works:
> > > ping -I 10.0.20.254 192.168.20.10
> > > 
> > > I get responses back from the pings, now I need to nat my 
> > internal network 
> > > to appear to be coming from 10.0.20.254
> > > 
> > > So I can do:
> > > 
> > > nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 -> 
> > 10.0.20.254
> > > 
> > > And what happens is, packets coming in from the 
> > 192.168.20.0/24 network 
> > > hit my internal NIC, are evaluated for IPSEC routing, are 
> > not part of an 
> > > SPI and are not sent over enc0.  This is because IPSEC 
> > routing takes place 
> > > before pf and nat.
> > > 
> > > In the message I linked to above, Cedric said that you can 
> > get around this 
> > > by creating a fake flow into an existing SPI so that your 
> > incoming traffic 
> > > gets routed into enc0 and then nat'd appropriately.  He 
> > said you could run 
> > > this flow from a cron script, I suppose that would run 
> > every period of 
> > > time that your SPI times out.
> > > 
> > > This doesn't seem real solid to me if you need traffic to 
> > stay up over 
> > > your tunnel.  If your script doesn't run at the right time, 
> > your existing 
> > > connections over the tunnel are going to fall apart.  In 
> > another message 
> > > someone suggested patching isakmpd to modify this behavior.
> > > 
> > > My questions are:
> > > 
> > > Is there a better or newer way of doing NAT before IPSEC routing? 
> > > Does anyone have a script for adding fake flows to SPI's 
> > periodically?
> > > Does anyone have a source patch for isakmpd that solves this issue?
> > > 
> > > Any info is much appreciated,
> > > I am subscribed to the list.
> > > Thanks,
> > > 
> > >  		-Matt-
> > > 
> > > 
> > > 
> > _____________________________________________________________________
> > > This e-mail has been scanned for viruses by MCI's Internet 
> > Managed Scanning Services - powered by MessageLabs. For 
> > further information visit http://www.mci.com
> 
> 
> _____________________________________________________________________
> This e-mail has been scanned for viruses by MCI's Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.mci.com