Question regarding the internal "$INTERFACE net" alias & pf syntax translation

[sammy2ooo]

How comes that on the LAN interface the internal alias "LAN net" gets translated to 192.168.1.0/24 and on all other interfaces it translates to 192.168.x.1/24 (instead of 192.168.x.0/24 what I would have expected).

This is how my 6 interfaces are configured:

WAN	- NIC 0 
LAN - NIC 1 - 192.168.1.1/24 
DMZ - NIC 2 - disabled 
VNET - VLAN 2 on NIC1 - 192.168.2.1/24
WLANDMZ - VLAN 3 on NIC1 - 192.168.3.1/24
OPT4 - ovpns1() - 192.168.4.1/24

On the LAN tab within the firewall rule section I have this one defined:

Action: Reject, Log 
Proto: IPv4 *
Source: LAN net
Port: * 
Destination: any_local_network (alias that contains 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24) 
Port: * 

This get's correctly translated to (taken from /tmp/rules.debug):

block return in log quick on $LAN inet from 192.168.1.0/24 to $any_local_network tracker 1422306073  label "USER_RULE"

On the VNET tab I have this rule defined:

Action: Reject, Log 
Proto: IPv4 *
Source: VNET net
Port: * 
Destination: any_local_network (alias that contains 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24, 192.168.4.0/24) 
Port: * 

This however get's translated into:

block return  in log  quick  on $VNET inet from 192.168.2.1/24 to $any_local_network tracker 1422306076  label "USER_RULE"

Is this a bug or something I have missed? Thanks for clarifying.

[Derelict]

I see.  the 192.168.1.0/24 vs 192.168.2.1/24.

That is interesting and I wonder why it does that, but they both cover the entire /24 range. 192.168.3.254/24 would be the same thing.

I wouldn't call it a "bug" if it functions correctly.

[sammy2ooo]

I stumbled over this because I can't manage to block access to the firewalls webinterface (https://192.168.4.1) from the openvpn subnet (192.168.4.0/24) no matter what I try. OpenVPN is configured as an access server in tunneling mode. Here are the relevant rules.

# pfctl -sr | grep OPENVPN
pass in quick on ovpns1 reply-to (ovpns1 192.168.4.2) inet proto udp from <openvpnsubnet> to 192.168.4.1 port = domain keep state label "USER_RULE"
block return in log quick on ovpns1 reply-to (ovpns1 192.168.4.2) inet from <openvpnsubnet> to <any_local_network> label "USER_RULE"
pass in quick on ovpns1 reply-to (ovpns1 192.168.4.2) inet from <openvpnsubnet> to any flags S/SA keep state label "USER_RULE"</openvpnsubnet></any_local_network></openvpnsubnet></openvpnsubnet>

[Derelict]

What is the alias OPENVPNsubnet?

[Derelict]

What kind of OpenVPN server is it?  Remote access or site-to-site?

[sammy2ooo]

OpenVPN is configured as a remote access server in tunneling mode. I have assigned subnet 192.168.4.0/24 to it. The alias OPENVPNsubnet contains 192.168.4.0/24.

[Derelict]

Sorry.  I see you had already stated that.  You're not testing using an already-established state are you?

Clearing states doesn't make it function as expected?

[sammy2ooo]

I have tried rebooting the firewall, resetting the states, reloading the firewall rules several times, rebooting my iphone, but no luck. Now I cant access anything from the openvpn client anymore  :-[

Is it absolutly necessary to assign an OPTx interface to ovpns1()? I have just tried deleting the interface and stick with this very basic setup according to: https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server

The only difference is that I enabled

[code]Allocate only one IP per client (topology subnet), rather than an isolated subnet per client (topology net30).

The OpenVPN firewall rule tab contains an any to any allow rule. But now the firewall log shows many packets hitting the "Default deny rule IPv4" coming from the openvpn client.

[EDIT] Just found the culprit, there was a mistake in the any to any rule… let's call it a day...  :-\

[Derelict]

Are you using an OpenVPN assigned interface?  If so, rules on the OpenVPN tab are processed first.  When I use assigned interfaces I typically delete all the rules on the OpenVPN tab.

The attached rules do what I expect.  These are on the OpenVPN tab. 172.29.64.0/24 is my Remote Access tunnel network - topology subnet.


[sammy2ooo]

If I use an explicit block for the destination "The firewall" and HTTPs - access is denied properly. However I just dont understand why my "catch-and-deny-all-to-local-network" rule is not rejecting the access. See my point?

[Derelict]

It depends on what you want to do.  For instance, if you want to NAT on OpenVPN addresses, then you have to have an assigned interface.

Assigned interfaces give you a lot more granular control over who can do what.  Rules on the OpenVPN tab apply to all OpenVPN instances and are processed before rules on assigned interface tabs.  So, In general, if you use both the rules on the OpenVPN tab cannot match the traffic in question or the interface rule is never processed.

You're missing something.  This blocks the webconfig on 192.168.223.1:8883 the same as the This firewall rule.


[Derelict]

typo in your alias.  192.186, not 192.168.  Slow down.

(THIS is why we always insist on screen shots instead of simply a description of what users think they've done.)

[Derelict]

And always make your DNS rules TCP/UDP.  It's usually UDP but sometimes TCP (large responses, etc.  DNSSEC triggers a lot more DNS over TCP.)

[sammy2ooo]

awesome!! thanks a lot, that was really driving me nuts.  :o :)

[phil.davis]

This however get's translated into:
Code:

block return  in log  quick  on $VNET inet from 192.168.2.1/24 to $any_local_network tracker 1422306076  label "USER_RULE"

Is this a bug or something I have missed? Thanks for clarifying.

It is a feature  ;)

I don't think it effects the actual set of addresses that PF ends up matching for the rule, but it should be made neater and consistent with the way LANnet and WANnet are handled.
This does it: https://github.com/pfsense/pfsense/pull/1564