Rule not matching after upgrade to 2.5.2
-
Prior to 2.5.2, I had a rule that uses an Alias as the source, and the WAN Address as the destination, with Port 500 (ISAKMP), and this worked fine to allow my IPSEC tunnels to form. Since upgrading to 2.5.2, I've had nothing but issues, and I think I've tracked it down to the rule no longer matching. When looking at the log for ^500$ as the destination port, I see all traffic, even from the allowed sources, hitting the Drop All rule instead of matching my allowed rule, which is above the Deny All rule.
I have tried using the specific IP, allowing ISAKMP from Any, etc, but I cannot get the rule to match on the firewall since upgrading. I have also switched to a different port, but no luck, still just smacks down to the Drop All rule. I even have gone so far as to delete the rule and manually recreate it, still no luck. -
screenshot of your rules ...
floating rules in use ?interfaces still the same ? igb0 still igb0 ? in other words WAN is still WAN and LAN is still LAN after the upgrade.
br NP
-
@noplan There are some floating rules from pfBlocker, but the log is calling out the Drop All rule specifically, which only exists on the WAN interface. In parathesis there is a number, 1579574159, which is unchanged so I'm assuming that's some rule identifier maybe? Anyway, literally, 2.5.1 everything worked, 2.5.2, no IPSEC tunnels. My WAN interface is still em0 after the upgrade, so that didn't change.
Is there some advanced logging I can enable to trace the packet through the firewall tables to see why it's not matching my rule anymore? I also had the thought that maybe it's because it's UDP, but I also have OpenVPN set for my mobile devices, and that uses UDP and has no issues.
Here's my WAN rules, you can see the Drop All way at the bottom, and the IPSec Tunnels all the way at the top (third from actually). I'm going to be changing everything back to the default ISAKMP (500/UDP) which has always worked prior to 2.5.2
-
@jlw52761 I also just updated to 2.5.2 and am seeing very similar things. It appears as though none of the changes I make to my firewall rules actually work. I’d really like to see if this is just a specific thing with our setups, or if this is a known issue.
-
@ludejim yeah, seeing the same thing like crazy, which is not good. I'm going to have to do more testing to be sure that it's not limited to just the IPSEC stuff, which wouldn't make much sense if it were...
I did delete the existing rule and create a new one, Any/Any source destination, port 500, and everything else open, and nope, the traffic is still dropping down to the Drop All rule all the way at the bottom of the chain. I even placed my allow rule at the bottom, thinking that maybe the order is reversed, but nope, the Drop All is still hitting. Some of the rules are still working though, but others are not, no real rhyme or reason. -
Ok, so this is where things get weirder. I have 3 firewalls in total, two that are running pfSense CE 2.5.2 and one running pfSense+ 21.05. So let's break it down like this
- FirewallA - pfSense CE 2.5.2
- FirewallB - pfSense CE 2.5.2
- FirewallC - pfSense+ 21.05
FirewallA is where I have been having my problems, and it is configured as reciever only on IPSec, that way, no open ports on the two remotes.
On both FirewallB and FirewallC, I created a rule to allow port 500 in to the WAN Address, and on FirewallA I set the IPSec to initiate. Wouldn't ya know it, things work, the rules are matching and everything is happy, sorta. I still do not know why FirewallA is having this problem, even after deleting and creating a new rule, and then we have the other poster having an identical problem with pfSense CE 2.5.2. I'm really confused at this point on what the correlation is here. -
@jlw52761 I ended up taking a backup, and then doing a fresh install of 2.5.2 (my other install was an update). I then restored my backup. It seems that fixed most of my issues, but I do have one host that has monitoring on it drop off the network pretty regularly when it never did before. I still feel like 2.5.2 is acting much different than 4.5.1 p1 (at least I think that’s what I was on). When I tried to install a fresh 4.5.1, it didn’t want to install any packages so it seems like I was forced to update.
-
@ludejim said in Rule not matching after upgrade to 2.5.2:
I tried to install a fresh 4.5.1, it didn’t want to install any packages
Did you set the update version/branch setting to the prior version?
