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
