Firewall stopped working - uninformative error message

Nadar

I copied my 2.0.3 (amd64) VM to a "test VM" and upgraded that one to 2.1-RC0 (amd64). The 2.0.3 VM was shut down during testing. I removed all packages but the Open-VM-tools. I then played a little with the logging filtering, and changed some firewall rules to see the results. When I didn't get the expected lines logged, I suspected that the traffic shaper interfered with my logging and removed the traffic shaper.

From that moment on, the "warning notices" started saying:```
There were error(s) loading the rules: pfctl: DIOCADDRULE: Invalid argument - The line in question reads [0]:

Nothing is logged in the firewall logs from that point on, and no traffic seems to get through. I can no longer reach my WAN at all. I've tried to undo/change things, but haven't succeeded in undoing the error.

The real problem here however, is the error message itself. How am I supposed to figure out what's causing whatever is not starting to start from this error? I don't know if this is specific to 2.1 or just happened by chance when I tested 2.1\. I still have no idea what's causing it, other than that it probably has something to do with the traffic shaper. I have nothing defined under any of the traffic shaper tabs at this point.

A little sidenote: I like the new firewall logs, especially that you can trace which rules generates what line, but: I haven't figured out how to translate the rule numbers from the log into the actual firewall rules. Is it something I've missed here? It would be nice to be able to actually see the rule numbers in the "rules" interface. I'd also like if you could choose if the different filter arguments for the firewall log would be AND'ed or OR'ed together. It seems now like they are always AND'ed, and that makes it difficult to for example track all traffic to and from a particular host - like you could with the old filter.

phil.davis

Look at /tmp/rules.debug for the stuff that is being fed to configure pf. I guess there must be a line that is missing a lot of something and is invalid, hopefully it stands out. Then we can work out how the GUI let you edit/delete settings in way for that to happen.
pfSense adds a lot of stuff "under the hood" in addition to the user-defined rules that you make on the GUI, and sometimes what is 1 rule to the GUI or a GUI option results in multiple rules in pf. So it would be non-trivial to map the pf rule numbers back to the GUI-based rule or option that is the reason for the pf rule. But obviously it is not impossible, it is a computationally solvable problem if someone wants to put the effort into coding it - am I right?

Nadar

I don't know what rules.debug is, for a long time it seems like a config file, but then it ends abruptly with```

VPN Rules

ERROR! Unable to determine remote IPsec peer address for xxx.xxx.xx

anchor "tftp-proxy/*"


The error itself isn't strange, since I running the 2.0.3 VM as the actual firewall now and has created "dummy" NICs for the 2.1-RC0 VM at the moment without any real connection to anything. The remote IPsec peer address is a dyndns address, which for obvious reasons is unreachable. This can't be the actual error hindering the startup, since I was using the "real" NICs when this problem arose.

Is the rules.debug actually a log file, echoing every setting that is loaded? If so, why did it quit after failing to resolve an IPsec peer? That shouldn't be that "game breaking" should it? I've only used pfSense from the GUI up until now, so you'll have to guide me where to find further information…

phil.davis

# VPN Rules
# ERROR! Unable to determine remote IPsec peer address for xxx.xxx.xx
anchor "tftp-proxy/*"

rules.debug is the input configuration that is fed to the packet filter. On a working system of mine, the last things are the VPN Rules comment and the anchor statement, but I don't have the ERROR line in the middle. I don't use IPsec.
The message comes from filter.inc filter_generate_ipsec_rules(), after a call to ipsec.inc ipsec_get_phase1_dst($ph1ent)
You can look in the config.xml - do a backup and open the xml file in a text editor - for the ['ipsec']['phase1'] section. The code complains if ['remote-gateway'] is missing or does not seem valid.
But that ERROR message is a comment, so it should not cause a pf error. There should be something else "odd" in rules.debug that pf can't process.

Nadar

I think the IPSEC error is a dead end. Before the firewall stopped working, IPSec was working as expected. I'm not physically on the site now, so I can't give the "test firewall" the actual WAN interface without taking it away from the 2.0.3 version and thus taking away my access to the site, but the problem mentioned above arose while I was on site and it had the actual WAN interface connected.

I've done a diff on the rules.debug files from both the (working) 2.0.3 version and the 2.1. I really don't have the knowledge to judge what should be there and not, but I can't see any obvious error. There are quite a few differences caused by the IPv6 support with extra rules for that, and the inet/inet6 notations, the packet filtering isn't to be found in the 2.1 rules.debug (as expected, since I removed it from the GUI), but that is all as expected.

Isn't there a log file somewhere that can tell me what was the happening right before the error arose, so that I can get a clue about where in the debug.rules this happends?

Klaws

I might be that 2.0.x was more tolerant when it encountered a buggy rule definition. For example, some valid DiffServ Code Points were not accepted because if a bug in the dscp patch. pfSense 2.0.x apparently just ignored the offending rule. pfSense 2.1 immediately threw an error on the same rule (apparently also causing port forwarding to fail). In this case, however, the error message gave me the name of the offending rule

Okay, the dscp patch bug is fixed by now in the 2.1 branch.

You might try to check if disabling rules can lead to an "offensive rule".