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!!

Here is one possibility - I do something along similar principles at one site.
a) Give all your clients DHCP from pfSense, allocate static mappings for the clients so you know who is which IP.
b) Make an alias for the IP addresses that you want to use the DD-WRT router OpenVPN path - let's call it DDWRTclients
c) Add a gateway on LAN - address of DD-WRT router - let's call it DDWRTgateway
d) Add a firewall rule on LAN - Source = DDWRTclients, Port = any, Destination = any, Port = any, Gateway = DDWRTgateway
e) Turn on manual outbound NAT, add a mapping Source = DDWRTclients, Port = any, Destination = any, Port = any, NAT Address = LAN Address
f) Turn off DHCP server on DD-WRT

The DDWRTclients will send their packets to pfSense. pfSense will route them across to the DD-WRT router, and will NAT them on the way back across your LAN to the DD-WRT. As far as the DD-WRT knows, the packets have a source IP of the pfSense LAN address. When the replies come back, the DD-WRT will send the replies back to the pfSense, the pfSense will unNAT them and deliver them to the correct DDWRTclient. (The NAT bit ensures that pfSense sees the packets in both directions - and thus maintains its state table nicely for those flows)

Now you can port forward ports from pfSense WAN to whatever DDWRTclient systems you like. When external connects are established from pfSense WAN into a DDWRTclient, pfSense should know about those as established flows. It won't try to NAT the responses back through DD-WRT router - it should send them across pfSense WAN, where the connection originated.

Just saw it. The rule in OpenVPN that I added back was only for UDP.

I had tried a traceroute and then an nslookup. NSlookup worked, UDP.
Changed the rule to TCP/UDP and we are back.

Thanks again.

The server errors are really old and I do not think related to your current problem, so I will ignore them.
It seems that the client is simply not getting through to the server at all.

Mar 13 10:48:38  openvpn[12597]: UDPv4 link local (bound): [AF_INET]10.60.3.21 Mar 13 10:48:38  openvpn[12597]: UDPv4 link remote: [AF_INET]192.168.31.34:1194

From the above, the client is correctly bound to a LAN IP at Branch2.
For some reason it thinks it should connect to the server on 192.168.31.34 - which is a private IP. Unless you have setup a completely private test environment, then that is not a valid address of the server.
If the client is setup correctly, with an extra "remote" statement in the advanced box, then the client log should cycle around about every minute trying
"UDPv4 link remote: [AF_INET] n.n.n.n:1194" and
"UDPv4 link remote: [AF_INET] m.m.m.m:1194"
where n.n.n.n and m.m.m.m are the 2 WAN IPs at the server end.
Both those server WAN IPs should be port-forwarded to LAN on the server end, where the server should be listening.
What did I misunderstand about your setup?

thanks that has fixed my problem  :)

@m9820441:

This is an interesting case as I'm suffering from exact the same issue.
Could you please elaborate more in detail how you fixed this?
More specifically : what has to be done on the remote side for routing?

Thx

You just need an additional Phase 2 entry on both ipSec site pointing to the OPenVPN network. So on your site it the local network will be the openVPN network and on the remote site the remote network will be your openvpn network.

Cheers,

@phil.davis:

Can't I just add two rules under the default rule on WIFI1? I.e., two not-rules just over/under each other?

Any special rules need to go before (above) the more general rules. The rules are checked from top to bottom, and the first match is what counts. If you put 2 rules on WiFi1
  (a) (destination !LAN) to WAN_DHCP
  (b) (destination !WIFI2) to WAN_DHCP
then:
  (i) traffic from WIFI1 to WIFI2 matches (a) - so it gets routed to WAN_DHCP
  (ii) traffic from WIFI1 to LAN matches (b) - so it gets routed to WAN_DHCP
not what you want!
The rule on WIFI1 needs to be
(destination (!LAN and !WIFI2) to WAN_DHCP)

For that, you need an alias that covers LAN and WIFI2 together, and use (destination !alias) in the rule.

Wouldn't it be clever to implement AND, OR into the pfSense ruleset right away to be able to use them within the firewall rules? I think this would make sense, because the two dimensional matrix layout (aliases) doesn't suit very well for a three dimensional problem (single host aliases, groups of hosts, groups of groups meaning different layers).