@Bob-Dig thanks for the interesting hint, tagging looks like a great feature! So basically I am tagging all (!) my current rules in the LAN section where I define which traffic is allowed and that it goes through the OpenVPN gateway. And the I setup a rule which rejects all traffic which is tagged and goes to WAN, correct? How do I make sure that the only connection the pfsense can do itself will be to VPN Providers DNS and OpenVPN Servers? As far as I understand this can also be done via "floating rules": Floating Rules can: Filter traffic from the firewall itself Filter traffic in the outbound direction (all other tabs are Inbound processing only) https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html [...] -Tom

Finally figured it out. It put the any/any autocreated rule in the OpenVPN category under firewall rules. I had to add a new interface assignment for the OpenVPN server and move the rule to be bound to that interface specifically in order for policy based routing to work correctly.

@Rico thanks its working now

Found the issue - my own stupidity. At some point in the past, I had put my ip in as a host override in the dns server settings. Doh!

What's the question? I assume you can connect to the OpenVPN-Server fine but you cannot connect to things on LAN right? If that's the case, turn the OpenVPN-Interface into a TAP interface (L2), then turn LAN into a bridge, adding the OpenVPN-TAP-Interface and the LAN-NIC to the bridge. Restart the OpenVPN-Server, export the OpenVPN-config to the phone again, refresh and reconnect. Now the phone should get an ip-address and be bridged into the LAN, problem solved. (This can take a few seconds if STP is enabled on the bridge). The other option is to use a TUN interface. The downside here is that stuff like broadcasting is not working. Nevertheless you can go down two routes: Easy route: Give the VPN-Clients a different subnet, e.g. 10.1.1.0/24 and route them to the LAN-subnet. As the LAN uses pfSense as default gateway, LAN is able to find the way back. Hard route: You use brouting to make this happen. You have to understand that routing and subnetting are NOT the same. So on the LAN-Interface you have 192.168.0.0/24 as subnet and 192.168.0.1/24 as ip-address. On OpenVPN's TUN interface you have 192.168.0.241/24 (YES, 24) as IP-address. Also you hand out IP-addresses in the range of 192.168.0.240/28 to the clients. You add a static route of 192.168.0.240/28 to the tun interface (YES, THE INTERFACE) and enable proxy ARP for the interface. Now a client dials in via tun interface, gets an IP-address in the range of 192.168.0.240/28 and the firewall proxies the arp requests from one site to the other. As it knows what's going on, it magically copies the packets back and forth and you're a happy camper. You need to understand what this does, how proxy arp works and that you can get yourself into a lot of trouble if other networks exist and you haven't configured this correctly. KR, G.

Hello The first routing that you posted, which pfSense is that? A? B? maybe C? The first routing I posted got in the Pfsense Web interface "PfSense->Web-Interfaces->Diagnostics->Routes" Yeah. Nevermind. I give up. I asked you on which machine you got this routing table and still you are not able to provide that information. Have fun figuring this out, but I'm not gonna waste my time here. Maybe paid support will get you anywhere. They can help you here: https://www.netgate.com/support/ Nice talking to you! Have a nice day! KR, G.

I try to sniff the packets to see whats going on. Bfo

@Grimeton It seems to monitor the correct address of my WAN. Did you mean add the actual VPN server's IP as a monitor IP for the VPN gateways? Also, just had another disconnection and the only new lines in the logs are these: [image: 1581419053252-screen-shot-2020-02-11-at-13.02.18.png] [image: 1581419753304-screen-shot-2020-02-11-at-13.11.01.png] The WAN gateway is always green and ok so the problem is probably that the dpinger pings the internal virtual IP of the VPN (10.8.x.x), instead of its server's actual IP, right?

@JKnott Thanks. I used the ip addy and user authentication.

You do not need to force all traffic through the VPN to reach your Domain Controller / AD. -Rico

@Grimeton said in Wierd OpenVPN client behaviour causing disconnections: Networking issues, followed by an ICMP package containing proto or port unreachable. ICMP package coming from me out to the server or vice versa? @Grimeton said in Wierd OpenVPN client behaviour causing disconnections: Networking issues causing OpenVPNs internal timer to timeout and disconnect/reconnect. What should I do in such case? EDIT: I've noticed that it usually happens when one of the VPNs in the VPN group (of 2) is going down (for maintenance or whatever) and because both/all of them are marked as Tier1 it may cause such reconnection attempts...on the other hand that's why we have VPN groups and Tier priority LOL

@Pippin According to NordVPN guys, the cipher thing is not an issue and their servers also support GCM. The fact that my choice of SHA512 is not recognized/mentioned in the logs is wierd though... @Pippin said in Constant disconnections and "Restart pause" in the system logs: Also, showing a fragment of the log doesn't help. It's not a fragment. It's the majority of it and it just repeats itself from time to time.

Sniff traffic on the pfSense side to check if the client can even hit your OpenVPN server. -Rico

@Gertjan you are correct. I will just set everything to go thru the tunnel and be done with it. Thanks for pointing these things out.

@Pippin no I have several (12) user each one with a specific routing...