Question about broadcast address traffic within a subnet
-
I am very new to pfSense and have an elementary question about how pfSense handles broadcast traffic within a subnet. Let me explain. I have set up a wireless access point interface which I call WIFI. This is a physical interface and not a VLAN. The subnet is 192.168.4.0/24. The access point is assigned a static IP of 192.168.4.2 and my wireless clients receive DHCP addresses over the range of 192.168.4.100 - 192.168.4.254. I am attempting to lock down this interface so that it does not communicate with the more sensitive parts of my network. After allowing for some port exceptions, I wrote a rule to block all destination to private addresses (RFC1918). While reviewing my firewall log, I noticed that this block rule was blocking WIFI net client communication with 192.168.4.255, which I have come to understand is a broadcast address. I had to write a specific allow rule to allow this communication. I was surprised by this because I had assumed that all communication within a given subnet did not pass through pfSense and was allowed by default. Is 192.168.4.255 not within my subnet? Why is my block rule blocking it? I apologize in advance for such a neophyte question.
-
No response to my query after 3 days?! Come’on, there has be someone out there willing to help out a newbie. Where are you johnpoz?
-
Post screenshots of your rules
-
@NogBadTheBad said in Question about broadcast address traffic within a subnet:
Post screenshots of your rules
I certainly will. Currently at work but will post when I get home later today. Thank you very much for your time!
-
You can drag screenshots into the message, here's what a simple internet only set of rules would look like:-
n_ip_local is an alias with all my local subnets defined.
-
@NogBadTheBad said in Question about broadcast address traffic within a subnet:
Post screenshots of your rules
Ok, here are the screenshots. Since my initial post I also discovered that the block rule in question is also blocking the ability of my access point (statically assigned to 192.168.4.2) to communicate with my interface firewall address of (192.168.4.1). I guess I can somewhat understand this as this does require communication with the firewall. Still, I thought that this communication was allowed by default because they are on the same subnet. Thus the first two rules in my screenshot address these two issues, communication with my firewall (192.168.4.1) and communication with the broadcast address of 192.168.4.255:
The next screenshot is the detail of my alias for RFC1918 so that you can review that it is correct:
The next screenshot demonstrates the blocking message that is listed in my firewall log when I disable the second rule to allow communication with 192.168.4.255. Notice that clients 192.168.4.112 and 192.168.4. 109 are blocked from communicating with 192.168.4.255. Also notice that the rule causing this block is my block RFC1918 rule:
My last screenshot is showing the same firewall log when I disable my first rule which allows communication between my access point (192.168.4.2) and my firewall interface address (192.168.4.1):
I should state that I have not identified any problems with or without my first two rules. I actually am not sure how important it is that my subnet clients can communicate with the subnet broadcast address or that my access point can communicate with my firewall interface address. My main purpose for posting this is to develop a better understanding of how pfSense functions so that I can more confidently construct the appropriate rules. Thanks again.
-
#1 Use WIFI address in the destination, makes things more readable
and from your logs it just looks like ICMP traffic.#2 You don't need this rule what so ever it's netbios and Spotify traffic thats broadcast to 192.168.4.255, the firewall won't do anything, you might as well set it to block and not log.
I'd suggest checking out the port numbers.
https://www.speedguide.net/port.php?port=138
https://www.speedguide.net/port.php?port=57621
#4 I'd be tempted to look at what ports are actually used by logging on that rule, then add the ports.
#7 Why is the gateway WAN_DHCP, is the default route out your PIA access, I'm guessing it is and you haven't enabled Don't pull routes in the OpenVPN client setup.
I'm also guessing you've had to set the gateway for all the other interfaces as well.
-
@NogBadTheBad said in Question about broadcast address traffic within a subnet:
#1 Use WIFI address in the destination, makes things more readable
and from your logs it just looks like ICMP traffic.Will do. Doesn't the log also show some UDP traffic here as well?
#2 You don't need this rule what so ever it's netbios and Spotify traffic thats broadcast to 192.168.4.255, the firewall won't do anything, you might as well set it to block and not log.
I'd suggest checking out the port numbers.
https://www.speedguide.net/port.php?port=138
https://www.speedguide.net/port.php?port=57621
Not sure about this. Might need the broadcast address for Spotify. I haven't tested this yet but Spotify allows for switching output to multiple devices. This might be needed for Spotify to search for those devices.
#4 I'd be tempted to look at what ports are actually used by logging on that rule, then add the ports.
Completely agree. My initial attempt to narrow down to a few ports failed. This is a multifunction device including scanner. Apparently multiple ports are involved. Going to take some time to figure this one out.
#7 Why is the gateway WAN_DHCP, is the default route out your PIA access, I'm guessing it is and you haven't enabled Don't pull routes in the OpenVPN client setup.
I'm also guessing you've had to set the gateway for all the other interfaces as well.
You're partially correct. I did make the mistake of not enabling "Don't pull routes..." when I initially set up PIA but later corrected that mistake. I guess I just left the gateway specified as WAN_DHCP. Is there any reason that I should switch to the default value?
Thank you very much for your feedback! I am still left with the unanswered question of why pfSense is not automatically allowing for broadcast traffic on the same subnet.
-
@wanabe said in Question about broadcast address traffic within a subnet:
Will do. Doesn't the log also show some UDP traffic here as well?
Yes Spotify that I mentioned, look at the port numbers.
You're partially correct. I did make the mistake of not enabling "Don't pull routes..." when I initially set up PIA but later corrected that mistake. I guess I just left the gateway specified as WAN_DHCP. Is there any reason that I should switch to the default value?
Depends on which interface the majority of the traffic goes out, you'll need to change every rule that you want to go out the WAN interface, makes more sense to policy route PIA traffic rather than WAN traffic
I have 45+ rules on my various LAN interfaces, if I had the PIA as the default route I'd have to change 45+ rules rather than the 1 rule.
I am still left with the unanswered question of why pfSense is not automatically allowing for broadcast traffic on the same subnet.
The only broadcasts of interest to pfSense would be dhcp requests and they are sent with a destination of 255.255.255.255.
-
@wanabe said in Question about broadcast address traffic within a subnet:
Might need the broadcast address for Spotify
Not sure why think you needed to allow it? You were logging it, because your rfc1918 alias would include directed broadcast which is what 4.255.. Your rule could just as well be block, just don't log it.
Pfsense isn't going to do anything with that traffic anyway.. So it doesn't matter if you allow it or block it - you just want it not to be logged.
BTW - I didn't notice this thread, if you want to call someone to a thread you have to use the @ in front of their nic..
-
@NogBadTheBad said in Question about broadcast address traffic within a subnet:
@wanabe said in Question about broadcast address traffic within a subnet:
Will do. Doesn't the log also show some UDP traffic here as well?
Yes Spotify that I mentioned, look at the port numbers.
I'm sorry, I thought this comment was directed at the logs for rule #1. I see that that many of the communication attempts are ICMP but there is also some UDP traffic to port 137 which my research says is for NETBIOS. Port 57621 is the Spotify port and it applies to rule #2.
You're partially correct. I did make the mistake of not enabling "Don't pull routes..." when I initially set up PIA but later corrected that mistake. I guess I just left the gateway specified as WAN_DHCP. Is there any reason that I should switch to the default value?
Depends on which interface the majority of the traffic goes out, you'll need to change every rule that you want to go out the WAN interface, makes more sense to policy route PIA traffic rather than WAN traffic
I have 45+ rules on my various LAN interfaces, if I had the PIA as the default route I'd have to change 45+ rules rather than the 1 rule.
Agree, my default route is now WAN_DHCP. Again, I just have not gotten around to changing it back to default.
Again, I deeply appreciate the time you have taken to review my query!
-
@johnpoz said in Question about broadcast address traffic within a subnet:
@wanabe said in Question about broadcast address traffic within a subnet:
Might need the broadcast address for Spotify
Not sure why think you needed to allow it? You were logging it, because your rfc1918 alias would include directed broadcast which is what 4.255.. Your rule could just as well be block, just don't log it.
Pfsense isn't going to do anything with that traffic anyway.. So it doesn't matter if you allow it or block it - you just want it not to be logged.
BTW - I didn't notice this thread, if you want to call someone to a thread you have to use the @ in front of their nic..
Let me start off by saying that I have nothing but tremendous respect and admiration for the work that you do on this forum. I have lurked here for many months and have read hundreds of your posts. I don't know how you manage to respond to so many questions. Unfortunately, your response makes me realize that I have failed miserably in explaining the source of my confusion. I have no doubt that the failing is mine and due to my inexperience. Let me make another attempt. What I don't understand is why my rfc1918 alias block rule blocks 192.168.4.255 and not the other addresses on my subnet. For example, this rule does NOT block my attempt to login to my access point which has an address of 192.168.4.2 from my iphone which has an address of 192.168.4.112. As a matter of fact, I actually tried to construct a rule to do just that and discovered that I could not because the communication did not pass through pfSense but instead passed directly from iphone to the access point because they were on the same subnet. If this is true, then why does my rfc1918 alias rule block communication between 192.168.4.112 and 192.168.4.255? Are they not on the same subnet? This is the main question that I am trying in vain to answer.
-
@wanabe said in Question about broadcast address traffic within a subnet:
For example, this rule does NOT block my attempt to login to my access point which has an address of 192.168.4.2 from my iphone which has an address of 192.168.4.112
How could it... They are on the same network.. Why would phone at 4.112 talk to pfsense to talk to another IP on 192.168.4.X?
then why does my rfc1918 alias rule block communication between 192.168.4.112 and 192.168.4.255?
Because its a BROADCAST, and pfsense sees that, because it goes out to all mac address.. Not just the mac address of 4.2..
Here is sniff of me sending a ping to 192.168.9.255, which is the directed broadcast address for my 192.168.9.0/24 network.. See the all FF mac - this means anything on that layer 2 network, so pfsense sees it..
When 192.168.4.x wants to talk to 192.168.4.y it arps for the mac address of 192.168.4.y, and then sends the traffic to that mac address! Which would not be pfsense interfaces mac address... So pfsense never sees that traffic - only 4.y would see that traffic.
When you broadcast and send to mac of all FFs - switch would sent that traffic out all ports, ie everything on that layer 2.. Which pfsense interface is - so it sees it.. That is in the rfc1918 space you blocked, so its blocked and logged as you told it to do. But even if you didn't do anything with it.. Pfsense wouldn't really do anything with that traffic anyway - it can not route it.. if its not traffic that interests something running on pfsense - it wouldn't do anything with it.. Now if it was a ping, it might answer it.. etc..
example when I pinged the broadcast, I got answers back from both .99 and .98
$ ping 192.168.9.255 Pinging 192.168.9.255 with 32 bytes of data: Reply from 192.168.9.98: bytes=32 time=7ms TTL=64 Reply from 192.168.9.99: bytes=32 time=1ms TTL=64 Reply from 192.168.9.98: bytes=32 time=1ms TTL=64 -
Now we are finally getting somewhere! I understand why pfSense cannot block my iphone from communicating with my access point, they are on the the same network. But I still don't understand how pfSense can block the BROADCAST address if it is sent to ALL the addresses on my subnet. I understand that that the broadcast is also sent to pfSense and that pfSense sees it but is it not also sent directly to the other addresses on my subnet? If so, how does pfSense block it?
-
pfsense isnt blocking it.. its only blocking what was sent to it... It has no control over what other devices would see that traffic on that layer 2..
When you broadcast you send to all FF macs, when you send a directed ping, ie 192.168.4.Y - you would only send it to that specific mac address..
-
@johnpoz
So, what you are saying is that the other addresses are receiving the broadcast from 192.168.4.255? -
YES!!! and so does pfsense since its sent to all macs with that all FFs mac.
-
Here is ping to pfsense which is at 9.253 - see its mac!!
Then I send to 9.10 ping - see its sent to its mac.. not all FFs
Pfsense sees the one sent to its mac, it does not see the one sent to 9.10 mac.
-
@johnpoz said in Question about broadcast address traffic within a subnet:
YES!!! and so does pfsense since its sent to all macs with that all FFs mac.
Excellent!! I think that the information I was interpreting from the logs was the source of my confusion. It made it seem that pfSense was blocking the broadcast to all the addresses to my subnet but you are saying that is not actually happening?
-
Its sees the traffic since sent to all mac.. FFs -- says hey that rule says to block and log it..
But that doesn't stop all the other devices from seeing it..
