@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.

Thats really nice data to see.  Thanks for sharing!!!  Not bad at all for a 266 mhz device + vpn crypto.

Have a look at http://pfsense.com/mirror.php?section=tutorials/mobile_ipsec/

We did some IPSEC improvements in RC2 but they shouldn't affect establishing of a tunnel. I just wondered what your specs are as we had some funny effects with 64 MB RAM hardware at the hackathon where racoon exited too due to full memory but that shouldn't be the case with your boxes then.

It's only debug output.

Yep, you can.

I'll try to test this option soon with the latest build.

Actually, the openvpn trafic orignating from pfSense cannot take advantage of the load balancer. In order to have a functionnal(FAIL-OVER ONLY) setup on a single box, here's what we did: If the tunnel goes down, add a route to direct OpenVPN trafic to the other gateway (ISP2) In the openvpn client configuration, add to the custom options: up-restart;up /var/etc/yourscript.sh Idealy, the script should be linked to the load balancer (for the monitor IPs) So, there is follow-up in http://forum.pfsense.org/index.php/topic,1650.0.html for the load balancer scripting… mtoadmin

I really don't know, haven't played around with such a config yet.

We don't support old versions. Upgrade to the latest RC1 snapshot. If the problem still exists raise your voice again. The version you are using is outdated since month and a lot of things have been changed that might resolve your issue.

See http://forum.pfsense.org/index.php?topic=1580.0 for a similiar scenario.

Is this something that can be done for a fee?  Is there an alternative solution?  This would be a very helpful feature. Thanks