22.05.b.20220518.0600 OVPN Client problems
-
What did the OpenVPN status show (Status > OpenVPN)? The gateway status isn't always a good indicator.
Anything unusual in the OpenVPN logs?
IIRC there shouldn't be anything that fundamentally different with OpenVPN on the snapshot from the 13th vs today (especially non-DCO) but I may be forgetting something.
-
@jimp Yesterday (still on 22.05.b.20220513.0600) I made drastically changes to the firewall, for instance changed LAN to another NIC and stuff. Probably a bad idea doing it while on a Development Snapshot.
And it runs fine while I am still on 20220513, not so much if I am on 20220518.
So my config is hosed I guess, will have to stick with it for some time now and live with it. -
I note that the gateways that show off-line are all the same /24 along with one that shows on-line. Is is possible you have a conflict there? I assume they are /30 connections?
-
@stephenw10 said in 22.05.b.20220518.0600 OVPN Client problems:
I note that the gateways that show off-line are all the same /24 along with one that shows on-line. Is is possible you have a conflict there? I assume they are /30 connections?
They are all /24, but that is normal for those Privacy-VPNs and they are all working good in pfSense, like right now. The only problem with them is when they get the same IP (and with that, same Gateway).
Edit: Unless you changed there something in the last 3 days, I doubt that... has been working like that for years.
-
Hmm, so you have 4 interfaces with the same subnet but using different gateways inside that subnet. Are you sure the traffic for those is actually leaving across the expected tunnels?
I wonder if something that allowed that configuration was changed but not seen because having the same subnet on more that one interface is not supported.
I don't think it did.As long as nothing else in the subnet is required the more-spcific-route should apply.
Steve
-
@stephenw10 Just changed the last pic to a more used tunnel...
It works like this like forever. The privacyVPNs have tutorials for setting it up in pfSense and they are like this. I can't change the tunnel config anyways. -
Yeah, I understand. I'm not seeing anything that would have changed that might have stopped that working.
It's seen as invalid because if you tried to ping, say, 10.8.8.26 pfSense sees that as connected directly on 4 interfaces. It has no way to know which one to ARP on.
When you were on todays snap did you see any traffic on any OpenVPN tunnel?
Do you have any IPv6 configured on any of them?
Let me see if I can replicate it...
-
@stephenw10 To be honest right after testing that UPnP now is working for me, I noticed that I can't browse the web. Than that the gateway Widget made no sense to me and I saw this weird log entry I posted in the startpost. I decided that there is something fundamentally broken here and I "rolled" back.
Then I remembered that I changed al lot of the interfaces the other day... which are working fine.
I will take another look tomorrow, if there is any traffic on those OVPN interfaces but I am kinda sure that even "SSATVIE" wasn't working and that is the one my browser is using, so not much hope.
IPv6 is not supported by any of them. -
Ok, I've replicated that on a tunnel now. Were you seeing something like?:
May 18 17:16:51 openvpn 1424 Authenticate/Decrypt packet error: packet HMAC authentication failed
Steve
-
@stephenw10 So I "upgraded" again, only thing I find is this
May 18 18:46:04 openvpn 21814 Authenticate/Decrypt packet error: missing authentication info May 18 18:46:03 openvpn 77994 Authenticate/Decrypt packet error: missing authentication info May 18 18:46:03 openvpn 59187 Authenticate/Decrypt packet error: missing authentication info May 18 18:46:03 openvpn 39525 Authenticate/Decrypt packet error: missing authentication info
Everything looks good though
But non of it is working
Even if I say, don't monitor, treat as up anyway, nothing is going through. -
Yes, there's definitely an issue. We are pinning it down now...
-
@stephenw10 Wow, would be great, everything else is working, like Wireguard or my own OVPN-Server. I will go back now to check if "Authenticate/Decrypt packet error: missing authentication info" is just normal log noise for me. Also disabling all but one OVPN Client gateway didn't helped.
Edit: Going back now takes only seconds, that is a plus.
But I wonder, can I still see logfiles from the time before? If no, "Authenticate/Decrypt packet error: missing authentication info" is "normal" in my case.
Even when I am rebooting with 20220513 I have the feeling the OpenVPN Clients have to be restarted by me, but then they are working fine. -
If that is the case then that's something different. Clients connect fine at boot here if they are able.
Looks like an upstream issue was pulled in and appeared in Tuesdays snaps. We are testing now....
-
Today I made another attempt (this time 22.05.b.20220520.0600) and no problem, as if it never existed.
-
This post is deleted!