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

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.

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.

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.



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
5. Because the next-hop IP address is not specified in the default route, the firewall is doing an ARP for 4.2.2.2.


6. 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.


7. 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.


8. 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.

1. The debug for this packet is shown below



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


2. 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.


3. 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.