Continuous data traffic to WAN
-
Hey @Derelict , can you please plug your OPT1 back in? I'm having trouble getting to your Plex server box...
Thanks!
*** just kidding ***
Jeff
-
Thanks for your replies.
Seeing the states I understood the problem, if we want to consider this.
With old router, the LAN had this addresses: 192.168.100.0/24, so the broadcast address was 192.168.100.255
Now with pfsense, I changed the LAN addresses to 10.78.32.0/26, so the broadcast address is 10.78.32.63
I went to see the states and I noticed this particular:
The tv box has ip 10.78.32.34
I'm thinking the tv box continues to believe that the broadcast address ends with 255, as in old router, and not 64.
This explains that with old router, all LEDs were blinking (broadcast), and now with pfsense it isn't so because 10.78.32.255 is out of LAN, and then routed to the modem, which in turn routes to the Internet.So I need to block the outgoing traffic to 10.78.32.255? Or I need more?
Thanks
-
No, you should set a consistent IP network, including netmask, on your network.
-
What? You don't run your router with a /26 mask, and clients on this network with a /24 mask?? Is that what you did?
-
I configured the new network with /26 mask, but the tv box continues to send broadcast frames to 10.78.32.255, and I don't know why. It is a bit old (android 4.4.2).
I thought to add a new firewall rule, and indeed it works.
This is the LAN firewall:
In less than one minute, the firewall blocked 160KiB of noisy traffic.Now the LEDs behaviour hasn't changed in the switch, but the noisy frames are no longer routed to the modem and to the Internet.
This is what I can do, and for now it works.
Thanks for the help!
-
If you are running /26 on pfSense everything on that segment should be in the same /26.
That is how you configure an IP network.
There is no second option.
-
You need to fix the mask on the device, or have it update its dhcp lease so it gets the new mask
-
@dam034 said in Continuous data traffic to WAN:
Now the LEDs behaviour hasn't changed in the switch, but the noisy frames are no longer routed to the modem and to the Internet.
I thought we had already come to the conclusion that the "noisy" frames already WEREN'T routed to the Internet, as its broadcast traffic!
-
Its not going to route anywhere when the router thinks the IP is in its own network... But sure it could shove down its default gateway when its not an IP on is own interface... Ie is issue with a mismatched mask.
But your correct if a true broadcast it shouldn't be routed.
But odd things can happen when you run a network with clients having mismatched masks.
-
if pfSense has an interface subnet of 10.78.32.0/26 there is absolutely no way for it to know that 10.78.32.255 is a broadcast. The solution is to fix your network.
If you have broken devices that assume /24, then use /24.
-
Yeah, a device with something hardcoded to /24 is horrible but believable. Unfortunately.
Steve
-
What device is that that has a hard coded mask of 24... That is just freaking HORRIBLE!!! And it won't accept new mask with dhcp even if its interface has no place to set the mask..
Here is what you do with such hardware - RETURN IT!!!! Or throw it a freak away! And never buy hardware from the company again, and spread the news on how shit the stuff is..
-
@johnpoz Would it not be simpler to just have a firewall rule block traffic from the offending device, if you CAN'T adjust the network to compensate I mean?
Its not graceful I know, but it at least prevents it going out the WAN.
For example I have pf enabled on bridge and block traffic from LAN to LAN on certain IP addresses as a simple way to stop my neighbours phones/consoles from seeing my TV, surround system (the PtP link to them is on the bridge), etc, while still having full access myself if I roam onto their WiFi.
This is obviously not from a security perspective where putting them on their own VLAN would make more sense, its just to prevent accidental casting to my devices. Sometimes the hackery option is "good enough", especially when my router is seriously overpowered so not going to take any performance hit.
-
@dam034 said in Continuous data traffic to WAN:
I configured the new network with /26 mask, but the tv box continues to send broadcast frames to 10.78.32.255, and I don't know why. It is a bit old (android 4.4.2).
If that box can only use a /24, then you have to set everything else to /24. It should work fine then. Years ago, back when classfull addresses were used, some things would set the mask according to the address class. However, that sort of behavior should have disappeared with the shift to CIDR and variable length subnet masks several years ago. Even then, you'd never get a class C mask, with a class A address. Seems to me that TV box is NFG.
-
Dude just use a FREAKING /24 if your device will not let you change... What do you think using a /24 out of rfc1918 space cost you??? Let me think - nothing!
I have pf enabled on bridge and block traffic from LAN to LAN on certain IP
Yeah the blinking lights are making more and more sense the deeper this thread freaking goes..
-
Mmm. What exactly is that 'TV Box'? What does it think it's subnet is?
-
@Alex-Atkin-UK said in Continuous data traffic to WAN:
Would it not be simpler to just have a firewall rule block traffic from the offending device, if you CAN'T adjust the network to compensate I mean?
Its not graceful I know, but it at least prevents it going out the WAN.What's going out? For it to go anywhere, it needs a destination address. Where's it going? If it's the broadcast address, then it's not going out anywhere. What does Packet Capture, running on the WAN interface, show?
-
@JKnott said in Continuous data traffic to WAN:
@Alex-Atkin-UK said in Continuous data traffic to WAN:
Would it not be simpler to just have a firewall rule block traffic from the offending device, if you CAN'T adjust the network to compensate I mean?
Its not graceful I know, but it at least prevents it going out the WAN.What's going out? For it to go anywhere, it needs a destination address. Where's it going? If it's the broadcast address, then it's not going out anywhere. What does Packet Capture, running on the WAN interface, show?
I'm just trying to follow what was said above, I also thought it couldn't go out but its suggested above that it COULD go out if the broadcast address does not match the LAN.
-
@Alex-Atkin-UK said in Continuous data traffic to WAN:
that it COULD go out if the broadcast address does not match the LAN.
Yeah it "could" But in what freak show of scenario would you be running devices on the same L2 with different masks for their L3?? No you don't do that!!!
-
It's not the broadcast address because the broadcast address on the interface is .63
There is NO WAY for an interface to know .255 is a broadcast address if it is on subnet .0/26
If there are devices on a network that were designed by morons that insist on using /24, then you either remove the devices from the network or you use /24. Period. You don't block the traffic or try to work around it in other silly ways.
