Unexpected behaviour on bridged interfaces
-
Hello forum,
I observed something which is quite inexplicable to me. Please refer to the attached PNG for a drawing of my network setup.
I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass. My observations, however, are as follows:
- Connection from [172.16.0.2] to [172.16.0.3:1194/UDP] dropped and logged as expected.
- Connection from [172.16.0.2] to [172.16.0.1:5000/UDP] dropped and logged as expected.
- Connection from [172.16.0.2] to [172.16.0.1:1194/UDP] successful.
The last result puzzles me. Why would the LAN interface allow a connection to the WAN's IP if it is configured to drop any packets to an RFC1918 IP?
Is it some weird corner case? Or has it to do with the bridging mode which under the hood works other than one would expect?
Thanks for any help.
-
No idea what you're trying to do there with WAN and LAN on the same subnet and it looks like you have WAN and LAN bridged with workstations on both sides.
-
No idea what you're trying to do there with WAN and LAN on the same subnet and it looks like you have WAN and LAN bridged with workstations on both sides.
This diagram is massively simplified and is only meant to give you an example of what the issue is. Think of workstation 1 as the router to the public internet and pfSense acting as a VPN server. I don't like the setup much myself but there are boundary condiitons beyond my power which force me to choose this configuration.
And bridging a subnet across a firewall may be unusual but is imho a legit means of managing traffic.
-
When I have to make a bridge I generally put the IP address on the bridge interface itself.
What are the settings for the net.link.bridge.pfil_member and net.link.bridge.pfil_bridge entries in System > Advanced > System Tunables ?
-
I stuck with the standard setting as mentioned here
https://doc.pfsense.org/index.php/Interface_BridgesI do understand the difference to my configuration. However, filtering traffic on the bridge interface itself sounds like a workaround which is perfectly fine. Nevertheless, I would like to understand what the matter is with my setup, simply for the sake of understanding :).
-
I assume that the LAN interface should not allow any traffic to an RFC1918 network to pass.
Why? Did you explicitly block them?
-
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?
-
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
-
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 -
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…
-
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
-
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>[…]<address>10.0.0.0/8 172.16.0.0/12 192.168.0.0/16</address>
[…]</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.
-
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.
-
@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!
-
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 ;).
-
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?
-
Which IF does the openvpn server run on? Bridge or Wan?
-
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.
-
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…?
