@jimp: Put your allow rule for OpenVPN above any of the pfblocker rules. Once the connection is active the firewall state lets it through so it ignores the rules from that point on since it's an active connection. cant believe it was that simple!  I did not know you could move up the rules, my bad. Thanks!

Worked first time - can't do better than that Thanks Andrew

Sure, either by pushing a route to the clients for the IPs you want to go over the VPN, or using the option to force all client traffic through the VPN. The default automatic outbound NAT config will do NAT for the VPN tunnel network so it should work with minimal effort. If you're using manual outbound NAT you'll need to make sure you have a rule that covers the VPN client subnet. Beyond that, make sure your OpenVPN tab rules allow the traffic through and it should work fine.

We backed up the config, then did a factory reset on those two machines. With nothing but LAN/WAN IPs and the VPN configured, everything works flawlessly as expected. Will see if we can find out the breaking difference by comparing the configs :-)

Chris, I want to thank you for all your hard work in furthering pfSense to what it is today.  What an extremely powerful and useful solution. For a home user like myself,  the support option is pricey to say the least.  My system to date has cost under $400 running an Atom based board and Ubiquiti Unifi AP Pro.  I'm positive someone with the requisite knowledge could solve my issues in a relatively short period of time.  Spending $600 though is out of my budget and the reason why I came to the forum.  I bought The Book of PF, pfSense 2 Cookbook, and your Definitive Guide and still was having difficulty solving my issues on my own.   My plan was to use either freelancer or elance to try and get someone to solve them then post up the solution here for whomever wanted the same setup.   I would wholeheartedly trust the world's foremost pfSense experts but unfortunately I just don't have the budget at present to support that option.

I installed pfsense 2.1beta using snaphots. I configured it in "tap" mode. After dealing with windows firewall everything seems to be ok now. Except, when i try to connect to vpn server from local network, it connects but nothing works. It's not a big issue since nobody needs to use VPN in local network but it was working in v2.0.2 though. I noticed "Backend for authentication" line is missing in openvpn/server page. I thought this is issue or maybe tap mode is causing it. It would be better if i could test vpn from local network though.

I had exactly the opposite problem. I couldn't ping lan computers. Here is what i did. First I installed pfsense 2.1 beta because 2.0.2 was too messed up by trial and error. I followed this guide. It tells it for "tap" vpn mode instead of "tun". Tap is more suitable for me. I tried tun mode too. http://hardforum.com/showthread.php?t=1663797 Again I faced the same exact issue. But later I found it was a windows firewall issue. Just turning it off and on again somewhat solved the problem. If you want to follow the guide, dont forget to put rules for OpenVPN and bridge interfaces. And dont try to connect to your vpn from local network. Try from another computer because in 2.1beta they didn't put a backend handler so nothing works if you connect from local network. At least I couldn't do it. It was working in 2.0.2 though Cheers

You're using shared key mode with tun, which requires that you set an IP with ifconfig. If you use a server mode (ssl/tls) then it can automatically supply an IP to clients.

This issue is solved. My ISP at this time claimed the problem wasn't on his side. Since I wasn't able to find a solution, I changed the ISP. Now, I don't experience these disconnections anymore :-)

Fixed, Had manual NAT enabled and didn't add the OpenVPN Network NAT Rule

Care to share the root cause and solution?

There isn't a master switch for OpenVPN that would do what you're attempting. What is it you're really trying to accomplish? Perhaps there is another way to make it happen? One possible solution might be to "killall -9 openvpn" to stop it, and run /etc/rc.openvpn to start again. That would only be temporary though and it wouldn't survive any action that would normally cause OpenVPN to start again (e.g. reboot, WAN down/up event, etc)

Here is the nat table in the DDwrt. And just for clarification, I AM actually able to connect to the webGUI, it's just that I usually don't get and styling (although sometimes I do). Only sometimes I cannot connect at all. All phones register with the correct IP to the asterisk server. What would be odd to me is if the tunnel is set up and happy, why would a NAT cause pfsense to block the connection at the VPN level (it's blocking the VPN packets, rather than the actual traffic). In other words, right at the moment the call is placed, pfsense blocks all connections from the remote site's public IP address. And, for what it's worth, I do not observe this behavior with anything else coming over the VPN. Even when I have the issue with the webGUI, nothing get's blocked (at least on the pfsense side). Chain PREROUTING (policy ACCEPT 1162 packets, 304K bytes) pkts bytes target    prot opt in    out    source              destination     4  244 DNAT      icmp –  *      *      0.0.0.0/0            [public_IP]        to:10.51.2.1   60  8983 TRIGGER    0    –  *      *      0.0.0.0/0            [public_IP]        TRIGGER type:dnat match:0 relate:0 Chain POSTROUTING (policy ACCEPT 59 packets, 5237 bytes) pkts bytes target    prot opt in    out    source              destination   223 12561 SNAT      0    –  *      vlan2  0.0.0.0/0            0.0.0.0/0          to:[public_IP]     0    0 RETURN    0    –  *      br0    0.0.0.0/0            0.0.0.0/0          PKTTYPE = broadcast Chain OUTPUT (policy ACCEPT 61 packets, 4331 bytes) pkts bytes target    prot opt in    out    source              destination

@phil.davis: I would use OpenVPN. Put a server at HQ. You will need to forward a port on VDSL 1 from a.a.a.a to 192.168.1.100 - then the pfSense OpenVPN server can listen on that port. If you use Peer to Peer (SSL/TLS) then you can have both clients connect to 1 server. With client-specific overrides you tell it which remote network is at the other end on which client. The clients from site 2 and site 3 can get out fine to the server at public IP a.a.a.a - so no port forwards or mods to VDSL 2 and VDSL 3 settings needed. Ok, finally it's working in a Site-to-site Shared Key version of OpenVPN. I have two more questions: 1. When I ping from Site 2 LAN location to Site 1 LAN, everything it's ok, but when I ping from Site 1 (HQ LAN) to Site 2 nothing happens. 2. I build only one openvpn pfsense client yet - Site 2. For the next pfsense openvpn client - Site 3, should I use on server side the route command in custom field, eg: route 192.168.3.0 255.255.255.0 or something else ? I think client override section on HQ - pfsense Site 1 is useless, because for peer-to-peer shared key server mode I don't need certificates…

Nevermind, figured out how to set the PLC to DHCP and I can talk to it now.  Thanks!