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
