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

Web browser hangs - Unable to Pass Traffic using Policy Based Routing (PBR) across Multiple Virtual Routers (VR)

0

0

Article ID: KB11447 KB Last Updated: 21 Sep 2011Version: 6.0
Summary:

Multiple WAN connections available to the Internet.  Goal is to route all Web (HTTP) traffic through one WAN connection, while allowing all other traffic to go out through the other WAN connection, using Policy-Based Routing (PBR)

Symptoms:

Policy-Based Routing (PBR) is configured to route HTTP/Web traffic, but when attempting to pass HTTP/Web traffic, the Web browser hangs, and it does not try to connect to the web site.

Solution:

With PBR configured on a Juniper firewall with multiple VR's, a static host route for the next hop in the destination VR must be set.

For example, assume you have the following topology:

    172.16.10.229
         |
      Internet
         |
         |
       Router
         | 10.1.1.1
         |
         | 10.1.1.130
   ---------------
   | (untrust-vr)|
   |--------------
   | (trust-vr)  |
    --------------
         |192.168.1.1
         |
         |
192.168.1.27
        PC
  

The intended goal is to send traffic to 172.16.10.229 from the PC. 
On the firewall, there is a specific PBR route to send traffic for port 80 through the untrust-vr to the next hop router 10.1.1.1.  However, when doing a debug flow basic, we see that traffic stalls due to "waiting for arp rsp":

****** 544860.0: <Trust/ethernet1> packet received [48]******
  ipid = 48660(be14), @d7816910
  packet passed sanity check.
  ethernet1:192.168.1.27/3506->172.16.10.229/80,6<Root>
  no session found
  flow_first_sanity_check: in <ethernet1>, out <N/A>
  chose interface ethernet1 as incoming nat if.
  flow_first_routing: in <ethernet1>, out <N/A>
  search route to (ethernet1, 192.168.1.27->172.16.10.229) in vr trust-vr for
 vsd-0/flag-0/ifp-null
PBR lookup params: dst-ip: 172.16.10.229, src-ip: 192.168.1.27, dst-port: 80,
 src-port: 3506, protocol: 6, dscp: 0
  [PBR route] 15.route 172.16.10.229->0.0.0.0, to ethernet2
  routed (x_dst_ip 172.16.10.229) from ethernet1 (ethernet1 in 0) to ethernet2
  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 207.
17.137.229, port 80, proto 6)
  No SW RPC rule match, search HW rule
  Permitted by policy 151
  dip id = 2, 192.168.1.27/3506->10.1.1.130/50450
  choose interface ethernet2 as outgoing phy if
  no loop on ifp ethernet2.
  session application type 6, name HTTP, nas_id 0, timeout 1800sec
  service lookup identified service 0.
  flow_first_final_check: in <ethernet1>, out <ethernet2>
  existing vector list 3-635ee20.
  Session (id:62894) created for first pak 3
  flow_first_install_session======>
  route to 172.16.10.229
  wait for arp rsp for 172.16.10.229
  nsp2 wing prepared, not ready
  cache mac in the session
  make_nsp_ready_no_resolve()
  search route to (ethernet2, 172.16.10.229->192.168.1.27) in vr trust-vr for
 vsd-0/flag-3000/ifp-ethernet1
  [ Dest] 4.route 192.168.1.27->192.168.1.27, to ethernet1
  route to 192.168.1.27


The problem here is the destination IP uses a next-hop IP which is on the untrust-vr connected route, and it bounces back to the trust-vr, and never makes out of the untrust-vr.  The workaround is to set a static host route on the untrust-vr, with a gateway address as the next hop router.

set vr untrust-vr route 10.1.1.1/32 interface ethernet2 gateway 10.1.1.1

In the UNTRUST VR, the PBR next-hop will match this new host route and the gateway 10.1.1.1 (that also is the PBR next-hop), and this route will be used for the ARP request.  This only applies to multiple VR configurations.  The problem does not occur if using single VR configurations.

 

NOTE:  Refer to the following article for additional tips related to this solution:  
KB9404 - Configuration tips - Policy Based Routing (PBR) not working across multiple Virtual Router (VR)config

 

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