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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Nick Suckling > Gesendet: Mittwoch, 21. Dezember 2005 12:52 > An: misc@openbsd.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
