According to this video https://www.youtube.com/watch?v=ov-xddVpxhc You can use firewall rules to exclude the hosts that you dont want to go through the vpn tunnel. So if you set static ip's for the hosts that use the vpn tunnel an make a firewall alias for the dhcp range and use this alias in a firewall rule which will pass the vpn tunnel and to go through the wan Wouldn't that work?

Jimp can you take a quick look at my other theard, basiclly the same issue but I noticed a change in routing table that effects my other vlans. i'm trying to understand what can cause the change in routing table. The "static" part is removed when openvpn dies, after it reconnects it's not replaced. I'm giving up on UDP for the moment, but i made more comments about that in the other thread. https://forum.pfsense.org/index.php?topic=145237.0 Before OpenVPN connection dies Destination        Gateway            Flags    Netif Expire default            10.75.1.2          UGS      pppoe0 PUBLIC-IP.static link#13            UHS        lo0 After OpenVPN connection dies. Destination        Gateway            Flags    Netif Expire default            10.75.1.2          UGS      pppoe0 PUBLIC-IP        link#13            UHS        lo0

Not a pfSense problem. You might want to consult your operating system or OpenVPN support/forums for that. (Viscosity tells me when I am disconnected…) Someone else might know. Personally I think you're overthinking it. I would figure out why your home pfSense is crashing. Mine never does.

I'm also using OpenVPN Connect 1.2.9 build 0 (iOS 64-bit) and there's no problem like that.

For anyone who stumbles across this thread, the solution was to add the OpenVPN connection as a Interface on the client side. After creating the interface, restart the OpenVPN service and add allow firewall  rules for the interface. For OSPF to work, you need to add the interface on both ends. It's also advised to remove/disable the default OpenVPN rules as they'll supersede the interface rules if matched first.

facepalm That was it! I added the rules to the Firewall and now does everything work as expected. Thanks for the right pointer  :)

Check the client log and post it here. Also look if there are entries in the server log.

You'd add that on your AD setup, not on pfSense. Look into AD-based multi-factor auth.

Do you have an example? Our configuration on six boxes started on pfSense 2.3.4 and i upgraded it to 2.4.2_p1 on all of them. I did not have to change anything on our OpenVPN configurations so far.

simples thanks very much, all sorted  :)

Can someone help  :'(

Looking for a solution  :'(

I have successfully set up 4 site with independent connections between each other (see attached).  

If you want all ethernet ports to have the VPN then it should do that by default.

@Rango: @Ryu945: Crypto-Dev by itself also did nothing.  I only got it to work when both were turned on. That's interesting. I now only have Crypto Dev on both sides and it boosts 20% so i can get 120Mbs on N3150 and medium is about 115-117Mbps but when i switch to only AES-NI it goes down by 20% to base line with is about 100Mbps which is what you see in screenshot above. I tried it every possible combination and that's what i'm getting. At least i'm happy Cryptodev is working and boosting a bit, 20%. Maybe if AES-NI would work it would boost much more. I dunno what the expectation of hardware based acceleration should be. I just reported what my testing yielded. I am happy with pfsense but it seems AES-NI module is not working and looks like Cryptop Dev is FreeBSD solution to it, for now maybe. Maybe in 2.5 this will change when they focus on it.  I can't wait if so. I am however disappointed i purchased N3150 however. I didn't do enough research then. The fact that i owned asus 87u also purchased for encryption. It is now exclusively AP. I guess as they say u learn on your own mistakes. I've learned. Thanks for posting your results. :) I did this AES-NI test with the version that came out before the Spectrum/Meltdown bug so I don't know if things have changed in the version I currently run.  I will have to run more test at a later time.  I did notice a massive speed reduction after that update.

1)  Do you have duel WAN working by itself? 2)  Just for a sanity check, is there a reason your using two WANs?

Thanks for the assist.  Turns out, I had to generate a new VPN profile for my client to get it working.  Editing the old VPN config (changing port numbers and IPs) did not work…

@Derelict: It works if it is positioned ABOVE the policy-routing rule in the interface rule set. Forgive me, I guess I mix up the terms… Please see attached screenshot, that is what I thought you meant by putting it on the WLAN interface. But now I made a new floating rule like the 2nd screenshot and it works, I guess that is what you meant is a more neat solution?   [image: Finale.PNG] [image: Finale.PNG_thumb]