Continuous data traffic to WAN
-
Multicast and broadcast don't pass a router in the first place... So you don't have to worry about it flooding your wan..
As to your server and tvbox having to be in the same L2... Nonsense - you might not be able to use whatever broadcast/multicast discovery method your using now... But I stream stuff from my "server" to my TV every day all day and they are in different networks.
If you want to see what kind of traffic your tvbox is spewing - just do a sniff (packet capture) on pfsense lan interface under the diag menu.
-
I still don't understand why you consider any of this a "problem".
You will ALWAYS see traffic on the WAN, either from people probing your IP from the Internet, the PPPoE session to your ISP, or your IP address being refreshed over DHCP.
As for the LAN, my LEDs flash day and night, the amount of bandwidth its actually doing is microscopic. It will have zero impact on your Internet speed and be immeasurably small on your LAN speed.
Unless you have identified an actual issue with it causing problems on your LAN, blocking that traffic will only make using your devices more complicated as its there to make detecting devices on your LAN completely automatic.
Even my main smart managed switch and pfSense itself broadcasts its own traffic as I have uPNP enabled (for specific IP addresses only). Its how these devices are designed to work.
-
It's 2AM. Everyone's asleep but me. I am not chasing blinking LEDs.
-
@Derelict said in Continuous data traffic to WAN:
It's 2AM. Everyone's asleep but me. I am not chasing blinking LEDs.
It's morning here;,so I've been looking for an hour or so at your video : no red lights, all looks good to me ^^
-
@Gertjan said in Continuous data traffic to WAN:
@Derelict said in Continuous data traffic to WAN:
It's 2AM. Everyone's asleep but me. I am not chasing blinking LEDs.
It's morning here;,so I've been looking for an hour or so at your video : no red lights, all looks good to me ^^
Damn wanted to write the exact same thing :D
-
@JeGr I'm sat here trying to guess what each box is for. ;)
-
I'm sat here trying to guess what each box is for. ;)
Top down, left-to-right:
SG-4860 (Edge), Cable modem, MoCA bridge, VDSL modem
SG-5100 (tnsr), SG-4860 (Trex)
Brocade ICX6450-48 Layer 3 switch -
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.
