Skip to main content
tpfannes
tpfannes
New Member
January 9, 2015
Solved

Weird Routing Bug???

  • January 9, 2015
  • 5 replies
  • 10388 views

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

    Best answer by hklb

    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

     

    5 replies

    emnoc
    emnoc
    New Member
    January 9, 2015

    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
    hklbAnswer
    Visitor III
    January 9, 2015

    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
    tpfannesAuthor
    New Member
    January 9, 2015

    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

     

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    January 9, 2015

    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
    emnoc
    New Member
    January 9, 2015

    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
    tpfannesAuthor
    New Member
    January 9, 2015

    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
    emnoc
    New Member
    January 9, 2015

    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.

    Terms & ConditionsAccessibility statement