i believe you could do this with openbsd 3.9/4.0. they have utilities for ipsec failover, i'm sure they'll work they're way into pfSense either through a bounty or in a couple releases.

@hoba: However we have this already working in head. This means it's already working in our codetree for the next major version. You won't be able to achieve this with 1.0. You have to wait for the release of this version to get this feature.

Yes, and that error was fixed right after RC2 was released with RC2a or b when I recall correctly.

Not really. pfSense only supports ethernet kind of gear. You would need some kind of dial-on demand 56k network modemrouter for this. There are ISDN-Routers that could be used this way but I don't know of a 56k alternative that does something similiar.

@Phobia: Hi, Please don't take from my previous message that I was going to throw in the towel with PFSense!  I was referring to the Netscreen if anything.  ;D Thanks again for a truly wonderful firewall platform! – Phob No problem at all, just wanted to point out that you need that for tunnels from pfsnese to anything (even another pfSense) if one end is dynamic.  ;D

NAT-T will not be included in 1.0. Maybe 1.1 or in the future.

I've had an IPsec connection to a Watchguard x1000 for a little over a month. I'll be posting some screenshots and a basic howto shortly. (hopefully this week) I will put up the screenshots first, as soon as I can edit out the important stuff. The short answer is yes, IPsec to watchguard is possible and so, far, seems quite nice. Pay attention to the "advanced" button when setting up the tunnel on the watchguard side. Remember; both sides require identical settings for protocols, renegotiating timing, and identifiers. The default settings do not match between pfsense and watchguard. This is Monday. I hope to have some images up by Thursday/Friday. (depending how my "real" job goes…)

@IceZy: Is there a snapshot of a version with it, or is it still only in the planning? No there is not.  It's a development version with thousands of new features.

Have a look at http://pfsense.com/index.php?id=33 (the utilities section). You'll find some IPSEC tools and a smal tutorial for one of them there.

No, broadcasts won't leave the own subnet and the other end has a differnet subnetrange.

hoba, thanks for the reply. it turned out to be faulty network card on the WAN interface. Now the ipsec vpn is working flawlessly. great off-shoot of FreeBSD/M0n0wall you guys have created.

Thank you, I will try, but could someone explainds his experiences (soft and configuration (in pfsense and in the soft))?????

Not supported.

Yes, MTU was one of the first things I'v suspected, so I run MTU at 1300 almost from the start (when I installed the tunnel). I just don't know anymore.. but I will probably end up changing hardware all together just to rule out some "issues", but if this fails, it will left me clueless with a Dunce cap somewhere between the two peers. And belive you me - not a pretty picture. P

It's not a good news. But many thanks for your testing. Today, I updated pfsense to RC2h. And I made some tests and found some strange things. I hope it will help you to find the problem on IPSec at OPT1. 1. I disabled the IPSec and made below two tests, a and b. a. DHCP on WAN and OPT1 - I can access Internet through OPT1 when I leave the LAN rule at default gateway. b. Static on WAN and OPT1 - I cannot access Internet through OPT1 when I leave the LAN rule at default gateway. But I can access Internet after I change the LAN rule's gateway to OPT1's gateway. 2. I enabled the IPSec at OPT1. a. DHCP on WAN and OPT1 with the LAN rule at default gateway - I cannot even see SPD on IPSec staus page. b. Static on WAN and OPT1 with the LAN rule at default gateway - I cannot access to Internet. But I can see SPD on IPSec staus page and I found some IPSec logs that IPSec tried to establish tunnel and it failed. Below is the IPSec log. Sep 3 02:21:57 racoon: ERROR: phase1 negotiation failed due to time up. 28cde7f46500a3aa:0000000000000000 Sep 3 02:21:28 racoon: INFO: delete phase 2 handler. Sep 3 02:21:28 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 210.109.xx.xx[0]->210.106.XX.XX[0] Sep 3 02:20:57 racoon: phase1(agg I msg1): 0.102666 Sep 3 02:20:57 racoon: oakley_dh_generate(MODP768): 0.089224 Sep 3 02:20:57 racoon: INFO: begin Aggressive mode. Sep 3 02:20:57 racoon: INFO: initiate new phase 1 negotiation: 210.106.xx.xx[500]<=>210.109.xx.xx[500] Sep 3 02:20:57 racoon: INFO: IPsec-SA request for 210.109.xx.xx queued due to no phase1 found. c. Static on WAN and OPT1. I changed the LAN rule's gateway OPT1's gateway - Now I can access to Internet through OPT1. And I can see SPD on IPSec status page. But I cannot find any logs that IPSec tried to establish tunnel even after I ping to remote subnet. For more accurate test, all tests was made when WAN disconneted. Thank you.

@Voami: @hoba: Otherwise the traffic won't be encapsulated into the tunnel as it doesn't match the tunnel definition. Hmm, are you totally sure about this? I don't have any positive contrary evidence, but I successfully run an IPSEC VPN like this: Local Net Remote Net 172.16.0.0/22 172.16.2.0/24 Even though the remote net is technically a subnet of the local net, I have had this work without issue. Note: it was not totally intentional, originally. The next step: –------------------ If one expanded this into: Local Net Remote Net 172.16.0.0/22 172.16.1.0/24 172.16.0.0/22 172.16.2.0/24 172.16.0.0/22 172.16.3.0/24 Now you can send traffic bound from each remote net to another to the localnet. This will work. Nobody said it wouldn't. If you can sum up your networks this way it will work. I have a 10 location setup running this way with 8 of the locations coming from dynamic IPs. The thing you can't do is add a static route across the tunnel.

Thanks for the tip! I've tried serveral values in the 1400ish range and am not having much luck. I am able to make voip calls b/t the two sites, which tells me that traffic is at least flowing in both directions. Edited: looks like I spoke too soon…. lowering to 1300 seems to have fixed the VNC issue. Thanks for the tip!

Works fine for me. I would blame the problem on running in vmware maybe. I actually have configured a multi site (9 sites with dynamic IPs) to headoffice (static IP) setup today where all sites are connected through the mainoffice (traffic from site a to site b runs through the tunnels via mainoffice; site a and b don't share a tunnel). While I set up this the LANs of the firewalls were not connected but the tunnels were established automatically and stayed up. I even rebooted the mainoffice and the other machines dropped in in a few minutes. After 5 minutes the last machine joined again and everything was up and stayed up. I also have a similiar setup running since month where I have running voip through the tunnels. No issues. Please try this with some real machines.

Use the DHCP Server of the pfSense to assign the clients the pfSense as  first DNS Server and the remote DNS Server behind the tunnel as second DNS. Also if you have a WINS server in the remote LAN assign this as well. This works for me for pretty everything.