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!

That sounds a lot like a problem with the router the clients are behind, if the clients are at a different location or one of them behind something else, does it work? Some residential-grade routers/NAT devices do stupid things with UDP.

quagga does not need interfaces (anymore) either. I just prefer it that way because then you have a seperate firewall tab for each vpn connection. for me that makes it easier to visualize what i'm trying to do :)

Solved! As mentioned by jimp (http://forum.pfsense.org/index.php/topic,54537.msg291748.html#msg291748) just add a NAT rule on the MASTER for each IP address of the BACKUP host unreachable from the VPN client . Following the above data here is an example, which also includes a rule for the BACKUP IP host in the DMZ. Interface       Source                  Source  Destination             Destination     NAT Address     NAT     Static  Description                                        Port                            Port                            Port    Port –------------  ----------------------  ------  ----------------------  --------------  --------------  ------  ------  ------------------------------- LAN             10.102.128.0/24         *       192.0.0.252/32          *               192.0.0.254     *       NO      Enable PF2 reply to VPN clients DMZ             10.102.128.0/24         *       192.168.0.252/32        *               192.168.0.1     *       NO      Enable PF2 reply to VPN clients --------------  ----------------------  ------  ----------------------  --------------  --------------  ------  ------  ------------------------------- During the creation of this NAT rules you must check "No XMLRPC Sync". Similar rules can also be added to the BACKUP host, useful if the MASTER WAN connection goes down. Simply replace the destination IP address and put the IP of the MASTER, eg. 192.0.0.252/32 becomes 192.0.0.251/32. Do the same to any other networks. If you add rules also on the BACKUP host, I recommend to disable the option CARP -> "Synchronize NAT" because they would be deleted by the first synchronization. In 2.0.2 and 2.1 we shut down OpenVPN if it's bound to a CARP VIP in backup mode. On my 2.0.2 OpenVPN still running in BACKUP host and routing tables is identical between the two box. Bye.

Can you re-phrase?  I'm not following what you said.

@heper: without more information i doubt we can be of assistance I've opened a ticket with pfSense. It would have been helpful to state what additional information would have been helpful to you however.

The instructions at http://www.komodosteve.com/archives/232 are almost perfect, however, are missing a crucial (but easy to fix) element. The author fails to mention (close to his final step) that under "firewall: NAT: Outbound": https://192.168.1.1/firewall_nat_out.php After doing all the steps for NAT (set it to"manual" and hit "save" followed by "apply"), you need to edit the mapping that has the description "Auto created rule for LAN to WAN " (the middle one, out of 3). Then change "Interface" to "OpenVPN". Or, if you followed his instructions on creating the extra interface "OPTn" (my was called "OPT1"), selecting "OPTn" will also work. I'm not quite sure why he suggested creating that extra interface "OPTn". BTW, the way I figured out the above is I first read http://doc.pfsense.org/Create-OpenVPN-client-to-TUVPNcom.pdf, which described the above instructions, about setting the mapping interface to "OpenVPN". Also, he mentions that his connection slowed down considerably on his virtual machine (he doesn't state his specs). But for me, using hyper-v, on a 50Mbit connection, I get full speed with a max CPU usage of 12% for a single client/connection –haven't tested out with more than 1 machines trying to access over OpenVPN. My specs: Windows 8 Pro (built in Hyper-v) i7 @ 2.66 12GB RAM 128GB Crucial SSD Intel PRO/1000 PT Dual Port Server Adapter Used Zootie's hyper-v iso (I didn't apply any patches he lists a couple posts down) http://rapidshare.com/files/1592931654/pfSense-LiveCD-2.0.3-PRERELEASE-amd64-hyperv-kernel-20130119-0048.zip from here: http://forum.pfsense.org/index.php/topic,56565.msg309595.html#msg309595 Anyhow... I just finished setting this up, so I don't know how well this hyper-v build will hold up long term. And I'm planning on trying his 2.1 build next: http://rapidshare.com/files/4194997857/pfSense-LiveCD-2.1-BETA1-amd64-hyperv-kernel-20130119-0948.zip

If you don't need OSPF for other things (like routing in a big internal VPN network) then you should be able to do this without Quagga OSPF. You will have a gateway for each OpenVPN connection. Both gateways happen to be routes to the same LAN subnet at the other end - that is fine. You can use policy routing firewall rules (like you are trying already) to feed whatever traffic you like into whichever gateway. With no Quagga OSPF, the "strange" route for 10.0.11.1 that pushes that traffic down the wrong pipe will not be there.

@phil.davis: From the LAN rules, I don't think that you can reach 192.168.1.0/24 or 172.30.100.0/24 from the client LAN 192.168.2.0/24. The last LAN rule is directing it all into LoadBalance_Failover. I think this will work: a) Add an alias InternalNets for the networks 192.168.1.0/24 and 172.30.100.0/24 b) Add a rule before the last LAN to LoadBalance_Failover rule. Pass source LAN net, Destination InternalNets, no gateway. The packets for those internal networks should be passed straight out of the packet filter and use the normal routing table. Now is working. Thank you!!