Hi, I have a similiar configuration and have reconfigured my OpenVPN a few days ago according to this document : https://doc.pfsense.org/index.php/Multi-WAN_OpenVPN. It seems to be working. If I disconnect my first WAN connection on the OpenVPN Server side, the Client reconnects after a short time via the second link. If the first link is back up, when I disconnect the second link, the client switches back to the first link. With this configuration the client side won't reconnect automaticaly if the primary gets back online again..it stays on the second connection as long as it is available or until you reconnect the client side, but this is exactly how I want it to work.

The client is working just fine. I can't access my vpn server through the client interface. But you mean that it could be issues with sending tls packages within the client interface to my own vpn server? Still don't get why the traffic goes over random ports.. If I only could get it to use specific ports..

@networknut: Have you tried the connection by hostname and by the clients VPN IP to find out if the problem is the NetBIOS? Yes I have So it doesn't work in both ways? @networknut: I did a trick on my VPN server: I push the default route to the clients, but with a high metric, so it doesn't override the clients default route. So if windows has configured a gateway for an network interface it handles the connection as reliable. Can you be so kind as to provide an example of how you went about doing that? In the server advanced configuration section > custom options field I entered push "route-metric 512";push "route 0.0.0.0 0.0.0.0" However, the metric option entered here is also applied for any route, which are pushed to the clients, but no matter since there is no other route for this destination on the client with lower metric. So the route option could as well be set by entering "0.0.0.0/0" in the Locale Network(s) field above.

Are you running the wireless from PFSense or a wifi router? If using wifi from PFSense I am not sure, however I just setup a second network to do exactly what you want to do! It is wired though, would just need to add a wifi router.

@Derelict: Hmm. I have never had to reboot to get a change like that to take effect. Might have more to do with clearing existing states. Yeah I would have thought it didn't need one! But hey it works so all good.

My solution was 1) reinstall pfSense 2.24, 2) observe browsing and website response, 3) allow program to download and install current version. Repeat Step 2. Install security update 2.3.1_1. Repeat Step 2. PIA was configured per guide and modified instructions. Repeat Step 2. I can't describe it yet browsing 'feels' normal before upgrade to 2.3. Initial upgrade to 2.3.1 from 2.2.6 failed. IIRC it required 3 attempts. I didn't realize it but there were big changes to 2.3 from 2.2.x. IMO OpenVPN issues were triggered by incremental updates did not properly address PHP. Suggest reinstalling previous pfSense without configuring OpenVPN. Allow program to download and install current version, install security update(s), and configure OpenVPN. Hope this helps.

My solution was 1) reinstall pfSense 2.24, 2) observe browsing and website response, 3) allow program to download and install current version. Repeat Step 2. Install security update 2.3.1_1. Repeat Step 2. PIA was configured per guide and modified instructions. Repeat Step 2. I can't describe it yet browsing 'feels' normal before upgrade to 2.3. Initial upgrade to 2.3.1 from 2.2.6 failed. IIRC it required 3 attempts. I didn't realize it but there were big changes to 2.3 from 2.2.x. IMO OpenVPN issues were triggered by PHP. Incremental updates did not properly address PHP. Suggest reinstalling previous pfSense without configuring OpenVPN. Allow program to download and install current version, install security update(s), and configure OpenVPN. Hope this helps.

@Derelict: You could also try adding an IP alias VIP to Localhost on an IP network distinct from your LAN and include that address/network in the Local Networks of the OpenVPN Server. In the unlikely event you experience a subnet collision with LAN, you could connect to the localhost VIP instead. Less heavy-handed than redirecting all traffic through the tunnel if that's not what you want. Thank you for the reply/suggestions, Yes this situation has previously happened; I was told I could access my WAN DDNS link from anywhere so long as I make the correct rules in my firewall (for my VPN connections exclusively of course). I tried the VIP as such. 1.Selected IP Alias for the type 2. For interface I selected Localhost 3. Address type only allowed me to use Single address 4. I input my OpenVPN address for the Address section 5. Left Virtual Ip Password, VHID Group, Advertising frequency, and Skew blank/at defaults My connections can now access my hostname + domain link url to my pfSense box (previously wasn't able to); but I cannot put my DDNS link into the VIP, or access it still from its url. Can you guide me on your suggestion?

The OS routes in the routing table are not from iroutes, they are from the "remote network" definition or "route" statements in the OpenVPN server. If you want to move a site-to-site client from one VPN to another you have to change the override to the other server (if it was set to use just the old server anyhow) and you have to change the route/remote networks on the old and new server.

Thanks !

OK, my fault… learned somefink, anyway :-D

The config you state doesn't agree with the behavior you describe. With shared key, the server cannot push a route to the client side, so putting a "local network" on the server settings does nothing. You have to put that route in the client side Remote Network box. If that isn't working, there must be something else already defining that route. Either that, or you aren't really set for shared key, but SSL/TLS, in which case you could be missing an override with a remote network/iroute statement. It would appear from what you observed in the routing table that the client has a route for the server's LAN, but if that's the case, you can't be using shared key.