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] Packet being NATed to the IP address of the primary ISP's interface IP address which is inactive instead of the secondary ISP which is active

0

0

Article ID: KB22135 KB Last Updated: 21 Nov 2011Version: 1.0
Summary:
This article describes the issue of the packet being NATed to the IP address of the primary ISP’s interface IP address, which is inactive, instead of the secondary ISP which is active.
Symptoms:
Environment:

  • A customer has 2 WAN interfaces (eth0/1 primary and eth0/0 secondary interface).

  • 2 default route with different metrics.

  • A primary link (eth0/1) and a secondary Link (eth0/0). See the output of get route before the failover:

IPv4 Dest-Routes for <trust-vr> (73 entries)
--------------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------------
4046 0.0.0.0/0 eth0/0 193.253.160.3 C 0 2 Root
*12 0.0.0.0/0 eth0/1 213.188.180.234 S 0 3 Root---Active route

A TCP session is created with the primary route on the firewall. There was interface based NAT occurring in the traffic, so the traffic went out with the primary interface IP as the source IP. See the below output of get session id:

SSG20-DATAMFGP-> get session id 6286
id 6286(0000188e), flag 00000000/0000/0001/0000, vsys id 0(Root)
policy id 1, application id 0, dip id 2, state 0
current timeout 300, max timeout 300 (second)
status normal, start time 2058829, duration 0
session id mask 0, app value 0
bgroup0(vsd 0): 192.168.4.8/1117->193.159.160.145/80, protocol 6 session token 3
route 7
gtwy 193.159.160.145, mac 000c293ac81a, nsptn info 0, pmtu 1500
flag 801801, diff 0/0
port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
ethernet0/1(vsd 0): 213.188.180.233/1719<-193.159.160.145/80, protocol 6 session
token 4 route 12

gtwy 193.253.160.3, mac 00901a40f2f4, nsptn info 0, pmtu 1500
mac 000000000000, nsptn info 0
flag 10003800, diff 0/0
port seq 0, subif 0, cookie 0, fin seq 0, fin state 0

Now when the primary route goes down, the route reflection happens in the session (session id 6286) and traffic goes through the secondary route. But the interface based NAT, does not get reflected in the session; the traffic goes out with the source IP as of the primary interface, through the secondary interface.

As a result, the traffic is getting dropped at the next hop and the reply traffic is failing.

See the below routing after failover:

IPv4 Dest-Routes for <trust-vr> (73 entries)
--------------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------------
* 4046 0.0.0.0/0 eth0/0 193.253.160.3 C 0 2 Root---Active route after the failover
12 0.0.0.0/0 eth0/1 213.188.180.234 S 0 3 Root

See the output of the same session after failover:

SSG20-DATAMFGP-> get session id 6286
id 6286(0000188e), flag 00000000/0000/0001/0000, vsys id 0(Root)
policy id 1, application id 0, dip id 2, state 0
current timeout 300, max timeout 300 (second)
status normal, start time 2058829, duration 0
session id mask 0, app value 0
bgroup0(vsd 0): 192.168.4.8/1117->193.159.160.145/80, protocol 6 session token 3
route 7
gtwy 193.159.160.145, mac 000c293ac81a, nsptn info 0, pmtu 1500
flag 801801, diff 0/0
port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
ethernet0/0(vsd 0): 213.188.180.233/1719<-193.159.160.145/80, protocol 6 session--->Session updated with the interface.
token 3 route 4096

gtwy 193.253.160.3, mac 00901a40f2f4, nsptn info 0, pmtu 1500
mac 000000000000, nsptn info 0
flag 10003800, diff 0/0
port seq 0, subif 0, cookie 0, fin seq 0, fin state 0

See the output of debug flow basic below:

SSG20-DATAMFGP-> get db str
****** 147585.0: <Trust/bgroup0> packet received [912]******
ipid = 16207(3f4f), @0397a570
packet passed sanity check.
flow_decap_vector IPv4 process
bgroup0:192.168.4.8/1117->193.159.160.145/80,6<Root>
existing session found. sess token 3
flow got session.
flow session id 6286
flow_main_body_vector in ifp bgroup0 out ifp N/A
flow vector index 0x103, vector addr 0x4305ecc, orig vector 0x4305ecc
tcp seq check.
post addr xlation: 213.188.180.233->193.159.160.145.
send out through normal path.
flow_ip_send: 3f4f:213.188.180.233->193.159.160.145,6 => ethernet0/0(912) flag 0x0, vlan 0
send packet to traffic shaping queue.
flow_ip_send: 3f4f:213.188.180.233->193.159.160.145,6 => ethernet0/0(912) flag 0x20000, vlan 0
pak has mac
Send to ethernet0/0 (934)

Cause:

Solution:
This is expected behavior; there is no workaround. However, the only way to resolve this issue, would be to have the customer apply for a routable public IP address though the regional authority, and inform both ISP's so that they can add the IP on their routing tables.

BGP peering would be needed in this case; the routable IP would have to be setup as a loopback interface and the internal traffic will be routed to this loopback interface that has a routable IP recognized by both ISP's.


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