Then you have a problem at the remote end. Maybe it needs some firewallrules too? Also note that the devices that are establishing the tunnels usually can't use the tunnel itself unless you add a fake static route. Retry from clients behind the vpn endpoints.

ok so i will forget about making a request ;D i belive i can live without isakmpd…i will see.

We do create rules for IPSEC behind the scenes. In the past you only had to add those rules manually if you were running ipsec on VIPs like CARP but I think we nowadays even create rules for those since you now can specify the CARP IPs as endpoints in the tunnelconfiguration.

Oh, ehm … i change the PFS option to 2 and now the tunnel is up and running again. I'm wondering how the tunnel works first with this option set to off ... Greets, Sannny

"solved" done  :)

It's not designed that way yet. Search the forum if you need further details. This has been discussed in depth already. When using dynamic endpoints at both ends try using openVPN.

I have seen that error before when the ends of the tunnel are mismatched.  One being main and the other agressive.  I have seen it when I am first setting up the ipsec connections between symantec, linksys, & netgear boxes. RC

This is being addressed on 1.3.

@fastcon68: What VPN clients do you use for IPsec and Open VPN? Is OpenVPN a encrypted VPN solution? Take a look at the documentation on http://www.openVPN.net on how to setup an openVPN client. Reading the example file and the documentation helps to bring the client to run… http://openvpn.net/index.php/documentation/howto.html#client To your question if OpenVPN is an encrypted VPN solution. Did you even take a look at it? From your question it seems to me as if you didnt even bother to read the absolute basics about it. (Like the frontpage of http://www.openvpn.net )

Hello, i have tested the ipsec inoffcial rc5 ( Build 2008/02/15) today. I have run various tests with different builds of 1.2 beta/rcx.: Here are my results: 1. inofficial rc5 – static - main -->  1.2 rc3 – static -- carp-cluster = OK and stable 2. inofficial rc5 – static - main -->  1.2-TESTING-SNAPSHOT-07-21-2007  –static -- carp-cluster = OK and stable 3. inofficial rc5 – static - main -->  1.2 rc2 – static  = OK and stable 3. inofficial rc5 – static - main -->  1.2 rc5 –static = OK and stable 4. inofficial rc5 – static - main -->  1.2 beta 3 –static -- carp-cluster = OK and stable 5. inofficial rc5 – aggressive -- mobile -- pfs-on --> inofficial rc5 – mobile-pfsense-server -- pfs-on = OK and stable 6. inofficial rc5 – aggressive -- mobile -- pfs--off --> inofficial rc5 –mobile-pfsense-server --pfs-off = OK and stable Ok, the actually rc5(inofficial) ipsec was fast and stable….... Good Job! Greetings Heiko

sorry, under the weather.  Will try to post tonight. RC

Sorry, forgot to mention the pfsense version, it's 1.2-RC4 built on Tue Jan 15 23:05:07 EST 2008 PFS key group, if that's what you mean, has been set to off on the server. I'm not sure how you set PFS on the OS X client, it's somewhat limited in options. Tried setting it to 1,2 and 5 as well, but it seemed to have no effect.

Thank  you guys.

Thanks for letting me know that Seth.

The upgrade did not help, so I decided to drop to eh command shell and run racoon with some more debugging enabled. That showed me what the problem was immediately. I had incorrectly specified the the remote LAN as 10.0.0.1/24 not 10.0.0.0/24 Correcting this sill mistake in my configuration sorted it out. Regards Ben

Thanks razor2000, for the useful information that you have provided me.