VPN

We are running the latest beta 1.3b11, mostly because the NICs that our board has aren't supported in the latest stable release.

Using the device as a firewall works great (and very easy interface!), however we are having a hard time setting up the VPN tunnels between two sites.

Both sites are running the same exact hardware and the same version of m0n0wall. The IPSec tunnel was setup according to the documentation.

The problem is that the IPSec tunnel needs a manual trigger in order to start, and will die after a few minutes. The manual trigger is also very strange. I have to edit the IPSec tunnel and set the tunnel to "disabled", apply the settings and then enable it again. Only then will it work again.

However, even when I permanently transfer data over the tunnel, the tunnel will disconnect and the whole game has to be repeated. Just pinging the remote site is not enough to bring the tunnel up, it will just result in the messages below.

The only log entries that seem relevant are these:

May 13 00:41:02    racoon: ERROR: phase1 negotiation failed due to time up. 07e06b260bd069bf:0000000000000000
May 13 00:40:59    racoon: INFO: request for establishing IPsec-SA was queued due to no phase1 found.
May 13 00:40:43    racoon: INFO: delete phase 2 handler.
May 13 00:40:43    racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 67.33.143.62[0]->54.57.181.40[0]
May 13 00:40:22    dhclient: bound to 54.57.181.40 -- renewal in 231 seconds.
May 13 00:40:22    dhclient: New Broadcast Address: 54.57.181.255
May 13 00:40:22    dhclient: New Network Number: 54.57.181.0
May 13 00:40:04    kernel: arplookup 192.168.0.1 failed: host is not on local network
May 13 00:40:22    dhclient: DHCPACK from 192.168.0.1
May 13 00:40:22    dhclient: DHCPREQUEST on vr0 to 192.168.0.1 port 67
May 13 00:40:12    racoon: INFO: begin Aggressive mode.
May 13 00:40:12    racoon: INFO: initiate new phase 1 negotiation: 54.57.181.40[500]<=>67.33.143.62[500]
May 13 00:40:12    racoon: INFO: IPsec-SA request for 67.33.143.62 queued due to no phase1 found.

These errors always show up when I try to bring the tunnel up.

One of the sites has a T1 line with a static IP, the other has a DSL line where the IP changes, but I use dyndns.com for that.

I'm really not sure how to proceed with this - does anybody have any ideas on how to troubleshoot or fix this? I can post the configuration, but it's completely standard according to the doc.


Thank you .... any help is appreciated.

Well, we just tried it again and for some reason it works now. I didn't really do anything other than reboot one of the firewalls (which I had done before).

Thus far the tunnel has been up for a couple of hours, so that's great.

However, we still had to trigger the initiation of the tunnel by disabling and then enabling the tunnel on one of the machines.

I'd be happy to provide any additional information if anybody cares ;-)

did you enable DPD (Dead Peer Detection) on both ends?

CS...

Just a quick FYI - it's normal for the tunnel to require a "trigger" (i.e. an outbound packet) to be established. That's just the way it works with FreeBSD's IPsec implementation and the racoon IKE daemon... m0n0wall configures the security policy in the kernel and fires up racoon. When the kernel sees a packet that matches the policy (i.e. needs to be encrypted), it finds that there's no corresponding security association (keys etc.), so it triggers racoon to negotiate one.

If anybody knows of a (reliable) way to make racoon immediately negotiate SAs for all existing policies on startup, please let me know.

Hi Guys,

Sorry for the long delay in getting back. DPD was actually not enabled (empty field), and I just changed it 60 seconds.

The tunnel had actually been up for quite some time now (about 2 weeks) without any manual intervention needed. Yesterday I had a power failure at home however (and no UPS - but it gave me a reason to buy one) and so I had to trigger the tunnel again.

With "trigger" I mean I had to disable and re-enable the tunnel on one side. A simple ping, etc. is not enough. This is what's so strange - it won't start the tunnel until I disable and re-enable it. But once I do that it works - every time.

So it looks to me like there is a small bug in the interface. Something is done only when the tunnel is enabled.

I also had the tunnel die on my a couple of hours ago, but disabling and re-enabling it did the trick. Hopefully the DPD will help with that in the future.


Thanks.