Source IP 0.0.0.0 to destination IP 255.255.255.255 - couldn' t block

[Richard_Bartlett]

Fortigate-100A 2.80,build357,050127 I had a UDP session running that I couldn' t fathom the source of. Worst still, I couldn' t quosh it using the policy statements - which I am guessing is a result of this type of communication not being catered for within the policy engine in this quite recent release. I used the CLI " diag netlink rtcache list" command to give me a clue (looking at the number that occured after the @ symbol [0.0.0.0@3->255.255.255.255@7). [from UDP 68 to UDP 67] However irrespective of the rules that I entered using match addresses as host 0.0.0.0 and host 255.255.255.255 - the flow always appeared on the session table (with a counter of 30 seconds). Should an all 1s broadcast go anywhere, or was it being dumped in the bit bucket by if=root. However I wouldn' t want it to burn up one of my session table entries and felt that I couldn' t do anything about it. I cannot tell what the packet was trying to do without sniffing it further - which I didn' t do. For info: 10.100.15.137 = via WAN2 diag netlink rtcache family=02 tab=254 vf=0 type=03 tos=0 flag=90000200 0.0.0.0@3->255.255.255.255@7 gwy=0.0.0.0 prefsrc=10.100.15.137 ci: ref=2 lastused=649 expire=0 err=00000000 used=0 br=0 pmtu=1500 diag netlink interface list if=lo family=00 type=772 index=1 mtu=16436 link=0 master=0 ref=5 flags=loopback if=wan1 family=00 type=1 index=2 mtu=1500 link=0 master=0 ref=58 flags=up broadcast run multicast if=wan2 family=00 type=1 index=3 mtu=1500 link=0 master=0 ref=44 flags=up broadcast run multicast if=dmz1 family=00 type=1 index=4 mtu=1500 link=0 master=0 ref=6 flags=up broadcast multicast if=dmz2 family=00 type=1 index=5 mtu=1500 link=0 master=0 ref=6 flags=up broadcast multicast if=internal family=00 type=1 index=6 mtu=1500 link=0 master=0 ref=71 flags=up broadcast run multicast if=root family=00 type=772 index=7 mtu=16436 link=0 master=0 ref=23 flags=up loopback run if=vsys_ha family=00 type=772 index=8 mtu=16436 link=0 master=0 ref=10 flags=up loopback run if=port_ha family=00 type=1 index=9 mtu=1496 link=0 master=0 ref=4 flags=up broadcast multicast I' ve tried firewall policies, policy routeing (all 1s addresses are invalid for acceptance), and static routeing (still creates a session table entry even if the host is unreachable by pointing to a next hop that isn' t resolvable). Not a big oversight and if it is fixed in 2.9-private-beta or 3.0-public-beta - then all is well. However I thought I' d save anyone else from spending time chasing this lost sheep by declaring it on the forum as opposed to entering the trouble as a fault.

[#2]

This is an old post that I stumbled upon that no one seems to have responded. Those udp ports 67 and 68 are either bootp or DHCP protocol(s). (DHCP is a subset of BOOTP) Something is broadcasting (255.255.255.255) -- that' s how dhcp/bootp work. It' s to the local network so you wouldn' t block it at the firewall. If you really can' t have it, then I think you' d have to block it at the switch level via layer three management most likely. But why would one do that anyway? Now, you may determine the source first by looking at the ethernet MAC address and then associating the MAC to a host. Some switches will let you associate a port to a MAC address. Now, if you' ve got DHCP relay going, it' s a little harder to do, because the MAC could be that of a router or firewall doing the relay because the broadcast wont leave that ethernet network segment. I am not an expert. -Jim