I tested it with pfSense-Full-And-Embedded-Update-1.2-BETA-1-TESTING-SNAPSHOT-06-06-2007.tgz today. But the parallel tunnel is not available with the latest update too. Pls Pls fix this problem. I think parallel tunnel is a very usful ipsec function. Thank you.

@covex: well… i have about 40 linksys befvp41 and 10 netgear fvs318v3 connected to pfsense box. besides minor missconfiguration problems everything work fine. Wow, so they're actually stable? I cringe at the thought of supporting 40 Linksys VPN boxes.  ;D  I've tried the BEFVP41, granted it was probably 5 years ago, but at the time it didn't work reliably at all no matter what I connected it to. I think I still have it on a shelf around here somewhere, maybe it's time to give it another shot if for nothing other than the sake of documenting the proper way to configure one to connect to pfsense.

after 24 hours this message went away by itself  :- i hate when things fix by themselves

Thanks for that. I have to say I agree that hidden rules are bad. Maybe you could do the same as with NAT and auto create a rule if the check box is checked. Either way it needs to be consistent between creating a rule for a carp and a wan. Especially given that the carp address/interface is now selected from the same dropdown as the WAN interface Thanks for a great firewall

I'm not a Linux guru, and never heard of strongswan until you mentioned it. From a quick Google, it's IPsec for remote access. The issue with IPsec is, unless you have a commercial solution that comes with a client (Cisco, probably others), there are issues getting client software on Windows machines (and I assume that's the majority of what you'll need to support). There is the Shrew Soft client, and I know the author hangs out on our mailing list and people do use it with pfsense. http://www.shrew.net/ OpenVPN is more convenient, IMO, because you can use a single client across every platform you need to support (Windows, OS X, BSD, Linux). With IPsec, you would have a different client from a different source for every platform (again, unless you had a commercial solution). If I was going with a large scale open source deployment, I would go with OpenVPN in most environments. For around 100 simultaneous connections, I would go with a Pentium 4 or better box. That should leave you plenty of power to spare.

Fixed recently: http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/pfSense/etc/inc/vpn.inc?rev=1.89.2.29.2.8;content-type=text%2Fplain

There were some issues with IPsec and snapshots up until earlier today. Try a new snapshot.

@nbviegas: My issue is basically routing then. Wierdly, when I go to "Diagnostics: Routing Tables" I have nothing saying that 192.168.16.0/24 (on pfsense A) should go throuh interface ENC0 (IPSec to pfsense B). As per the default gw of pfsense I have - default 10.0.0.138 UGS 0 682017 1500 fxp0  - which is the IP Address of the ADSL Router. Is there any issue with this setup? It's not routing. As I said before, there is no routing involved with IPsec, as far as the routing table is concerned. It's the SPD that encapsulates matching traffic and sends it to the destination. @nbviegas: What do you mean by " Is the default gateway of every system involved pfsense?" . From what I get the existing DHCP server gives the default gw as the pfsense LAN IP address. If you're using pfsense for DHCP for everything and don't have anything statically addressed then you don't have to worry about what the gateways are set to. Since the traffic is getting logged at the source end, what about at the destination end if you enable logging there?

VPN on OPT1 should work fine provided you are using a 1.2 beta. It was not working on 1.0.1 release.

hi, finally works with release 1.2-BETA-1… i permited traffic between pc1 and pc2... working cool now.. thanks everybody