OPT1 state change - OpenVPN clients disconnect - DNS resolver drops for all
-
I am out of ideas of how to prevent traffic on all ports losing connectivity.
Problem:OPT1 interface from UP-> DOWN, then UP again (caused by network card with WOL network card).
All OpenVPN tunnels disconnect & reconnect 10 seconds from OPT1 interface goes down then upVPN 2 & 3 are setup in a Gateway group; Trigger Level Packet Loss or High Latency. I've increased VPN Gateways' intervales and thresholds up to 125%. Normal pings over VPNs are 150-190ms.
Logs seem convoluted, but I'm checking General, Gateways, Routing, DNS Resolver, pfBlocker Logs, and OpenVPN. OPT1 Interface State cycles back up at 18:25.19.
OpenVPN logs shows disconnects and reconnects about every minute for all tunnels (maybe normal, status shows connected since the interface cycle)...
pfsense General Log: https://pastebin.com/embed_js/itDR0Vww
pfsense Gateways Log: https://pastebin.com/embed_js/Mpc9n7Q6
pfSense OpenVPN Log: https://pastebin.com/embed_js/uYFa0t65
pfSense DNS log excerpt: https://pastebin.com/embed_js/kHr4hQ3uI've tried:
Changing Advanced~Miscellaneous~ State Kill on Gateway failure to 'Do not Kill...'
DNS Resolver already set to LAN interface only
Strict Outgoing Network Interface Binding changed to Do not send recursive queries out any outgoing interface
DNS Resolver: Python Mode Enabled
......What could I be missing?
-
It's doing it because rc,.newwanip gets called when the interface changed from unlinked/no-ip to linked/with an IP.
9/12/2023 18:19,php-fpm, php-fpm,71402,/rc.newwanip: Resyncing OpenVPN instances for interface OPT1.
Do you actually have OpenVPN instances on that interface?
Why is it actually unlinking? What's connected to igb2?
How is OPT1 configured? Does it have an IPv6 address?
You can likely work around this by setting OPT1 to trackv6. However that takes advantage of a different existing bug.Steve
-
Yes I saw that newwanip msg; odd it would be called for another port's state change? There is no reason for the WAN IP on pfSense to change and it has not been a issue in any other case.
For the OpenVPN instances 'on' the OPT1 (igb2) interface, I believe the only thing would be the 'firewall rules' gateway field that set the OpenVPN tunnel for all of OPT1's traffic(except a few specific ports, directed to individual clients on the LAN interface).
Each of the tunnel clients are created on the WAN interface only (I assume not related: I do have a OpenVPN server created on a unique port from the tunnels).
igb2 is hard-lined directly to pc1. For whichever reason, for PC1 to be WOL ready when PC1 is powering down it completely cuts power to the link, but reactivates link power 10+ seconds later; PC1 then can successfully power-up from WOL packets. I know it is unusual behaviour for PC1's NIC, but it is not the pfsense system as a different PC that was in PC1's place before did not do this.
OPT1 is static IPv4 only (no IPV6, IPV6=None), no upstream gateway.
-
Is the OpenVPN server configured to listen on 'any' interface?
If you can put a switch between igb2 and that PC? That would solve this.
However if you set OPT1 to track interface for IPv6 it will probably stop this happening. Even if you have no IPv6 on the WAN.