Weird Routing Bug???

[tpfannes]

OK,

So I have an Public Wireless interface (Port5: 192.168.16.1/20) that has all my public wireless traffic that is only allowed access to the Internet (Port1: 12.249.1.1).  The DHCP Scope for Port5: is 192.168.16.2 - 192.168. 31.254.  

Everything works great UNLESS DHCP assigns me an address in the 192.168.20.x range, then nothing works.  If you look at my routing table you will see:

Now I didn't think much of this because the FW should always prefer a locally connected route over one learned via. a routing protocol (OSPF in this instance). 

Though in my environment this is not the case.  I tested this by hardcoding my machine to 192.168.20.125 and tried to ping 8.8.8.8 and did a packet capture on the FW (v5.0,build0128) I see that the traffic flows:

Client (192.168.20.125) ->

-> Port5 in (inside pub wireless 192.168.16.1)

-> Port1 out (outside Internet connection 12.249.1.1) -> Destination (8.8.8.8)

-> Port1 in (outside Internet connection 12.249.1.1)

-> Port14 OUT (inside corporate 10.176.16.2).  

Pasted output:

C_FW (root) # diag sniffer packet any "host 8.8.8.8" 4

interfaces=[any]

filters=[host 8.8.8.8]

4.163172 port5 in 192.168.20.125 -> 8.8.8.8: icmp: echo request

4.163197 port1 out 12.249.1.1 -> 8.8.8.8: icmp: echo request (NAT)

4.179553 port1 in 8.8.8.8 -> 12.249.1.1: icmp: echo reply

4.179563 port14 out 8.8.8.8 -> 192.168.20.125: icmp: echo reply

 

8 packets received by filter

0 packets dropped by kernel

(I think) this IS WRONG; shouldn't it prefer the locally connected route (Port5 192.168.16.1) over the OSPF learned route (10.176.16.2)??????

Thanks,

Tim Pfannes

[hklb · Accepted solution]

Hello,

No, it's normal. Fortigate will use the longest match first (your subnet 192.168.20.0/24 is more precise of subnet 192.168.16.0/20), so the traffic will be routed by port14.

Lucas

[emnoc]

No you have it wrong and don't quite understand routing. All routers prefer  the longest match. So in your case the ospf admin value 110 is prefered due to

1: it's the longest match ( /24 vrs /20 )

2: routing table at this point could care less if it was static, dynamic learn, or connected

This routing 101 and not a bug.  Now why would you assign a dhcp-scope that overlaps another network?  I can't think of anything good that would come of that  scenario. Since you have rfc1918 address space, it makes no sense to restrict or deploy bad designs or habits. It's isn't like you have a limited vailability or have to justify the use of private-addressing. I would personally rethink your network address goals, and select a new network for port14 imho.

Ken

[hklb · Accepted solution]

Hello,

No, it's normal. Fortigate will use the longest match first (your subnet 192.168.20.0/24 is more precise of subnet 192.168.16.0/20), so the traffic will be routed by port14.

Lucas

[tpfannes]

HKLB,

Thank you for an accurate reply without being a condescending prick (see: emnoc).  I always thought connected took precedence and then longest matching prefix and then AD.  

Found a good explanation for anyone interested: 

https://alexandremspmorae...egory/english/routing/

hklb wrote:

Hello,

No, it's normal. Fortigate will use the longest match first (your subnet 192.168.20.0/24 is more precise of subnet 192.168.16.0/20), so the traffic will be routed by port14.

Lucas

[tpfannes]

Lucas,

A question for you, when I'm local (192.168.20.125) and try to ping my default gateway (192.168.16.1) I see the same thing.  In this instance there is no routing involved, my PC should just arp for 192.168.16.1 and send the ping directly to that mac.  I understand why my pings to 8.8.8.8 are not working (thank you for the response) but shouldnt the ping to the local physical interface work?

[ede_pfau · Accepted solution]

Tim, even if the tone of emnoc's answer was a bit harsh he didn't insult you like you did in your response. I don't think it's appropriate for grown-ups to communicate in this manner. Certainly not in these forums.

There are still valid points in his post.

[emnoc]

Your local interface subnet mask is going to determine what/where your ARPs are going to go. Outside of Proxy-Arp the  local address of 192.168.20.125 with a /24 is going to send the ARPs to 192.168.20.255, so how is the default-gw going to answer that broadcast request if it's on a /20?

[tpfannes]

emnoc wrote:

Your local interface subnet mask is going to determine what/where your ARPs are going to go. Outside of Proxy-Arp the  local address of 192.168.20.125 with a /24 is going to send the ARPs to 192.168.20.255, so how is the default-gw going to answer that broadcast request if it's on a /20?

My local PC did have a 20 bit mask (192.168.20.125/255.255.240.0) and obviously so did my default gateway (FG: Port5 192.168.16.1/255.255.255.240).  When I did the capture I saw the Port5 on the FG (192.168.16.1) reply to the ARP and then immediately saw the ICMP Echo Request (dest: 192.168.16.1 source: 192.168.20.125 data: icmp echo request) get forwarded out Port 14.  Since its a local request with no routing involved it doesnt seem to me it should forwarding this to the OSPF learned network, instead it should be replying locally?  

Anyway, thanks for your help.

[emnoc]

What interface is the PC on? Remember the ARP ( local to the PC ) has nothing to do with the L3-RIB on the forigate. As a matter of fact, the PC doesn't even know the  route-table of the  fortigate but only it's default-gw.

Do a  capture with the filter ARP on the interface of that of the PC and then look for the reply if any and if it populates in your  local-PC arp table ( arp -a ). That should clear things up. ARP in it's self is a protocol and works at the datalink layer for "ethernet" only.