Bug in rules.debug if interface is down

[rcarr]

For me, this bug manifests with the $wan interface, but I think it might manifest for other interfaces given the right circumstances…

If you have a rule which refers to the IP address of an interface, and that interfaces is down and has no IP addr (e.g., $wan interface, configured for DHCP, but not connected to the network -- thus no IP), rules.debug hiccups, creating a commented out rule that starts with:

at the break!

followed by the label (if any) that you supplied.

For instance, this WAN anti-spoofing custom rule:

BLOCK on WAN if the source is "WAN address" and the destination is any, description "Block packets spoofing WAN IP addr (LAND attacks)"

If my DHCP-configured WAN interface is disconnected from the network, rules.debug will generate:

at the break! label "USER_RULE: Block packets spoofing WAN IP addr (LAND attacks)"

I think your code just assumes every enabled interface has an IP addr when it renders the XML.

Possible fix: instead of filling in the actual IP addr of interfaces when rules refer to them, use "($interface)" instead.  Let PF figure out the IP addr.

[sullrich]

Sometimes on bootup when the interface is not initialized it does this.  However it reloads the filter configuration at the very end of the bootup process which will correct this.

Let me guess, pppoe?

[rcarr]

Nope.  While I'm playing around with pfsense, I just happen to not have the $wan interface (DHCP) plugged in.

So I boot up with the $wan not connected and leave it like that because I'm not ready to put the pfsense box into production.  You're right that as soon as I connect the $wan interface and it gets its DHCP addr, the rule fixes itself in rules.debug.

I just think it's more correct to refer to an interface's IP addr by reference "($wan)" than by value.

[sullrich]

@rcarr:

I just think it's more correct to refer to an interface's IP addr by reference "($wan)" than by value.

You might be right.  Mind submitting a patch to change this behavior?