Knowledge Search


×
 

[ScreenOS] Traffic going out of my network fails or works intermittenly with a default route set with no gateway

  [KB15682] Show Article Properties


Summary:
Read below to understand why traffic fails when no gateway is specified for a default route. 
Symptoms:
Traffic fails when the default route has no specified gateway or next-hop.
Solution:
When a default route is set with no gateway (as below), traffic may not arrive.
set route 0.0.0.0/0 interface ethernet1/1
This is because 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.

To show how this works, follow this example:

First, a default route is set with just the interface.  Note that no gateway IP exists in the routing table. The gateway is not set, so there is no next hop for the traffic.
ISG2000-> set route 0.0.0.0/0 int eth1/1
ISG2000-> clear db
ISG2000-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (4 entries)
--------------------------------------------------------------------------------------
ID     IP-Prefix   Interface   Gateway     P Pref Mtr Vsys
--------------------------------------------------------------------------------------

* 1    0.0.0.0/0   eth1/1       0.0.0.0    S 20   1   Root


ISG2000-> ping 1.1.1.1
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 1 seconds
.....
Success Rate is 0 percent (0/5)

The ping failed at this point. This is the debug output from one of the failed ICMP ping packet fails:
ISG2000-> get db str
****** 00533.0: <Self/self> packet received [128]******
ipid = 1410(0582), @6cc5bb54
flow_self_vector2: send pack with current vid =0, enc_size:0
processing packet through normal path.
packet passed sanity check.
flow_decap_vector IPv4 process
self:172.18.68.67/13000->1.1.1.1/1024,1(8/0)<Root>
no session found
created new session from self 1048553
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
search policy for self zone packet, get 320000.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
policy id = 320000(Deny), tunnel = 0
search route to (null, 0.0.0.0->1.1.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-eth1/1
[ Dest] 12.route 1.1.1.1->1.1.1.1, to eth1/1
routed 1.1.1.1 next hop 1.1.1.1, from self
existing vector list 0-6cffc834.
processing packet from self
flow_first_install_session======>
route to 1.1.1.1
wait for arp rsp for 1.1.1.1
ifp2 eth1/1, out_ifp eth1/1, flag 00000600, tunnel ffffffff, rc 0
outgoing wing prepared, not ready
The reason for the failure is that the firewall is waiting for an ARP response from this IP, as if it was on a connected segment. This is indicated by the 'wait for arp rsp for 1.1.1.1' which it never receives. It then drops the packet with the message 'outgoing wing prepared, not ready'.  This indicates that there is no ARP response; therefore no layer2 connection (no MAC address) to send the packet out on, and the packet is dropped.


Below, the default route with no gateway is removed, and replaced with a new default route with the interface AND the next hop:
ISG2000-> unset route 0.0.0.0/0
total routes deleted = 1
ISG2000-> set route 0.0.0.0/0 int eth1/1 gateway 172.18.68.1
ISG2000-> get route

IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
N: NHRP
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2 trailing B: backup route


IPv4 Dest-Routes for <trust-vr> (4 entries)
--------------------------------------------------------------------------------------
ID    IP-Prefix   Interface   Gateway      P Pref Mtr Vsys
--------------------------------------------------------------------------------------
* 2   0.0.0.0/0   eth1/1      172.18.68.1  S 20   1   Root
The routing table now shows the default route, the interface, and the gateway of the next hop router.
A ping to the same IP we tried before should now work:
ISG2000-> ping 1.1.1.1
Type escape sequence to abort

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 1 seconds
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=41/41/42 ms
ISG2000->
The result is showing that the pings were able to all get to their destination, and get a response.
The debug for this packet shows:
****** 00566.0: <Self/self> packet received [128]******
ipid = 1425(0591), @6cc5c314
flow_self_vector2: send pack with current vid =0, enc_size:0
processing packet through normal path.
packet passed sanity check.
flow_decap_vector IPv4 process
self:172.18.68.67/13900->1.1.1.1/1024,1(8/0)<Root>
no session found
created new session from self 1048568
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
search policy for self zone packet, get 320000.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
policy id = 320000(Deny), tunnel = 0
search route to (null, 0.0.0.0->1.1.1.1) in vr trust-vr for vsd-0/flag-2000/ifp-eth1/1
[ Dest] 13.route 1.1.1.1->172.18.68.1, to eth1/1
routed 1.1.1.1 next hop 172.18.68.1, from self
existing vector list 0-6cffc834.
processing packet from self
flow_first_install_session======>
route to 172.18.68.1
arp entry found for 172.18.68.1
ifp2 eth1/1, out_ifp eth1/1, flag 00800600, tunnel ffffffff, rc 1
outgoing wing prepared, ready
flow got session.
flow session id 1048568
flow_main_body_vector in ifp self out ifp eth1/1
flow vector index 0x0, vector addr 0x330073c, orig vector 0x330073c
skip ttl adjust for packet.
post addr xlation: 172.18.68.67->1.1.1.1.
packet send out to 0010db69a5f0 (cached) through eth1/1
00566.0: eth1/1(o) len=142:0010db7ad100->0010db69a5f0/0800
172.18.68.67 -> 1.1.1.1/1
vhl=45, tos=00, id=1425, frag=0000, ttl=64 tlen=128
icmp:type=8, code=0
The difference seen between these setups is that the firewall found the MAC address (0010db69a5f0) in it's ARP table for the IP of 172.18.68.1(the default router where the next hop packets are sent to). It was then able to build the frame and forward it out of the eth1/1 interface, to that gateway router.  The gateway was able to route the packet to it's next hop, until the packet reaches the designated remote system, which then responds back.
Modification History:
2019-09-09: Article reviewed for accuracy.
Related Links: