I spent awhile figure this about but eventually found someone that knew how to do it.  From what I understand, you already have the VPNs themself working so they only thing left for your to do is to have specific client going through specific VPNs.  To do this you need to have what you consider a default VPN providing internet to everything first.  I usually restart VPNs until this is working correctly and it seems to continue working but it may also happen to do with the fact my Outbound NAT has my default VPN rules above the other VPNs (i'm not exactly an expert on this). The next thing you need to do is to put a static address DHCP address on the clients you don't want to be using the default VPN.  This is done at status -> DHCP leases. Finally, you need to create a firewall rule that that forces those static address through those alternate VPNs and place them above your rule that normally allows clients to get internet.  If your static dhcp address for that client is 188.132.1.3 then the rule looks like: Interface: LAN Source: 188.132.1.3  (using single host or alias) Destination: any Gateway:<the name="" of="" your="" selected="" vpn=""></the>

Connections coming IN to an OpenVPN endpoint are firewalled using rules on the OpenVPN interface. If you want the remote site to only have access to certain hosts:ports, create firewall aliases/pass rules with those hosts:ports as the destination. In this example, 172.29.64.0/24 is my local OpenVPN server that only I can connect into, so it's far more permissive.  Everything else is from work site-to-site.  The local_vpn_hosts alias includes local IPs for a copier/printer, IP phone, etc, that the work VPN needs to initiate connections to. Note that my connections to the remote site are governed by rules on the remote site's OpenVPN interface.  

I have found the problem. In the Firewall - OpenVPN tab  I had the same rule:  from any to any  2 times , because I use DUAL WAN setup. The first rule was the one with DUAL WAN  gateway  instead of default gateway.  See picture attached. Regards, Adrian  

I believe this is resolved now.  I spoke with Jim P. and it sounds like I can create a LAN firewall rule and specify the source IPs and destination port, and then pick the Gateway specifically, and the traffic should go around the primary OpenVPN tunnel between the sites.

@jimp: The user's password is not stored in the clear on the firewall so what you're asking is not possible. Furthermore, storing user credentials is not recommended and not something we'll likely encourage. If you will store the user/pass you may as well not require it, leaving it only to have certificates for authentication (e.g. change mode from SSL/TLS + User Auth to only SSL/TLS) Good reply.  I didn't know I could just disable the password requirement and I appreciate that the passwords are not stored in plaintext on the firewall.  Thank you.

Oh, wait, I just thought of something.. Just to check, when you are running your VPN client are you running it as Administrator? This kind of sounds like the actual routes are being set on the client pc. If you are running it as an admin, would you mind posting a traceroute output going from the client to a machine on the other side of your vpn?

Is there nobody who want this feature? Regards, David

Make sure there's an any/any rule on your openvpn tab. Post your server1.conf.

yes, but I found the solution. The Firewall Rules are descending. They were in the wrong order. I found out by deleting and creating them manually again. Then aftwerwards I found the arrow icon to move the rules, gave myself a big slap on the forehead ::) But thanks for the help though

What are the firewall rules on site 2's openvpn interface?  Those determine what hosts at site2 are accessible via openvpn.

…on BOTH sides of the tunnel added? I have TCP/UDP and ICMP allowed for the tunnel, dunno if that makes a difference. Show us your openVPN log for the connection and check in firewall logs on both sides that nothing is blocked.

meh please delete this thread. I have figured it all out :) Thanks though!

I made some additional code changes to check the Framed-Route format to ensure it complies with the RFC. /etc/inc/openvpn.auth-user.php /** *  Convert Framed-Route format to iroute for the CCD file */ function FramedRoute($cidr) {     $baseip = substr($cidr,0,strpos($cidr, '/'));     $prefix = substr($cidr, strpos($cidr, '/') + 1) * 1;     $netmask = str_split(str_pad(str_pad('', $prefix, '1'), 32, '0'), 8);     $ipLong = ip2long($baseip);     if ( ( ($ipLong << $prefix) ^ 0) == true ) {         foreach ($netmask as &$element) $element = bindec($element);         return $baseip.' '.join('.', $netmask);     } } if (isset($attributes['framed_route'])) {         $iroute = FramedRoute($attributes['framed_route']);         if (!empty($iroute)) {             file_put_contents("{$g['varetc_path']}/openvpn-csc/{$username}", "iroute {$iroute}\n");             syslog(LOG_NOTICE, "user '{$username}' iroute '{$iroute}' created\n");         } } I'm creating static openvpn-csc file that could cause issues in the future. Should I be looking at, deleting the created openvpn-csc on client disconnect using the openvpn_resync_csc function

@scurrier: Two thoughts. How can it change your IP so fast while still allowing others to maintain a connection to you? It's pretty common, it wouldn't affect most things. How would someone on AOL Dialup for example maintain a connection? Have you tried disabling IPV6 on your phone?  On Tmobile there is a way to do this by changing your APN settings, I think. I'll give it a look.

As usual, the reason I could not get a pfSense feature working was an oversight on my part. I discovered and fixed the problem and now its working just fine. I had a 1 to 1 NAT on the secondary WAN's primary address that took over after I removed the port forward that was redirecting the OpenVPN port to where it was listening on my LAN. After moving that port forward to another virtual IP, everything works as designed. OpenVPN is now listening on my WAN Group. Failover to tier 2 and recovery to tier 1 now works flawlessly.