Source IP 0.0.0.0.0 OR 127.0.0.1 AND ports 137, 138, 3128 dropped packets
-
Hello Team,
I have a few lines in the fw logs that I don't understand. There should be a way to either stop these or allow them if they are normal. Using Pfsense 2.4.2-RELEASE-p1 on Proxmox.
1/ Pfsense is the source? What can I do to understand where this traffic is coming from?
Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:138 0.255.255.255:138 UDP Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:137 0.255.255.255:137 UDP Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:137 0.255.255.255:137 UDP Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:137 0.255.255.255:137 UDP Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:137 0.255.255.255:137 UDP Feb 5 10:22:27 LAN USER_RULE (1513358118) 0.0.0.0:137 0.255.255.255:137 UDPNot sure why Pfsense is sending some Netbios traffic. How can I stop of being sent if it's not legitimate/necessary traffic?
2/ I have many lines from Pfsense again to my Wifi laptops. Out of connection traffic which seems coming from Squid. Should I increase a timer or whitelist my internal networks in Squid to avoid such messages between internal interfaces?
Feb 5 09:38:48 ► WIFI Default deny rule IPv4 (1000000104) 127.0.0.1:3128 10.20.30.2:54788 TCP:RA Feb 5 09:09:17 ► WIFI Default deny rule IPv4 (1000000104) 127.0.0.1:3128 10.20.30.2:41544 TCP:FAThank you in advance for your help
XabiX
-
Those packets from 127.0.0.1 3128 look to be out of state from the proxy? 3128 is proxy..
But from 0.0.0.0 to a broadcast address.. Pfsense out of the box has nothing that would talk or listen on 137 or 138 that most likely something on your lan sending to broadcast - which yes pfsense would see that traffic.
-
The 0.0.0.0 source address is also used by a DHCP client when the client has no lease at all. It will broadcast UDP discovery messages on the connected network to discover DHCP servers in that network and the source address in those messages is set to 0.0.0.0 because it has no other source address to use. Something on your network is doing the same but with NetBIOS/MS filesharing ports.
-
The 0.0.0.0 address is used when a device does not yet know it's IP address. It's used, for example, with DHCP, until an address has been received. However, the destination would be the broadcast address 255.255.255.255. I have no idea why 0.255.255.255 is used. The loop back address, 127.0.0.1 or any address in 127.0.0.0 /8 for that matter, is used within the device for various things.
-
Good catch on the 0.255.255.255
Why don't you sniff that traffic and find out what mac its coming from so you can see what is sending it.
-
0.255.255.255 is a type of broadcast address. It wouldn't have a hardware MAC address. I believe this may go back to the very early days, when 0.0.0.0 was a broadcast address.
-
For point 1, then the question would be: Is 0.255.255.255 legitimate traffic that I should allow so they will disappear from those logs and potentially fix a traffic currently being blocked?
If not I agree I should look to understand who is sending those. (so far my captures where empty with filter "0.255.255.255 | 127.0.0.1 | 0.0.0.0" so I need to let him run longer)FYI I have noted this on my Pfsense:
netstat -n | grep 137 tcp4 0 0 192.168.1.10.39316 137.254.104.115.80 TIME_WAIT tcp4 0 0 192.168.1.10.17033 45.79.137.197.443 ESTABLISHED netstat -n | grep 138 tcp4 0 0 127.0.0.1.3129 10.0.0.2.61383 FIN_WAIT_21/ Maybe is then normal to have 127.0.0.1:3129 or 3128 ? Do you also have this on your Pfsense box? (FYI 192.168.1.10 is my WAN IP behind the DSL box)
For point 2, do you think it worth trying these Squid options by adding my private IP ranges (as 10.20.30/24)?
-
Bypass Proxy for Private Address Destination
-
Bypass Proxy for These Source IPs
It's interesting not critical issue but I like to understand what is happening and have clean logs too :)
PS (EDIT): Attached the NAT rules created for Ipsec. I am wondering if this 127/8 couldn't be the reason. I will remove the 1st line as I am using OpenVPN and not IPsec tunnel
-
