# at the break! - message in rules.debug if interface name is not optX

artooro

I found a strange issue from a config file that another user sent to me.
They said after upgrading to pfSense 2.5.1 their firewall rules that were set to a source of "GUEST net" stopped working.

Looking at their config file I noticed under <interfaces> that the interface name was <guest> when normally it would be something like <opt1>
So I reproduced the problem on my pfSense 21.02.2 box using the following XML config.

<interfaces>
    <guest>
        <if>mvneta0</if>
        <descr><![CDATA[Guest]]></descr>
        <enable></enable>
        <ipaddr>172.19.41.1</ipaddr>
        <subnet>27</subnet>
        <spoofmac></spoofmac>
    </guest>
</interfaces>

and a firewall rule example

<filter>
    <rule>
        <id></id>
        <tracker>1622153012</tracker>
        <type>pass</type>
        <interface>guest</interface>
        <ipprotocol>inet</ipprotocol>
        <tag></tag>
        <tagged></tagged>
        <max></max>
        <max-src-nodes></max-src-nodes>
        <max-src-conn></max-src-conn>
        <max-src-states></max-src-states>
        <statetimeout></statetimeout>
        <statetype><![CDATA[keep state]]></statetype>
        <os></os>
        <protocol>tcp/udp</protocol>
        <source>
            <network>guest</network>
        </source>
        <destination>
            <address>1.1.1.1</address>
            <port>53</port>
        </destination>
        <descr><![CDATA[Allow Cloudflare DNS]]></descr>
        <created>
            <time>1622153012</time>
            <username><![CDATA[admin@192.168.1.5 (Local Database)]]></username>
        </created>
        <updated>
            <time>1622163642</time>
            <username><![CDATA[admin@192.168.1.5 (Local Database)]]></username>
        </updated>
    </rule>
</filter>

With the above configuration I am finding this line in /tmp/rules.debug instead of the firewall rule.

# at the break! label "USER_RULE: Allow Cloudflare DNS"

Changing the firewall rule source to the subnet instead of the interface name resolves the issue.
Also changing the interface name in the config file to opt1 also resolves the issue.

Would this be considered a bug or expected behaviour? I have no idea how this user managed to have a config like this, maybe an older version of pfSense created these interface names?

Let me know if this is something I should report in redmine.

Gertjan

@artooro said in # at the break! - message in rules.debug if interface name is not optX:

at the break!

is already updated.

See here for more details.

@artooro said in # at the break! - message in rules.debug if interface name is not optX:

<interface>guest</interface>

Looks strange to me.
It's LAN WAN OPTx for all my setups.

@artooro said in # at the break! - message in rules.debug if interface name is not optX:

Would this be considered a bug or expected behaviour?

If you take in account that an 'admin' could have edited the config.xml file manually, probably both.

jimp

Likely undefined behavior. There is no way to make that happen in the GUI, and it is not a valid configuration. So whatever happens as a result is unpredictable. Not a bug, though.

artooro

Considering it used to work prior to the pfSense 2.5 would make me think it's a regression but on the other hand going back to pfSense 2.3 it's always created optX interfaces, so I'm assuming they manually edited the config during a restore from different hardware and it's just a fluke that it worked until now.

jimp

It can't be a regression if it was never supported behavior.

It may have happened to work by sheer luck, but that doesn't mean it would always work.

stephenw10

Mmm, it would be interesting to see the rules.debug section from their working firewall with that config. But, yeah, 'guest' is not a valid interface name in the config and never has been. They must gave edited it at some point.

Steve

AKEGEC

@jimp dude! you are famous. About 2017 controversy pfSense vs OPNsense in court.
https://www.youtube.com/watch?v=y8R5-xNeHY8