Knowledge Search


×
 

[ScreenOS] Why is it necessary to specify 'Gateway IP address for Next Hop' during the configuration of static default route?

  [KB28674] Show Article Properties


Summary:

This article describes the importance of the next-hop gateway IP address in the configuration of a static default route.

Symptoms:

The goal of this article is to understand the behavior of the firewall during the presence and absence of gateway IP address in static default route.

Cause:

Solution:

Network Setup

192.168.2.0/24---- eth0/0 [SSG] eth0/1(1.1.1.1)------(1.1.1.2)[ISP router]-----

Scenario I: Next-hop gateway IP address is not specified in the static default route.

SSG-> set route 0.0.0.0/0 int eth0/1
  1. It is desired to access the Internet via the firewall.

  2. A static default route, 192.168.2.0/24, and a policy have been configured for the internal LAN to reach the Internet.

  3. For testing purpose, continuous ping to global DNS server 4.2.2.2 is initiated but all the pings are unsuccessful.

  4. During troubleshooting, the command debug flow basic gives an insight into the packet flow and the reason for ping failure.


  5. SSG-> get db st
    ****** 38410.0: <Trust/ethernet0/0> packet received [128]******
    ipid = 30129(75b1), @02a44354
    self:192.168.2.1/46464->4.2.2.2/1024,1(8/0)<Root>
    flow_decap_vector IPv4 process
    ethernet0/0:192.168.2.1/46464->4.2.2.2/1024,1(8/0)<Root>
    no session found
    flow_first_sanity_check: in <ethernet0/0>, out <ethernet0/1>
    chose interface ethernet0/0 as incoming nat if.
    flow_first_routing: in <ethernet0/0>, out <ethernet0/1>
    search route to (ethernet0/0, 192.168.2.1->4.2.2.2) in vr trust-vr for vsd-0/flag-0/ifp-null
    cached route 16 for 4.2.2.2
    [ Dest] 16.route 4.2.2.2->4.2.2.2, to ethernet0/1
    routed (x_dst_ip 4.2.2.2) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/1
    policy search from zone 2-> zone 1
    policy_flow_search policy search nat_crt from zone 2-> zone 1
    RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 4.2.2.2, port 41649, proto 1)
    No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 2/1/0x1
    Permitted by policy 2
    interface-nat dip id = 2, 192.168.2.1/46464->1.1.1.1/18099
    choose interface ethernet0/1 as outgoing phy if
    no loop on ifp ethernet0/1.
    session application type 0, name None, nas_id 0, timeout 60sec
    service lookup identified service 0.
    flow_first_final_check: in <ethernet0/0>, out <ethernet0/1>
    existing vector list 1-dfcd174.
    Session (id:63395) created for first pak 1
    flow_first_install_session======>
    route to 4.2.2.2
    cached arp entry with MAC 000000000000 for 4.2.2.2
    add arp entry with MAC 000000000000 for 4.2.2.2 to cache table
    wait for arp rsp for 4.2.2.2

    ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10000e00, tunnel ffffffff, rc 0
    outgoing wing prepared, not ready

    SSG-> get route | i 4.2.2.2
    * 16 0.0.0.0/0 eth0/1 0.0.0.0 S 20 1 Root
  6. Because the next-hop IP address is not specified in the default route, the firewall is doing an ARP for 4.2.2.2.

  7. When the firewall needs to forward a packet via the default route, it needs the MAC address of the default router in order to build the frame to forward the packet.

  8. The reason for the failure is that the firewall is waiting for an ARP response from 4.2.2.2, as if it was on a connected segment. This is indicated by the 'wait for arp rsp for 4.2.2.2',  which it never receives.

  9. It then drops the packet with the message 'outgoing wing prepared, not ready' which indicates that there is no ARP response;

Scenario II: Next-hop gateway ip address is specified in the static default route.

SSG-> set route 0.0.0.0/0 int eth0/1 gateway 1.1.1.2
  1. The debug for this packet is shown below


  2. SSG-> get db st
    ****** 38953.0: <Trust/ethernet0/0> packet received [128]******
    ipid = 37853(93dd), @02a44d04
    self:192.168.2.1/47864->4.2.2.2/1024,1(8/0)<Root>
    flow_decap_vector IPv4 process
    ethernet0/0:192.168.2.1/47864->4.2.2.2/1024,1(8/0)<Root>
    no session found
    flow_first_sanity_check: in <ethernet0/0>, out <ethernet0/1>
    chose interface ethernet0/0 as incoming nat if.
    flow_first_routing: in <ethernet0/0>, out <ethernet0/1>
    search route to (ethernet0/0, 192.168.2.1->4.2.2.2) in vr trust-vr for vsd-0/flag-0/ifp-null
    cached route 0 for 4.2.2.2
    add route 15 for 4.2.2.2 to route cache table
    [ Dest] 15.route 4.2.2.2->1.1.1.2, to ethernet0/1
    routed (x_dst_ip 4.2.2.2) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/1
    policy search from zone 2-> zone 1
    policy_flow_search policy search nat_crt from zone 2-> zone 1
    RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 4.2.2.2, port 40249, proto 1)
    No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 2/1/0x1
    Permitted by policy 2
    interface-nat dip id = 2, 192.168.2.1/47864->1.1.1.1/31899
    choose interface ethernet0/1 as outgoing phy if
    no loop on ifp ethernet0/1.
    session application type 0, name None, nas_id 0, timeout 60sec
    service lookup identified service 0.
    flow_first_final_check: in <ethernet0/0>, out <ethernet0/1>
    existing vector list 1-dfcd174.
    Session (id:63795) created for first pak 1
    flow_first_install_session======>
    route to 1.1.1.2
    cached arp entry with MAC 000000000000 for 1.1.1.2
    add arp entry with MAC 002688e8c305 for 1.1.1.2 to cache table
    arp entry found for 1.1.1.2

    ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10800e00, tunnel ffffffff, rc 1
    outgoing wing prepared, ready
    flow got session.
    flow session id 63795
    flow_main_body_vector in ifp ethernet0/0 out ifp ethernet0/1
    flow vector index 0x1, vector addr 0x1a808f0, orig vector 0x1a808f0
    post addr xlation: 1.1.1.1->4.2.2.2.

    SSG-> get route | i 4.2.2.2
    * 15 0.0.0.0/0 eth0/1 1.1.1.2 S 20 1 Root

  3. In this scenario, the firewall found the MAC address for the next-hop gateway (ISP router with ip 1.1.1.2) in its ARP table.

  4. It was then able to build the frame and forward the packet to the ISP router, which in turn routed the packet to its next hop, until the packet reached the destination IP 4.2.2.2.
Related Links: