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

Question

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.

Anonymous_User · Answer

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

Sign up

Login with SSO

Login to the community

Login with SSO