Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

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

0

0

Article ID: KB15682 KB Last Updated: 09 Sep 2019Version: 2.0
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.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search