This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to Stop UDP 14675 waterfall

After months and months of teethgrinding and not finding a good solution, I now realy want to know what to do about a few problems I find in my UTM.

I have a NAS disk in my network configured with static IP / DNS / Gateway ip's . 
But something in this system is is continiously poking on the 255.255.255.255 broadcast adress. And this is driving me crazy.
 I would like to know what can be done about the constant flow of UDP pokes on port 14675 ??? There are pokes on the UDP 137 and 138 also. 

I tried firewall rules but this didn't help. 
I have NO WINS server installed (on windows2008) and the DHCP setting in my UTM (UTM is DHCP server) 
has wins on 0.0.0.0 and WINS Node type: B-Node (no WINS)

Here are the results of Network Protection on my UTM dashboard.
Source:
Total dropped packets: 28 226 
host: 192.x.x.x 
packets: 27130 
percentage: 96.12%

Destination:
Total dropped packets: 28 226 
dest1: udp/14675
destination: 255.255.255.255
packets: 25656
percentage: 90.89% 

dest2: udp/137
destination:  Internal (LAN) (Broadcast)
packets: 1080
percentage: 3.83 %
 
UTM Version: 9.105-9


This thread was automatically locked due to age.
Parents
  • Right, Barry, that's one of the few valid uses.  If you don't have spoof protection enabled, you can use bound definitions for source definitions to prevent spoofed IPs from gaining access they shouldn't have.  For all other uses, I think that an Additional Address on an Interface is the correct solution.

    @HMaster - It also appears that your physical network has a problem.  Each broadcast hits two UTM interfaces.  This means the Ethernet segments are not isolated from each other.  This will cause strange problems.

    Cheers - Bob
Reply
  • Right, Barry, that's one of the few valid uses.  If you don't have spoof protection enabled, you can use bound definitions for source definitions to prevent spoofed IPs from gaining access they shouldn't have.  For all other uses, I think that an Additional Address on an Interface is the correct solution.

    @HMaster - It also appears that your physical network has a problem.  Each broadcast hits two UTM interfaces.  This means the Ethernet segments are not isolated from each other.  This will cause strange problems.

    Cheers - Bob
Children
No Data