Skip to main content
BraddyJ
BraddyJ
New Member
January 31, 2013
Question

unable to ping beyond default gateway on new Internet connection

  • January 31, 2013
  • 15 replies
  • 20318 views
I have a Fortigate 200B with the latest 4.0 firmware. We use muiltiple Internet connections, two PPPoE connections that work just fine, and one new manual connection that I can' t get to work. I feel like I must be missing something really simple/stupid. The connections that are working: Port 13 (DSL01) - DHCP 63.231.68.142 / 255.255.255.255 Gateway: 207.225.112.6 Port 14 (DSL02) - DHCP 216.160.163.168/255.255.255.255 Gateway: 207.225.112.2 The connection that isn' t working: Port 15 (EoCu) - Manual 63.232.194.114/255.255.255.248 Static routes: Device distance priority gateway ip/mask Port 13 10 5 0.0.0.0 0.0.0.0/0.0.0.0 port 14 10 5 0.0.0.0 0.0.0.0/0.0.0.0 port 15 10 5 63.232.194.113 0.0.0.0/0.0.0.0 Static Settings: port 13 ping server 4.2.2.1 port 14 ping server 4.2.2.2 port 15 ping server 63.232.194.113 Routing monitor shows: type network distance gateway interface static 0.0.0.0/0 5 207.225.112.2 PPP1 static 0.0.0.0/0 5 207.225.112.6 PPP2 (no other static entries are listed for any interfaces) connected 63.231.68.142/32 0 0.0.0.0 PPP2 connected 63.232.194.112/29 0 0.0.0.0 Port 15 connected 207.225.112.2/32 0 0.0.0.0 PPP1 connected 207.225.112.6/32 0 0.0.0.0 PPP2 connected 216.160.163.168/32 0 0.0.0.0 PPP1 (why isn' t my static route default gateway listed for port 15???) From the firewall console: exec ping 63.232.194.113 comes back fine exec ping 207.109.53.142 does not come back When I connected my laptop to the same connection as port 15 I configured it like this: IP: 63.232.194.114 Subnet mask: 255.255.255.248 Default gateway: 63.232.194.113 With that configuration, I am able to ping 207.109.53.142 from my laptop. What am I missing???

    15 replies

    Show previous replies
    BraddyJ
    BraddyJAuthor
    New Member
    February 1, 2013
    Route monitor (note: no static entry for port 15)
    BraddyJ
    BraddyJAuthor
    New Member
    February 1, 2013
    Ok, so I didn' t have any policy routes, but I started thinking: if my static routes aren' t creating a routing entry for the default gateway on port 15, perhaps I could create a policy route that would. The image below is what I just created, and it allows traffic out over that interface from the internal network over port 15! In short, this policy route fixes the problem. My question now is, why does the policy route work when a static route did not!?
    Dave_Hall
    Dave_Hall
    New Member
    February 1, 2013
    In short, this policy route fixes the problem. My question now is, why does the policy route work when a static route did not!?
    From what I can tell I don' t think there is anything wrong; you have enabled ECMP Weighted Load Balance, so the fgt should route traffic out port 13,14 and 15. Assuming you have all three port interfaces merged into a Zone, you could test to see if the fortigate routes traffic out port 15 by either disabling or unplugging port 13 and 14. (I wouldn' t do this during work/offic hours though.)
    BraddyJ
    BraddyJAuthor
    New Member
    February 1, 2013
    From what I can tell I don' t think there is anything wrong; you have enabled ECMP Weighted Load Balance, so the fgt should route traffic out port 13,14 and 15. Assuming you have all three port interfaces merged into a Zone, you could test to see if the fortigate routes traffic out port 15 by either disabling or unplugging port 13 and 14. (I wouldn' t do this during work/offic hours though.)
    I am restricting traffic to port 15 with firewall policies that limit 1 subnet to communicating over port 15. I have also tried moving the connection from port 15 to another port (11) and reconfiguring 11. Same issues. I have opened a support ticket on this issue, and will post the results to this forum for everyone’s edification. Tier 1 support couldn’t see anything wrong with the configuration either, and has upgraded the ticket’s priority and forwarded to tier 2. During the support call I learned a series of new commands including the ping trace and sniffer commands that EMNOC was talking about. We also took a look at the routing tables and routing table database. The trace and sniffer show that my testing laptop on the Intranet was successfully able to communicate with the Internet as long as the policy route was in place. Take the policy route away and the traffic from the testing laptop goes nowhere. We checked the routing tables and there is no default gateway listed for port 15 (so no wonder it doesn’t know how to get out). We checked the database and there is a static entry showing that there should be a default gateway, but it is not listed in the tables or in the kernel’s routing information. One interesting note about the kernel’s routing information though is that it shows the IPs of the network and broadcast addresses for port 15 in addition to the static IP of the port itself and the network address for that port. All entries are missing the default gateway configuration. See below: 
      IASLC-FW01 # get router info kernel  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->207.225.112.6/32 pref=63.231.68.142 gwy=0.0.0.0 dev=57(ppp1)  tab=254 vf=0 scope=0 type=1 proto=14 prio=0 216.160.163.168/255.255.255.255/0->4.2.2.2/32 pref=0.0.0.0 gwy=207.225.112.2 dev=56(ppp2)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->207.225.112.2/32 pref=216.160.163.168 gwy=0.0.0.0 dev=56(ppp2)  tab=254 vf=0 scope=0 type=1 proto=14 prio=0 63.231.68.142/255.255.255.255/0->4.2.2.1/32 pref=0.0.0.0 gwy=207.225.112.6 dev=57(ppp1)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->63.232.194.112/29 pref=63.232.194.114 gwy=0.0.0.0 dev=8(port15)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.20.0/24 pref=192.168.20.1 gwy=0.0.0.0 dev=25(IASLC-WIFI)  tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->10.254.254.0/24 pref=0.0.0.0 gwy=0.0.0.0 dev=12(ssl.root)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.1.0/24 pref=192.168.1.1 gwy=0.0.0.0 dev=9(port16)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.30.0/24 pref=192.168.30.1 gwy=0.0.0.0 dev=24(IASLC-WIFIguest)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.11.0/24 pref=192.168.11.1 gwy=0.0.0.0 dev=9(port16)  tab=254 vf=0 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.0/24 pref=192.168.10.1 gwy=0.0.0.0 dev=9(port16)  tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0  	gwy=207.225.112.2 flag=04 hops=0 oif=56(ppp2)  	gwy=207.225.112.6 flag=04 hops=0 oif=57(ppp1)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.1.1/32 pref=192.168.1.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.1.0/32 pref=192.168.1.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->63.232.194.114/32 pref=63.232.194.114 gwy=0.0.0.0 dev=8(port15)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=11(root)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.11.1/32 pref=192.168.11.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.11.0/32 pref=192.168.11.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->63.232.194.112/32 pref=63.232.194.114 gwy=0.0.0.0 dev=8(port15)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.255/32 pref=192.168.10.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->63.232.194.119/32 pref=63.232.194.114 gwy=0.0.0.0 dev=8(port15)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->63.231.68.142/32 pref=63.231.68.142 gwy=0.0.0.0 dev=57(ppp1)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.20.255/32 pref=192.168.20.1 gwy=0.0.0.0 dev=25(IASLC-WIFI)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.30.255/32 pref=192.168.30.1 gwy=0.0.0.0 dev=24(IASLC-WIFIguest)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->216.160.163.168/32 pref=216.160.163.168 gwy=0.0.0.0 dev=56(ppp2)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.1.255/32 pref=192.168.1.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.1/32 pref=192.168.10.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.10.0/32 pref=192.168.10.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.11.255/32 pref=192.168.11.1 gwy=0.0.0.0 dev=9(port16)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.20.0/32 pref=192.168.20.1 gwy=0.0.0.0 dev=25(IASLC-WIFI)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.20.1/32 pref=192.168.20.1 gwy=0.0.0.0 dev=25(IASLC-WIFI)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=11(root)  tab=255 vf=0 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.30.0/32 pref=192.168.30.1 gwy=0.0.0.0 dev=24(IASLC-WIFIguest)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=11(root)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.30.1/32 pref=192.168.30.1 gwy=0.0.0.0 dev=24(IASLC-WIFIguest)  tab=255 vf=0 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=11(root)           S*      0.0.0.0/0 [5/0] via 207.225.112.2, ppp2                    [5/0] via 207.225.112.6, ppp1  S       10.254.254.0/24 [10/0] is directly connected, ssl.root  C       63.231.68.142/32 is directly connected, ppp1  C       63.232.194.112/29 is directly connected, port15  C       192.168.1.0/24 is directly connected, port16  C       192.168.10.0/24 is directly connected, port16  C       192.168.11.0/24 is directly connected, port16  C       192.168.20.0/24 is directly connected, IASLC-WIFI  C       192.168.30.0/24 is directly connected, IASLC-WIFIguest  C       207.225.112.2/32 is directly connected, ppp2  C       207.225.112.6/32 is directly connected, ppp1  C       216.160.163.168/32 is directly connected, ppp2     IASLC-FW01 # get router info routing-table database   Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP         O - OSPF, IA - OSPF inter area         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2         E1 - OSPF external type 1, E2 - OSPF external type 2         i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area         > - selected route, * - FIB route, p - stale info     S    *> 0.0.0.0/0 [5/0] via 207.225.112.2, ppp2       *>           [5/0] via 207.225.112.6, ppp1  S       0.0.0.0/0 [10/0] is directly connected, port13 inactive, [5/0]                    [10/0] is directly connected, port14, [5/0]                    [10/0] via 63.232.194.113, port15, [5/0]  S    *> 10.254.254.0/24 [10/0] is directly connected, ssl.root  C    *> 63.231.68.142/32 is directly connected, ppp1  C    *> 63.232.194.112/29 is directly connected, port15  C    *> 192.168.1.0/24 is directly connected, port16  C    *> 192.168.10.0/24 is directly connected, port16  C    *> 192.168.11.0/24 is directly connected, port16  C    *> 192.168.20.0/24 is directly connected, IASLC-WIFI  C    *> 192.168.30.0/24 is directly connected, IASLC-WIFIguest  C    *> 207.225.112.2/32 is directly connected, ppp2  C    *> 207.225.112.6/32 is directly connected, ppp1  C    *> 216.160.163.168/32 is directly connected, ppp2
    BraddyJ
    BraddyJAuthor
    New Member
    February 2, 2013
    Tier 2 support was able to resolve my issue in no time! Here’s what was going on: The screenshot of the static routes showed a distance value of 10, and all things being equal, all three static routes should have appeared in the routing table screenshot. However, if you look close, the routing table’s entries for port 13 and 14 have a distance value of 5 instead of 10. This is because port 13 and 14 are PPPoE connections and are getting their default gateway information from the server (because it may change from time to time on a DHCP connection). When the “get default gateway from server” setting is enabled, the distance value of the interface is applied with a default value of 5. The Fortigate will only put the route(s) with the lowest distance value into the routing table. Port 13 and port 14 had a value of 5 per their interface configuration so they made it in, whereas port 15 had a value of 10 set in the static route configuration, so it didn’t make it in. The funny thing here is that the two entries for ports 13 and 14 in the static routes screen were doing nothing because those entries had a distance value higher than the interface configuration. The static route configuration for port 15 was applying, but wasn’t added to the routing table because it’s value was higher than those of port 13 and 14. I removed the static routing entries for ports 13 and 14, and decreased the distance value of port 15 in the static routes screen to 5. Bingo – it works! I also wanted to change the priority of port 13 and 14 so that all Internet traffic goes over port 15 (faster connection) unless it is down. If 15 is down I want to use port 13 and 14 as backup load-balanced links. I increased the priority value of port 13 and 14 at the CLI with these commands: 
      IASLC-FW01 # config sys interface   IASLC-FW01 (interface) # edit port13  IASLC-FW01 (port13) # set priority  5  IASLC-FW01 (port13) # next  IASLC-FW01 (interface) # edit port14  IASLC-FW01 (port14) # set priority 5  IASLC-FW01 (port14) # end
    Today I learned: 1. Fortinet support and forums are wonderful! 2. Fortigate looks at routing information before policies 3. Fortigate looks at policy routes before static routes 4. Fortigate will only enter the route(s) with the lowest value into the routing table, higher-distance routes will not be entered into the routing table until lower-distance routes go down. 5. When an route has a distance configured in both the Interface and Static Route screens (as is the case with DHCP PPPoE connections with default gateway information coming from the server) the Interface configuration will take precedence. Thank you all for your time!
    RH2
    RH2
    New Member
    February 8, 2013
    check your interface and dhcp settings. You show your are using a 32 bit netmask, that means the network connected to that interface only contains 1 host, the interface itself. So nothing else on that interface will get through. The other issue could be the three default routes. There should only be one, especially for testing.
    Terms & ConditionsAccessibility statement