local source packets dropped: where are they coming from?

[XabiX]

Hello Gurus,

First, waooouhh I like it a lot this new look'n feel. It makes the forum more easy to navigate IMHO.

The issue I have is that I see since day a lot of garbage drops in the FW which I can't identify and even understand. My config works but I don't understand why I see things about 1.1.1.1, 1.1.1.2 and 127.0.0.1

WIFI is an Asus HotSpot but even the LAN shows some netbios trafic with source 0.0.0.0. How can I know where this is coming from?

Merci
XabiX

[johnpoz]

You have something on your network with IP 1.1.1.1 and you also have link local addresses 169.254 - these are normally devices that ask for IP and don't get one.

To track down what device(s) are sending these packets do a packet capture on the wifi interface of pfsense and you will be able to see the mac address. From the mac address you can lookup the maker of the device and should help you track down what device(s) it is.

It might be helpful in posting your wifi rules, and I assume floating rule with the blocked outbound block. Also post your lan rules and sniff on that interface to track down the 0.0.0.0

[XabiX]

@johnpoz said in local source packets dropped: where are they coming from?:

It might be helpful in posting your wifi rules, and I assume floating rule with the blocked outbound block. Also post your lan rules and sniff on that interface to track down the 0.0.0.0

Hi Johnpoz,

Here are my rules:

I will launch a capture again to try to find the MAC of those packets. Is there anything strange wrong that you can spot from these rules?

I recently added the traffic shapping because of issues with wifi calls not being good but the issue was there before :)

Merci
XabiX

[NogBadTheBad]

IIRC 1.1.1.1 was used for the Cisco WLC captive portal address.

You don't have a Cisco wireless controller on your network do you ?

Do you have anything in the ARP table for 1.1.1.1, maybe look up its MAC address:-

https://www.wireshark.org/tools/oui-lookup.html

[johnpoz]

your first rule there wifi address to this firewall is pointless..

Rules are evaluated as traffic enters and interface from the network its attached to. First rule to trigger wins, no other rule is evaluated.

When would traffic be entering the interface from the network with a source IP of the wifi interface itself?

Did you maybe mean wifi net as source. Also if your wanting to allow dns, dns can at times use tcp so any dns rule should include both udp/tcp. Also this firewall would allow access to ALL interfaces on pfsense - wan, lan any other optX etc.. Normally such a rule to allow dns would be to the interface address of the network its attached to, ie wifi address.

Also you understand that 1900 is DLNA doesn't route, it is multicast... Same thing goes for GDM.. That is not going to work across a L3 boundary.

Your easy rules make no sense either.

Your rule on lan net to allow 10.0.0.8 to some alias makes no sense, unless that that some downstream network.. And not your lan net, since your rule right below is any any.. Having a downstream network off your lan and not a specific transit network is going to most likely introduce asymmetrical routing problems.

[NogBadTheBad]

His LAN diagram here John:-

https://www.dropbox.com/s/qtaa6q3ushwbk7g/network.jpg?dl=0

[johnpoz]

so his lan is what mask... He has a bunch of other 10.x networks but doesn't show any routing, etc. Nor does he mention any vlans setup on pfsense, etc.

[XabiX]

@nogbadthebad I did a 286Mo capture on the wifi interface and couldn't find any 1.1.1.1 or 1.1.1.2 packet and there is nothing in the ARP table:

The only Cisco equipment I have is an IP-Phone

[XabiX]

@johnpoz said in local source packets dropped: where are they coming from?:

your first rule there wifi address to this firewall is pointless…
Rules are evaluated as traffic enters and interface from the network its attached to. First rule to trigger wins, no other rule is evaluated.
When would traffic be entering the interface from the network with a source IP of the wifi interface itself?
Did you maybe mean wifi net as source. Also if your wanting to allow dns, dns can at times use tcp so any dns rule should include both udp/tcp. Also this firewall would allow access to ALL interfaces on pfsense - wan, lan any other optX etc… Normally such a rule to allow dns would be to the interface address of the network its attached to, ie wifi address.

It was until yesterday set to wifi-net but as I have a cell phone connected on wifi and using wifi calling then I changed it to wifi-address as the source ip address from the wifi calling side was not in the range of the wifi-net. I will fix that and add TCP to DNS just in case.

This is what the wifi calling client does (if there is a call then it's with ipsec)

yes the link above gives the vlan and ip ranges used. Basically internally I have 3 vlans and externally the wan. FYI the interfaces:
WAN (wan) -> vtnet0 -> v4: 192.168.1.10/24
LAN (lan) -> vtnet1.3 -> v4: 10.0.0.254/24
CAM (opt1) -> vtnet1.5 -> v4: 10.10.10.254/24
WIFI (opt2) -> vtnet1.4 -> v4: 10.20.30.254/24

And thanks to you here is now how it looks like:

[XabiX]

@johnpoz said in local source packets dropped: where are they coming from?:

Also you understand that 1900 is DLNA doesn’t route, it is multicast… Same thing goes for GDM… That is not going to work across a L3 boundary.
Your easy rules make no sense either.
Your rule on lan net to allow 10.0.0.8 to some alias makes no sense, unless that that some downstream network… And not your lan net, since your rule right below is any any… Having a downstream network off your lan and not a specific transit network is going to most likely introduce asymmetrical routing problems.

In general I added these rules as I wanted to have things working between the lan 10.0.0/24 and the wifi 10.20.30/24 networks.
Are you saying that I don't need them? I have disabled them for now (as you can see above).

Merci

[kpa]

Multicasts, broadcasts, all that traffic will never traverse the router on their own. Add rules that silently (no logging) blocks the traffic and don't worry about it.

[XabiX]

@kpa Thanks

So I will enable them but put them as block with silence logging instead so at the end I don't lose functionality and don't pollute my FW logs. MERCI

If I understood you well, here is what it now looks like:

[kpa]

You can be much broader with your rules, I block any UDP traffic going to UDP ports 137 and 138 and to any address on my LAN interface. The logic goes like that any such traffic hitting the router/firewall is of no interest regardless of the destination address.

The "MS_Filesharing_UDP_Ports" alias is an alias for UDP ports 137 and 138.