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	UDP
    

    Not 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:FA
    

    Thank you in advance for your help

    XabiX


  • Rebel Alliance Global Moderator

    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.


  • Rebel Alliance Global Moderator

    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_2
    

    1/ 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