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!



  • @wanabe

    You can drag screenshots into the message, here's what a simple internet only set of rules would look like:-

    Screenshot 2020-01-21 at 15.28.19.png

    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:

    Screenshot from 2020-01-21 14-32-47.png

    The next screenshot is the detail of my alias for RFC1918 so that you can review that it is correct:

    Screenshot from 2020-01-21 14-38-15.png

    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:

    Screenshot from 2020-01-21 15-09-27.png

    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):

    Screenshot from 2020-01-21 15-09-59.png

    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.



  • 1579639897111-screenshot-from-2020-01-21-14-32-47.png

    #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:

    1579639897111-screenshot-from-2020-01-21-14-32-47.png

    #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.

    Screenshot 2020-01-22 at 20.20.55.png

    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.


  • LAYER 8 Global Moderator

    @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.

    Screenshot 2020-01-22 at 20.20.55.png

    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.


  • LAYER 8 Global Moderator

    @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..

    broadcast.jpg

    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
    


  • @johnpoz

    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?


  • LAYER 8 Global Moderator

    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?


  • LAYER 8 Global Moderator

    YES!!! and so does pfsense since its sent to all macs with that all FFs mac.


  • LAYER 8 Global Moderator

    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

    pings.jpg

    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?


  • LAYER 8 Global Moderator

    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..



  • @johnpoz My question is finally answered!! Thank you so much! I owe you a beer.


  • LAYER 8 Global Moderator

    No problem - glad I could help... I would suggest you read up on how traffic is actually sent on the wire.. its sent to a specific mac address.. when client wants to talk to 1.2.3.4, if that is on its own network, then it arps for it! and then sends the traffic to that mac address.

    When the IP is not on its local network it sends it to the mac address of the gateway (pfsense) pfsense sees this traffic since sent to its mac, and says oh hey that is meant to go to 8.8.8.8 or where ever. Do I have a route to this network? Then send it to the mac address of the gateway or the default gateway mac, if don't have direct route to get to network that 8.8.8.8 sits on..

    Traffic is only ever actually sent to a mac address

    Example here me pinging 8.8.8.8

    ping8888.jpg

    Notice the mac address is the mac address of pfsense 9.253.. as I posted earlier..

    this is how switches know which port to send traffic on, because the switch uses its arp table and says hey mac xyz is connected to port 4.. So sends the traffic out port 4, and not all the ports. When switch sees traffic to mac abc, and its not in the switches arp table - then it arps out all its ports, to find out which port that mac is on, etc..

    Once you understand how this stuff actually works ;) Then it all becomes easy to figure out what is wrong...

    example - is is the mac address table of my switch, and you can see what macs are on what ports

    sg300-28#sho mac address-table 
    Flags: I - Internal usage VLAN
    Aging time is 300 sec
    
        Vlan          Mac Address         Port       Type    
    ------------ --------------------- ---------- ---------- 
         2         00:08:a2:0c:e6:20      gi5      dynamic   
         2         02:11:32:25:6d:d0      gi26     dynamic   
         2         02:11:32:28:77:34      gi26     dynamic   
         2         04:18:d6:c0:1c:90      gi7      dynamic   
         2         04:18:d6:c0:1f:6b      gi11     dynamic   
         2         0c:51:01:8c:19:ae      gi9      dynamic   
         2         80:2a:a8:13:4f:07      gi9      dynamic   
         2         88:b2:91:98:d6:f0      gi9      dynamic   
         2         f4:06:16:4f:f6:36      gi7      dynamic   
         3         00:08:a2:0c:e6:21      gi6      dynamic   
         3         64:52:99:6b:84:76      gi7      dynamic   
         3         8c:ae:4c:f5:59:82      gi3      dynamic   
         3         b8:27:eb:31:70:ab      gi16     dynamic   
         3         b8:27:eb:38:d8:4d      gi18     dynamic   
         4         00:08:a2:0c:e6:20      gi5      dynamic   
         4         50:c7:bf:06:63:83      gi7      dynamic   
         4         50:c7:bf:21:73:52      gi9      dynamic   
         4         50:c7:bf:21:81:58      gi9      dynamic   
         4         50:dc:e7:28:08:70      gi7      dynamic   
         4         5c:cf:7f:df:84:1e      gi9      dynamic   
         4         68:54:fd:47:87:32      gi7      dynamic   
         4         88:3f:4a:f0:cb:9c      gi7      dynamic   
         4         a8:1b:6a:24:ec:26      gi27     dynamic   
         7         00:04:20:ed:f8:62      gi7      dynamic   
         7         00:08:a2:0c:e6:23      gi8      dynamic   
         7         0c:08:b4:48:cc:63      gi7      dynamic   
         7         5c:ad:76:d5:36:2d      gi7      dynamic   
         7         88:de:a9:5c:9a:81      gi11     dynamic   
         7         d0:4d:2c:12:bf:f3      gi7      dynamic   
         9         00:08:a2:0c:e6:24      gi4      dynamic   
         9         00:11:32:7b:29:7d      gi26     dynamic   
         9         00:11:32:7b:29:7e      gi24     dynamic   
         9         00:13:3b:2f:67:62      gi10     dynamic   
         9         00:13:3b:2f:67:63      gi28     dynamic   
         9         70:6e:6d:f3:11:93       0         self    
         9         c0:7b:bc:65:4f:13      gi7      dynamic   
         9         c0:7b:bc:65:4f:1c      gi7      dynamic   
         99        00:01:5c:82:36:46      gi13     dynamic   
         99        00:08:a2:0c:e6:25      gi1      dynamic   
    
    sg300-28#
    
    


  • @johnpoz said in Question about broadcast address traffic within a subnet:

    No problem - glad I could help... I would suggest you read up on how traffic is actually sent on the wire.. its sent to a specific mac address.. when client wants to talk to 1.2.3.4, if that is on its own network, then it arps for it! and then sends the traffic to that mac address.

    When the IP is not on its local network it sends it to the mac address of the gateway (pfsense) pfsense sees this traffic since sent to its mac, and says oh hey that is meant to go to 8.8.8.8 or where ever. Do I have a route to this network? Then send it to the mac address of the gateway or the default gateway mac, if don't have direct route to get to network that 8.8.8.8 sits on..

    Traffic is only ever actually sent to a mac address

    Example here me pinging 8.8.8.8

    ping8888.jpg

    Notice the mac address is the mac address of pfsense 9.253.. as I posted earlier..

    this is how switches know which port to send traffic on, because the switch uses its arp table and says hey mac xyz is connected to port 4.. So sends the traffic out port 4, and not all the ports. When switch sees traffic to mac abc, and its not in the switches arp table - then it arps out all its ports, to find out which port that mac is on, etc..

    Once you understand how this stuff actually works ;) Then it all becomes easy to figure out what is wrong...

    example - is is the mac address table of my switch, and you can see what macs are on what ports

    sg300-28#sho mac address-table 
    Flags: I - Internal usage VLAN
    Aging time is 300 sec
    
        Vlan          Mac Address         Port       Type    
    ------------ --------------------- ---------- ---------- 
         2         00:08:a2:0c:e6:20      gi5      dynamic   
         2         02:11:32:25:6d:d0      gi26     dynamic   
         2         02:11:32:28:77:34      gi26     dynamic   
         2         04:18:d6:c0:1c:90      gi7      dynamic   
         2         04:18:d6:c0:1f:6b      gi11     dynamic   
         2         0c:51:01:8c:19:ae      gi9      dynamic   
         2         80:2a:a8:13:4f:07      gi9      dynamic   
         2         88:b2:91:98:d6:f0      gi9      dynamic   
         2         f4:06:16:4f:f6:36      gi7      dynamic   
         3         00:08:a2:0c:e6:21      gi6      dynamic   
         3         64:52:99:6b:84:76      gi7      dynamic   
         3         8c:ae:4c:f5:59:82      gi3      dynamic   
         3         b8:27:eb:31:70:ab      gi16     dynamic   
         3         b8:27:eb:38:d8:4d      gi18     dynamic   
         4         00:08:a2:0c:e6:20      gi5      dynamic   
         4         50:c7:bf:06:63:83      gi7      dynamic   
         4         50:c7:bf:21:73:52      gi9      dynamic   
         4         50:c7:bf:21:81:58      gi9      dynamic   
         4         50:dc:e7:28:08:70      gi7      dynamic   
         4         5c:cf:7f:df:84:1e      gi9      dynamic   
         4         68:54:fd:47:87:32      gi7      dynamic   
         4         88:3f:4a:f0:cb:9c      gi7      dynamic   
         4         a8:1b:6a:24:ec:26      gi27     dynamic   
         7         00:04:20:ed:f8:62      gi7      dynamic   
         7         00:08:a2:0c:e6:23      gi8      dynamic   
         7         0c:08:b4:48:cc:63      gi7      dynamic   
         7         5c:ad:76:d5:36:2d      gi7      dynamic   
         7         88:de:a9:5c:9a:81      gi11     dynamic   
         7         d0:4d:2c:12:bf:f3      gi7      dynamic   
         9         00:08:a2:0c:e6:24      gi4      dynamic   
         9         00:11:32:7b:29:7d      gi26     dynamic   
         9         00:11:32:7b:29:7e      gi24     dynamic   
         9         00:13:3b:2f:67:62      gi10     dynamic   
         9         00:13:3b:2f:67:63      gi28     dynamic   
         9         70:6e:6d:f3:11:93       0         self    
         9         c0:7b:bc:65:4f:13      gi7      dynamic   
         9         c0:7b:bc:65:4f:1c      gi7      dynamic   
         99        00:01:5c:82:36:46      gi13     dynamic   
         99        00:08:a2:0c:e6:25      gi1      dynamic   
    
    sg300-28#
    
    

    Fantastic tutorial! What about broadcast traffic? Do they also follow the mac address rule?


  • LAYER 8 Global Moderator

    broadcast is sent to all FFs for the mac - so it goes everwhere!!! That is on that same L2 network, if switch sees that on say vlan X, then all ports that are also in vlan X would see that traffic. Ports in vlan Y wouldn't get sent that traffic.

    For dumb switches - all ports would see it, because all ports are in the same vlan on a dumb switch (vlan 1)..

    If you want to see that in action - just sniff on say machine A, and pfsense and then send a ping to 192.168.4.255 from machine B..

    edit: I would show you an example of this, but its time to watch some TV with the wife! ;)



  • @johnpoz
    A much appreciated thanks! I have consumed more than enough of your time this evening and have no more questions for you regarding this topic. Definitely do not ignore the wife!! Perhaps I can trouble you again sometime in the future?


Log in to reply