upgraded to 25.11 now inbound wireguard connection don't work.
-
This was all working with the exact same configuration prior to upgrade. (forget version but was latest update like 25.07.x or something like that.)
I have 3 tunnels configured.
- outbound tunnel with static endpoint to commercial vpn provider. ( works great before and after)
- inbound tunnel with dynamic endpoint used by my devices/phones. (works before but not after update)
- inbound tunnel with dynamic endpoint used to connect with a remote router (works before but not after update)
The rest of this will relate to configurations for tunnel 2 and 3 which are experiencing identical issues.
First. if i do a packet capture, i do see traffic trying to initiate a connection. but i see no responses.
My wan rule is set to log successful traffic:
i have no nat rules related to port 51821 (tunnel 2) or 51822 (tunnel 3)
But i do not see any traffic in logs->firewall
I really don't understand what is happening at this point. the update definitely changed how something works. but i don't believe i actually understand what is happening. my understanding is that if i receive a udp packet on my internet interface and have a wan rule to accept it. well, it should accept and log it. Even if the wireguard package doesn't see it.
What am i missing? If i can't figure this out guess i need to try and figure out how to downgrade a netgate 4200. i would love to understand how this is possible and fix it instead though.
-
@mikek If you go to package manager is there an update? My WG connections are working here after the upgrade..
-
and patches show:
-
@chpalmer said in upgraded to 25.11 now inbound wireguard connection don't work.:
@mikek If you go to package manager is there an update? My WG connections are working here after the upgrade..
question are any of your WG configurations set with a dynamic endpoint, my commercial vpn with a static endpoint works. it's all the rest that are jacked
-
@mikek Yes. Dynamic for both.
Im still weaning off OpenVPN for the rest but all working at this point.
-
@chpalmer it is an upgrade issue for sure, just rolled back to boot enviornment 25.07.1 and all my stuff started working again.
-
@mikek Are you using dynamic DNS or is your end box on a static?
-
@chpalmer said in upgraded to 25.11 now inbound wireguard connection don't work.:
@mikek Are you using dynamic DNS or is your end box on a static?
The "server" is using dyndns to track the ip used by the "clients". The "clients" are using random unknown addresses.
So on the "server" i set the pier to dynamic
and on the "client" i set the endpoint to the "server" dns name and port.Which means the connection can only be initiated by the client config since the endpoint is configured with a static entry.
-
@mikek Im curious if your "Server" Dynamic DNS updated correctly.. One can assume that your IP address probably did not change but you never know.. just trying to rule out the easy..
-
No problem here either so my guess is @chpalmer is right.
-
the packet capture show that the traffic made it to the server. that means it is not a dns issue.
-
@mikek True. You seem the only one with that problem though. Also you should reduce the MTU to 1420 on all of the WireGuard-Interfaces.
-
@Bob.Dig I KNOW! it sucks to be me right now.
what i can't wrap my head around is this. ignore wireguard completely.
i have udp traffic going to the wan interface on port 51821, i can see the traffic hit the interface. yet the rule which is set to log never logs that it accepted a packet. it's like the traffic is being intercepted by something else before it gets to the first rule on the wan interface.
so i think self what could do that.
- a nat would change the traffic. there are no nat rules for that port.
- a floating rule would execute first. there are no floating rules that have that port configured on it. except this one:
it's a match rule for qos. so should not stop or change the traffic as it relates to the wan rule
that's it. if there is something else that could intercept a packet between entry on the interface and the first wan rule. i don't know about it.
the exact config with the exact same rules works in 24.07.1 i would really like to know what bone headed thing i did to cause this. because like you state, i seem to be the only one reporting this. so it has to be something that happens automagically in 07 that no longer happens in 11. something that is "helping me out" before but not after.
-
@mikek Disable that match rule and see how everything is working again. Then check the changelog in regards to match-rules. If you are not satisfied, create a bug report regarding match-rules.
-
i am in a rolled back state on 27.07.1 right now, i am going to try the upgrade again sometime next week. i will try disabling the qos matching rule and see what happens. it's the only thing so far that i don't remember trying.
Thanks
-
@mikek I guess it is this.
https://redmine.pfsense.org/issues/16475 -
@Bob.Dig awesome! that sounds like exactly what i am experiencing.
seems that the bug is resolved with a statement that it is fixed in 25.11
I am not a network engineer by trade or anything like that, any hint on how to test this in a way to prove it is the same issue.
My guess would be to do the upgrade again, turn off quick match if it all works then turn it back on and it breaks would be enough.In light of this information, i may upgrade again this afternoon and do some testing see if this has an effect.
Any pointers on what type of information would be good to collect?thanks a lot for your help on this.
-
figured it out, for some reason i had my floating match rule set to any direction. which worked on <= 25.07.1 but with 25.11 somehow that just eats the traffic, it never makes it to the wan rule chain to be accepted. not sure if that is by design or a bug. Set the rule to wan interface out stops that behavior.
likely need to review/learn how to setup qos properly. i mean it seems to work, but if i found that what else do i have jacked up.
thanks for the help
Mike -
Did you have 'quick' set on the match rule? That should almost never be set on a match rule IMO.
-
@stephenw10 i did have quick set. but adding or removing quick had no effect.
changing the direction from "any" to "out" fixed it.
all things the same. having direction any on the rule works on 25.07 and below version.
on 25.11 version, with the rule set to any on the matching rule. the traffic stops.
i say it stops, cause i really don't understand what happens to it. but it never hits the wan accept rule.Really, I should not have direction any, and I don't think there is a need for quick match either on my floating rules. but because i was doing bonehead stuff. i discovered this.
I don't believe that having direction "any" should have actually caused an issue. and since this is a "less than optimal" configuration, not sure many people will see this behavior.
What i don't understand is why it broke, while it is not a "correct" configuration from a best practice perspective, i don't understand why technically setting the direction to any caused it to stop working.
