I tried as suggested and added another flow to the isakmpd.conf. If this isn't mentioned in the connections statement, it will not start with isakmpd, but can be started through the fifo interface to isakmpd using the 'c' command.
It works for me, now the packets get routed through enc0 and are properly natted. I took a look at file isakmpd.pcap file and found that this extra flow is indeed negotiated with the remote end. This worries me. I added this flow only to get the routing going and do not want the remote site know about this. Could it be that this negotiation disturbs the other end? Btw. in the netstat -rn output only the 'in' half of this extra flow shows up, not the 'out' part. Strange, I would have expected this the other way. Regards Christoph -----Urspr|ngliche Nachricht----- Von: Matthew Closson [mailto:[EMAIL PROTECTED] Gesendet: Mi 21.12.2005 19:15 An: Christoph Leser Cc: misc@openbsd.org Betreff: Re: NAT/pf before IPSEC On Wed, 21 Dec 2005, Christoph Leser wrote: > Does this imply that I must not mention VPN-2 in the isakmpd.conf Connections > statement? > > Thanks for your help. I tried with and without and didn't get it working either way. I think if you do not include it in your Connections statement then it is irrelevant. You need to specify it in that statement to generate an SPI. From what I've read when packets come in they see if they match an existing SPI to determine if they should be sent to the enc0 interface or not. But like I said I still haven't got it to work so take that with a grain of salt. -Matt- > >> -----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
