Does this imply that I must not mention VPN-2 in the isakmpd.conf Connections statement?
Thanks for your help. > -----Urspr|ngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag > von Nick Suckling > Gesendet: Mittwoch, 21. Dezember 2005 15:32 > An: misc@openbsd.org > Betreff: Re: NAT/pf before IPSEC > > > 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: [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 > > > > > > > _____________________________________________________________________ > > 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
