Unexpected behaviour on bridged interfaces

alex11

I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass.

Why? Did you explicitly block them?

Yes, I do have an explicit rule dropping all traffic to RFC1918 subnets. Strangely enough, as per the logs this rule fires for all connection attempts but the one described as no. 3 in my original post.

BTW, even if I hadn't any explicit drop rule, the default drop rule would fire unless I have a pass rule?

chpalmer

@alex11:

Yes, I do have an explicit rule dropping all traffic to RFC1918 subnets. Strangely enough, as per the logs this rule fires for all connection attempts but the one described as no. 3 in my original post.

BTW, even if I hadn't any explicit drop rule, the default drop rule would fire unless I have a pass rule?

:)

Don't know. You haven't shared that with the forum here yet. Any rules at all? Keep in mind that rules affect incoming traffic on an interface. So each end of the bridge would have its own rules. Its got to be a configuration problem or misunderstanding on how rules work in this specific instance by you or yours or there would be loads of people including me complaining.

Asked by Derelict-

What are the settings for the net.link.bridge.pfil_member and net.link.bridge.pfil_bridge entries in System > Advanced > System Tunables ?

?? We all know what the article says but something could be different than you expect. Please look and report back.

Screenshots of your rules would be nice as well. ;D

alex11

Sorry, I cannot provide any screenshots right now, only a typed list of my rules:

The rules on the LAN interface are:

allow IPv4 UDP | 0.0.0.0 | * | 255.255.255.255 | 67 | * | none | (DHCP)
allow IPv4 TCP/UDP | * | * | 172.16.0.3 | 53 | * | none | (DNS)
drop IPv4/6 * | * | * | RFC1918 | * | * | none
allow IPv4 TCP/UDP | * | * | * | * | * | none
allow IPv4 ICMP | * | * | * | * | * | none

alex11

Re the pfil_* values: Currently I only have access to the backup xml file and there is no "pfil_*" entry in it. I reckon that means they have the default values…

chpalmer

Im going to guess this points at an alias. I believe you must have a config error in the way your alias is built.

drop IPv4/6 * | * | * | RFC1918 | * | * | none

Otherwise this rule is letting everything through-

allow IPv4 TCP/UDP | * | * | * | * | * | none

alex11

Correct, "RFC1918" is an alias for the three private subnets as per https://en.wikipedia.org/wiki/IP_address#Private_addresses. What I have in the xml file is
<alias>[…]

[…]</alias>

What puzzles me is that the RFC1918 drop rule works as expected but for this one case when I connect to the WAN interface's IP and port on which the VPN runs (e.g. in the examples 1 and 2 the rule works as it should). I have set up other aliases, both for IP ranges and ports, which also work fine. I am thus inclined to believe that my aliases are fine.

I am at my wit's end.

cmb

That kind of config with bridging isn't a good idea, with the same IP subnet on multiple interfaces. What's probably happening is that OpenVPN connection attempt hits your WAN rules, because that IP is showing up in the ARP cache for WAN.

alex11

@cmb:

That kind of config with bridging isn't a good idea, with the same IP subnet on multiple interfaces. What's probably happening is that OpenVPN connection attempt hits your WAN rules, because that IP is showing up in the ARP cache for WAN.

Thanks for the info. This supports my conjecture in the original post the the matter is rather a corner case than a misconfiguration, right? The fact that OpenVPN is reachable from the LAN is not a problem for me, I just don't understand it. By the same token, however, I would assume that other hosts on different sides of the bridged network might be able to connect to each other but the firewall rules work perfectly when restricting access from workstation 1 to workstation 2.

So, to rephrase my question: Can I be sure that the firewall rules work as one would expect for all traffic except that in which the WAN interface's IP is involved? That would be fine in my case.

Thanks!

alex11

Today I added an explicit block rule for traffic from 172.16.0.2 to 172.16.0.1 on the WAN interface and, voilà, OpenVPN is no longer reachable.

I do not quite understand this but I reckon it must have to do with what cmb posted even though I find it rather counterintuitive ;).

gcu_greyarea

That really is odd. Do you have a Floating Rule that might allow traffic from 172.16.0.2 to 172.16.0.1?

I agree with Derelict to put the IP on the Bridge Interface itself as opposed to one of the member interfaces. I also filter on the bridge (pfil.bridge=1) and not on the members.

I'm in a simular situation as you are in that I must bridge and there isn't much info available on bridged setups.

Since you OVPN Server is listening on 172.16.0.1:1194 there might be a chance that the OVPN Server is overriding the Packet filter… .??? And maybe this behavior is only exposed in bridged setups ? Possibly a bug?

gcu_greyarea

Which IF does the openvpn server run on? Bridge or Wan?

alex11

OVPN is configured to listen on all interfaces since I need it on two but apparently cannot specify 2 out of many. Hence I have it listen on all and block all but those two interfaces. However, the LAN and the bridge interfaces don't have an IP set.

Re floating rules: none configured whatsoever.

I am still in the dark wrt to this odd behaviour. However, since the firewall is in productive use I stick with the concept "never touch a running system" ;). Everything else seems to be working fine, though.

alex11

Things are going from odd to erratic ;).

I didn't touch the config since last week and on Friday everything was was described above. Then I turned on my computer this morning and, alas, pfsense did indeed block traffic to OVPN, coming from the LAN to the WAN interface.

Now I am utterly bewildered…?