openvpn client misbehaving

Derelict

Hmm. That's the default block rule. Something must be killing the state.

strangegopher

@Derelict you think it might be "Skip rules when gateway is down" option under System/Advanced/Miscellaneous?

Derelict

It would more likely be state killing on gateway failure. Are you having intermittent connectivity problems on that WAN?

Why did you mention suricata in the first place?

strangegopher

@Derelict I unchecked both "state killing on gateway failure" and “Skip rules when gateway is down” and created no_wan_egress tag for kill switch and I hope that will fix the issue. I mention suricata is because I saw other post here long time ago about it and I noticed it happen when I restarted suricata. Edit: It still happens without suricata enabled, so weird.

strangegopher

PF is still blocking openvpn but I have no idea what to do about this.

strangegopher

I created a bug report https://redmine.pfsense.org/issues/8541

Derelict

Not convinced it's a bug. Probably a misconfiguration somewhere. Just because it's a mystery right now does not mean it's a bug. Steps to reproduce from a plain install would be the first step.

strangegopher

@Derelict Should "Reset all states if WAN IP Address changes" be enabled?

Derelict

@strangegopher If that's what you want to have happen.

strangegopher

@Derelict Did a bit of reading about Asymmetric Routing https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules

I wonder if that is what is causing this.

Derelict

Could be. Do you have an asymmetric routing situation? Draw out the pieces involved and it's usually obvious. That can certainly be a cause of out-of-state blocks like you are seeing.

strangegopher

Finally figured out a workaround that limits the write TCPv4_CLIENT: Permission denied (code=13) message to 10 seconds max. I added keepalive 3 10; to custom options and I get this message for 10 seconds before ping-restart and then it connects. I have turned every setting I can think of on and off other than ramdisk and but for now I will live with this quirk.

strangegopher

fixed the error by changing to hostname instead of ip address, I compared the system logs and openvpn logs and noticed openvpn tried to connect before wan interface was up so I changed it to hostname, now it starts before wan is up but won't connect until it can resolve the hostname.

extra options:

remote-cert-tls server;
auth-nocache;
auth-retry nointeract;
tun-mtu 1500;
tun-mtu-extra 32;
mssfix 1400;
mlock;
pull-filter ignore "redirect-gateway";
pull-filter ignore "dhcp-option";

strangegopher

error came back but went away when I uninstalled pfblockerng-devel, only caused issues with tcp connections