I have not yet used a checkpoint client yet.  :( Oh, any chance you have a lifetime mismatch somewhere between the concentrator and the clients?

We need more details on your setup. This is not enough to even start a wild guess.

I agree. This would be a nice addition. I have a pfSense acting as concentrator for 12 other pfSense's joining as mobile clients and it's pretty confusing to tell which one is which  ;)

Sounds like a freebsd bug then. Search the appropriate lists for similiar problems or statements on this.

This has been discussed elsewhere already. Please search for this discussion and why it won't work. Loadbalancing over several tunnels won't work.

Guess this is untested. However I have no issues running ipsectunnels at the pfsense itself and using ipsec clients at lan to go somewhere else so far. Give it a try and let us know.

I'm in the same boat. PC with Cisco VPN client, configured for Group Auth, Tunneling IPSEC over UDP. I'm unable to get the desktop client to work behind the PFSENSE box (tried 1.01 and todays CVS). If I put the VPN client in FRONT of the box, IE on the public IP, works first time, like a charm. Dialup, works find. Sprint Wireless Modem, works fine. Behind the PFSENSE box, no work. I've tried NAT/Port forwarding, TCP/UDP 500, TCP/UDP 10000, ESP, etc. No work. I'd be happy with EITHER the VPN client working, or the PFSense box establishing the connection. Either would serve what I  need to accomplish. HELP!

or use the vpn ptpp server on youre pfsense server and the ptpp client on youre pc's

OpenVPN would be nice. Stupid sonicwalls. Are there any open source firewalls that will do dynamic ipsec endpoints?

@decibel83: racoon: ERROR: such policy does not already exist: "192.168.1.0/24[0] 192.168.0.0/24[0] proto=any dir=out" This is usually only a debug message that can be ignored. If it works one way the tunnel should be up fine. Does the netgear support some filtering for the vpn traffic? Maybe you need to create a rule to allow traffic? The pfSense currently can't filter VPN traffic so it can't be an issue on the pfSense end of the connection. Are you trying to ping from behind the netgear or from the netgear itself? Usually devices encapsulating the connection can't use it directly without adding a fake static route or pinging from their LAN IP.

try "Prefer old IPsec SAs  " from system>advanced and see if this has a positive effect on reestablishing the link.

fixed my problem with my sonicwall tz170 & pfsense.. on the pfsense side of the tunnel, when I was entering in the remote subnet, I left the subnet class with the default of 32, when it should have been 24.  When I changed that everything worked like it should!    Imagine that..

Cool  :D

Currently you need at least one static IP to create IPSEC Tunnels (have a look at http://pfsense.com/mirror.php?section=tutorials/mobile_ipsec/ ).

OK, thank you very much! I will try and I rewrite you if I will have some problem…

I reinstalled all system and now its works. I think that's a bug.

Since there are so many views of this topic I post what finally worked for me and might help others. Maybe Hoba adds it to his tutorial… both sides: RULE: AH          *        *        WAN address              *      *          AH for IPsec RULE: ESP        *        *        WAN address              *      *          ESP for IPsec RULE: UDP        *        *        WAN address              500    *          UDP500 for IPsec If you use the settings from pfSense (which is ESP as Phase 2 protocol), you don't need the AH rule. Do not use any NAT rules, this is not necessary and NAT-traversal (NAT-T) of IPsec is a task on its own. This usually would require UDP4500 and other things I am not familiar with. Have a look here:  http://en.wikipedia.org/wiki/NAT_traversal

Have a look at the free IPSEC clients mentioned here: http://forum.pfsense.org/index.php/topic,2009.msg11516.html#msg11516 For OpenVPN have a look at these GUI clients: http://openvpn.se/ http://openvpn.net/gui.html

I put seconds instead the IP… Now works ! thanks very much. Giacomo

IPSEC issue.  Research aggressive mode + dynamic dns domain names.