@Derelict: Create another phase2 entry at both ends for the 172.16.5.0/24<->192.168.1.0/24 connectivity. Perfect, that fixed it. Thank-you!

Hi Derelict Thanks, I was just being an idiot. The connection is working. I changed protocol to any. J

Did you solve this problem?

Please, post the Quagga OSPF Interfaces screen shot.

awesome thanks! I did not notice the gateway advance setting button. Appears to be operational!

@cmb: Sounds like what would happen if you're maxing out your upload bandwidth on that connection, or if that connection has issues in general. Is it that high with the connection idle? It's idle. No further traffic goes over WAN2 when WAN1 is down. It's not a failover. Only UDP source port 27005 and some game client UDP destination ports are permanently sent through WAN2. The increased latency is always 500 or 999 ms + the actual route latency to be exact. Even when WAN1 is up and I'm playing a game, the game is going through WAN2. During this time the WAN2 latency is normal. If WAN1 fails, the latency goes up shortly. A related problem as mentioned in the linked thread is when WAN2 is down, the above rules don't fall back to WAN1.

Aaaaand nevermind. This was a case of too many cooks. Someone who shall remain nameless had changed DNS from all interfaces and made it on just the required interfaces. They added opt7, get this, yesterday. If I posted two days ago, I would've seen opt7 not selected on that list.

My test systems are on pfSense 2.2-BETA now, so I did: > pkg install whois That got me a program called "mwhois" - just like way back here in 2009: https://forum.pfsense.org/index.php?topic=14093.msg74950#msg74950 Then I can do: mwhois -h whois.radb.net -- '-i origin AS32934' | awk '/^route:/ {print $2;}' | sort | uniq > /tmp/facebook.txt and I get a nice list of IPv4 subnets in the file. I guess you can install the pfSense Cron GUI package and use that to add this command as a regular Cron job to keep the list as up-to-date as you wish. I don't expect that "mwhois" will cause any nasty side-effects on a pfSense - but of course there is no warranty when you manually install extra FreeBSD packages.

Hi, There's unfortunately no overlap. My DNS servers are: 208.67.222.222 - WAN1 208.67.220.220 - WAN2 208.67.222.222 - WAN3 208.67.220.220 - WAN4 I'm testing on WAN 3, which has these settings: Monitor IP: 95.174.20.211 (not used anywhere else) Latency Low: 20ms Latency High: 21ms Packet Loss Low: 1 Packet Loss High: 2 Interval: 1 Second Down: 3 Seconds By any stretch of the imagination, this link should fail, but it stays up with sometimes over 500ms of latency.

@Derelict: You'll have to look through ifconfig -a ,  /var/log/dmesg.boot , etc and see why it's not available for selection. You're awesome, Derelict. I will delve into that when I can next get my butt back near the machine.

The second SSID is on a bridge interface on DD-WRT with the IP of 10.0.0.11, pfSense has virtual interface with the IP address of 10.0.0.1, and an uplink gateway of 192.168.10.1. 192.168.10.1 is the wired LAN router that leads out to the internet. A route needs to be made for the guest wifi subnet 10.0.0.0 to go over the gateway of 192.168.11.1 right? You should not need to add any routes. When a client connects to guest WiFi SSID, it should be getting DHCP from pfSense only (DDWRT and WiFiAP should have DHCP off), and be given gateway 10.0.0.1 (pfSense). The pfSense virtual interface must have rules to allow traffic from its own subnet to the internet. Then the client packets will be allowed into pfSense and pfSense will route then upstream out WAN.

It can be done, with 1:1 NAT for the subnet, OpenVPN with assigned interfaces and the right set of rules. You will need to build a static key OpenVPN tunnel between the sites, assign the interfaces on both ends, and make sure to only have firewall rules on the assigned OpenVPN tab. If you happen to be a gold subscriber that is one of the topics I talked about in the "Advanced OpenVPN Concepts" hangout back in September.

No body have any idea ? ….  :'( :'( :'(

Are you using Firefox? If so, there were changes in a recent Firefox release that messed up the way it processes old certificates that you had made exceptions for (like the first time you go to pfSense webGUI. Posts like this explain how to clean up Firefox: https://forum.pfsense.org/index.php?topic=82828.msg458036#msg458036

As I understand, in the client system you bring up 2 connections to the external VPN server. These connections likely end up on different physical WANs (if the pfSense they go through is doing general load-balancing). Then using a download manager, the client starts sucking parts of a file, and each segment is going round-robin on those 2 OpenVPN links out of the client. Thus all segments in total can use the available bandwidth of both links. When you are doing a single segment only, it can only go over 1 link, so only single-link speed as you describe. "I believe you could setup 2 separate OpenVPN clients - 1 out gateway 1 to OpenVPN server A, another out gateway 2 toOpenVPN server B. Then make gateways for the inside of each of these OpenVPN links, make a gateway group out of them with equal tier. Then pass traffic on LAN into that gateway group. It should be load balanced across the 2 OpenVPN links." This is the same principle as what you have done on the client, just moving the OpenVPN client origin to be pfSense. There will be 2 OpenVPN clients on pfSense, attached to WAN1 and WAN2 respectively. Traffic is load-balanced (= gateway group with equal tier gateways) into the links. When you use a download manager,the segments will get spread around the available links, just the same as you have done directly on the client device.

As phil pointed out while /22 gives you the 192.168.2.0 to work with – Your other option would of been to just use 192.168.0 vs 192.168.2 -- so when you changed your pfsense lan IP from 192.168.1.x/24 to 192.168.1.x/23 you would of been fine talking to devices using 192.168.0.x/23 where pfsense IP would just be in the second /24 in the /23 mask.