Support Support Downloads Knowledge Base Juniper Support Portal 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

[EOL/EOE] [ScreenOS] How to route the traffic to the same remote destination via more than one gateway on the same subnet as that of the firewall?

0

0

Article ID: KB14429 KB Last Updated: 18 Mar 2021Version: 9.0
Summary:
Note: A product listed in this article has either reached hardware End of Life (EOL) OR software End of Engineering (EOE). 
Refer to End of Life Products & Milestones for the EOL, EOE, and End of Support (EOS) dates.

Routing traffic to the same remote destination via more than one gateway on the same subnet as that of the firewall.

Symptoms:

Customer has the network diagram where in the remote user can send traffic to the firewall, in an asymmetrical way, and the traffic could arrive into the firewall from any of the three different gateway (in the same subnet as that of the firewall).

The diagram of the network appears to be as follows:

                               |----[1.1.1.2]Gateway1----|
                               |                         |
      ---- FW[1.1.1.1]----switch----[1.1.1.3]Gateway2---ISP----router----2.2.2.0/24-- USER's
 DMZ  |                        |                         |    
      |                        |----[1.1.1.4]Gateway3----|
    server


The three gateways were doing the load balancing.

This a asymmetrical routing issue in the network. In this case the problem is with the reverse route lookup on the firewall. By default the reverse route lookup (after ScreenOS 6.0.0r1) is set to 'Prefer reverse-route', which performs a reverse-route lookup first, and if no route is found, uses the MAC cache.   To check the setting on the firewall, enter the following command:

nsisg2000-> get flow | i reverse
reverse route setting:
clear-text or first packet going into tunnel: prefer reverse route (default)
first packet from tunnel: always reverse route (default)

In this scenario, looking at the routing table, the following observation was made.

nsisg2000-> get route | i 2.2.2.0

* 8      2.2.2.0/24      eth0/2    1.1.1.2 S 20    1    Root--------this route is in the top of the routing table for 2.2.2.0/24 network.
* 9      2.2.2.0/24      eth0/2    1.1.1.3 S 20    1    Root
* 10     2.2.2.0/24      eth0/2    1.1.1.4 S 20    1    Root-------- this route is in the bottom of routing table for 2.2.2.0/24 network.


When the packet arrives on the firewall from the gateway 1.1.1.4, the firewall does a reverse route look-up and finds the route ID 8 (via 1.1.1.2) as the best route for that remote network and installs it in the session table. And when the syn-ack from the server in the DMZ arrives it uses route ID 8 to send the packet out to gateway 1.1.1.2. This creates a problem and the users are not able to access the server in the DMZ, because the SYN arrives from 1.1.1.4 and the SYN-ACK goes to 1.1.1.2.

An attempt was made to reduce the preference for the route  to 10; however that only worked when the traffic arrived from gateway 1.1.1.4, and failed for all other gateways.
 
Solution:

In ScreenOS 6.0.0 and above, the following command was introduced:

set flow reverse-route clear-text prefer
This is by default enabled on the firewall.

So in order for the reverse traffic to use the same route, unset the above command:
unset flow reverse-route clear-text

NOTE: This command is a replacement of the command, unset arp always-on-dest, used in previous ScreenOS versions.

Now after enabling this command the firewall will not do a reverse route lookup. Rather it uses the mac-cache entry (entry is made with the first packet of the session) to forward the reverse packet i.e syn-ack to the same gateway from where the SYN packet had arrived initially.

This resolved the problem and while the packets were arriving from all the three gateways, the reverse packet was also using the same gateway from where the first packet arrived initially.

The reverse route lookup has resolved many issues like this one. There are three different methods for the reverse route lookup.  Below are the commands to change the behavior and their corresponding meaning.

Clear-text (simple pass through traffic):
  • set flow reverse-route clear-text always---------------------> Always perform reverse-route lookup; do not use MAC cache.
  • set flow reverse-route clear-text prefer (default)-----------> Perform reverse-route lookup first , and if no route is found, use MAC cache
  • unset flow reverse-route clear-text---------------------------->Do not reverse-route instead use MAC cache.

The reverse route concept is slightly different in case of a route based VPNs:

First packet from tunnel (VPN traffic):
  • set flow reverse-route tunnel always-------------->Always perform reverse-route lookup; do not use tunnel on which packet arrived.
  • set flow reverse-route tunnel prefer (default)--->Perform reverse-route lookup first, and if no route is found, use tunnel on which packet arrived.
  • unset flow reverse-route tunnel--------------------> Do not reverse-route: use tunnel on which packet arrived.

NOTE: Reverse route lookup does not work for policy based VPNs. For packets arriving from policy-based tunnels, traffic in the return direction is routed back through the same tunnel.
Modification History:

2021-02-21: content reviewed for accuracy; article marked as EOL/EOE
2020-03-02: Minor, non-technical update.
2019-07-06: Article reviewed for accuracy. No changes made. Article is correct and complete

Related Links

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