Description

On Juniper SRX firewalls, routing architecture plays a critical role in the behavior of host-initiated traffic, including system-level services such as DNS resolution. A common and often overlooked issue arises when the SRX is deployed in a multi-instance routing environment and host-initiated DNS queries fail because the DNS destination is not reachable through the master routing instance, even though a valid route exists within a custom virtual router.

 

This article explains the root cause of this behavior, demonstrates the failure scenario with supporting CLI output, and outlines the available resolution options.

Symptoms

    • On SRX firewalls, active routes are installed into the inet.0 routing table, which serves as the primary RIB (Routing Information Base) for the master routing instance.
    

    root@SRX# set routing-options static route 0.0.0.0/0 next-hop 192.168.1.1
    

    root@SRX# commit
    

    


    root@SRX> show route

inet.0: x destinations,
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5]
                    > to 192.168.1.1 via ge-0/0/1.0


    root@SRX> show route instance

Instance          Type
      Primary RIB                         Active/holddown/hidden
master            forwarding
      inet.0                              4/0/0
      inet6.0                             1/0/0

    

    • By default, host-initiated outbound traffic on the SRX, including DNS resolution, is sourced from the master routing instance and resolved against the inet.0 routing table.
    

     In a standard deployment where the default route is present in inet.0, DNS resolution functions as expected:
    

     
    

    root@SRX# set system name-server 8.8.8.8 
    

    root@SRX# commit 
    

     
    

     
    

    root@SRX> show route 8.8.8.8
    

    inet.0: x destinations,
    

    + = Active Route, - = Last Active, * = Both
    

        0.0.0.0/0 *[Static/5] 22:50:31
    

                   > to 192.168.1.1 via ge-0/0/1.0
    

    

    

    

    

    

    

    

    

    

    

    

    

    

     
    

    

    

    

    

    

    root@SRX> show host juniper.net
juniper.net has address x.x.x.x
juniper.net mail is handled by 5 p-mailhub01.juniper.net.
juniper.net mail is handled by 5 p-mailhub03.juniper.net.
    

    

    

    

    

    

    

    

    

    

    

     
    

    • 

      The master routing instance (inet.0) and a custom virtual router operate as logically isolated routing domains. Consider a deployment where the default route is not present in inet.0 but instead resides exclusively within a custom routing instance:
      

    

     
    

    root@SRX# set routing-instances Internet-Virtual-Router interface ge-0/0/1.0
    root@SRX# set routing-instances Internet-Virtual-Router instance-type virtual-router
    root@SRX# set routing-instances Internet-Virtual-Router routing-options static route 0.0.0.0/0 next-hop 192.168.1.1
    root@SRX# commit
    

     
    

    In this configuration, a route lookup for the DNS server returns no result in inet.0, while the route is present and active within the custom instance:
    

     
    

    root@SRX> show route 8.8.8.8 table inet.0
      (no output)
    

     
    

    root@SRX> show route 8.8.8.8 table Internet-Virtual-Router.inet.0
    

    Internet-Virtual-Router.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    

    0.0.0.0/0          *[Static/5] 00:33:45
                        > to 192.168.1.1 via ge-0/0/1.0
    

     
    

    • 

      Because the SRX resolves host-initiated DNS queries using the master routing instance, the query fails even though a valid path to the DNS server exists within the virtual router:
      

    

    root@SRX> show host juniper.net
    ; connection timed out; no servers could be reached
    

     
    

    Note: DNS server configuration is not supported within custom routing instances on the SRX platform.
    

     
    

     
    

    • Additionally, specifying a routing instance within the system-level DNS server configuration alone does not resolve the issue :
    

    

    

    

    

    

    

    

    

    

    

    root@SRX# set system name-server 8.8.8.8 routing-instance Internet-Virtual-Router
    

    

    

    

    

    

    

    

    

    

    

     
    

     
    

    

    

    

    

    

    

    Solution
    Since DNS server configuration is restricted to the master routing instance and host-initiated queries are resolved exclusively against inet.0, the route to the DNS destination must be made available in that table. The master routing instance (inet.0) and Internet-Virtual-Router (Internet-Virtual-Router.inet.0) operate as logically isolated routing domains. As a result, the DNS server route must be explicitly shared between the two instances or made reachable via inet.0.
    

     
    

    

     
    

     
    

    Method #1: Route leaking from custom routing instance to master/inet.0 
    

     
    

    The following configuration resolves host-initiated DNS failures on SRX platforms where the DNS destination is reachable exclusively through a custom routing instance. The solution leverages a RIB group to expose the required next-hop to inet.0, a dedicated loopback interface as the DNS source address, a source NAT rule to translate the loopback address to the internet-facing interface IP, and a return route within the custom instance to complete the path back to the master routing instance.
    

     
    

    Step 1 — Configure the Custom Routing Instance
    

    Define the virtual router instance, assign the internet-facing interface, and configure a default route:
    

     
    

    set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.2/24
    

    set security zones security-zone UNTRUST interfaces ge-0/0/1.0
    

    set routing-instances Internet-Virtual-Router interface ge-0/0/1.0
    

    set routing-instances Internet-Virtual-Router instance-type virtual-router
    

    set routing-instances Internet-Virtual-Router routing-options static route 0.0.0.0/0 next-hop 192.168.1.1
    

     
    

    Step 2 — Configure a Dedicated Loopback Interface
    

    Assign an RFC1918 /32 address to lo0.0 and place it in its own security zone. Using a /32 host address in the RFC1918 range avoids martian address conflicts that would cause the route to appear hidden in the routing table:
    

     
    

    set interfaces lo0 unit 0 family inet address 172.16.0.1/32
    

    set security zones security-zone Loopback-Zone interfaces lo0.0
    

     
    

    Step 3 — Configure the DNS Server
    

    Direct host-initiated DNS queries through the custom routing instance and bind them to the loopback source address:
    

     
    

    set system name-server 8.8.8.8 routing-instance Internet-Virtual-Router
    

    set system name-server 8.8.8.8 source-address 172.16.0.1
    

     
    

    Note: The routing-instance and source-address options under system name-server are only effective in conjunction with the complete configuration outlined in the subsequent steps. Configuring these in isolation will not resolve DNS, as demonstrated in the Problem Scenario section above.
    

     
    

    Step 4 — Configure Source NAT for DNS Packets
    

    When the SRX forwards a DNS query sourced from the loopback address (172.16.0.1) into Internet-Virtual-Router, the source address must be translated to the internet-facing interface IP (ge-0/0/1.0). Without this translation, the DNS server receives a packet sourced from a non-routable loopback address and the response will not return correctly.
    

     
    

    Configure a source NAT rule-set matching traffic crossing from the default routing instance into Internet-Virtual-Router, scoped specifically to the DNS server destination:
    

     
    

    set security nat source rule-set DNS-Pkt-Xlation from routing-instance default
    

    set security nat source rule-set DNS-Pkt-Xlation to routing-instance Internet-Virtual-Router
    

    set security nat source rule-set DNS-Pkt-Xlation rule 1 match source-address 172.16.0.1/32
    

    set security nat source rule-set DNS-Pkt-Xlation rule 1 then source-nat interface
    

     
    

    Step 5 — Leak the Connected Next-Hop Route into inet.0
    

    Configure a RIB group with an import policy scoped to the internet-facing interface. This makes the next-hop reachable from the master routing instance without exposing the default route into inet.0, preserving the routing isolation of the custom instance:
    

     
    

    set policy-options policy-statement Routing-Policy term 1 from interface ge-0/0/1.0
    

    set policy-options policy-statement Routing-Policy term 1 to rib inet.0
    

    set policy-options policy-statement Routing-Policy term 1 then accept
    

    set policy-options policy-statement Routing-Policy term 2 then reject
    

     
    

    set routing-options rib-groups Internet-vir-router-2-Inet0 import-rib Internet-Virtual-Router.inet.0
    

    set routing-options rib-groups Internet-vir-router-2-Inet0 import-rib inet.0
    

    set routing-options rib-groups Internet-vir-router-2-Inet0 import-policy Routing-Policy
    

     
    

    set routing-instances Internet-Virtual-Router routing-options interface-routes rib-group inet Internet-vir-router-2-Inet0
    

     
    

    Verify the connected route is now present in inet.0:
    

     
    

    root@SRX> show route 192.168.1.1 table inet.0
    

    inet.0:
    

    + = Active Route, - = Last Active, * = Both
    

    192.168.1.0/24   *[Direct/0]
    

                     >  via ge-0/0/1.0
    

     
    

    Step 6 — Add a Specific Host Route for the DNS Server in inet.0
    

    With the next-hop now resolvable in inet.0, install a static host route for the DNS server. This ensures only the DNS destination is reachable from the master routing instance, the default route remains isolated within the custom instance:
    

     
    

    set routing-options static route 8.8.8.8/32 next-hop 192.168.1.1
    

     
    

    Verify: 
    

    root@SRX> show route 8.8.8.8 
    

    inet.0:
    + = Active Route, - = Last Active, * = Both
    

    8.8.8.8/32   *[Static/5]
                  >  to 192.168.1.1 via ge-0/0/1.0
    

    Internet-Virtual-Router.inet.0: 
    + = Active Route, - = Last Active, * = Both
    

    0.0.0.0/0          *[Static/5] 
                        >  to 192.168.1.1 via ge-0/0/1.0
    

     
    

    Step 7 — Configure a Return Route for the Loopback Address
    

    Install a static route within the custom routing instance pointing the loopback address back to inet.0. This ensures DNS responses destined for 172.16.0.1 are correctly forwarded to the master routing instance after the NAT session completes:
    

     
    

    set routing-instances Internet-Virtual-Router routing-options static route 172.16.0.1/32 next-table inet.0
    

     
    

    Verification: 
    

     
    

    root@SRX> show host juniper.net
    

    juniper.net has address x.x.x.x
    

    juniper.net mail is handled by 5 p-mailhub03.juniper.net.
    

    juniper.net mail is handled by 5 p-mailhub01.juniper.net.
    

     
    

    root@SRX> show security flow session destination-prefix 8.8.8.8 destination-port 53
    

    Session ID: 4386, Policy name: self-traffic-policy/1, Timeout: 4, Session State: Valid
    

      In: 172.16.0.1/49575 --> 8.8.8.8/53;udp, If: .local..0, Pkts: 1, Bytes: 57,
    

      Out: 8.8.8.8/53 --> 192.168.1.2/26128;udp, If: ge-0/0/1.0, Pkts: 1, Bytes: 73
    

     
    

     
    

     
    

    Method #2:  Virtual link between inet.0 and custom routing-instance
    

     
    

    This method shows how to route DNS queries from the master routing instance (inet.0) to a custom virtual-router instance using logical tunnel (lt-0/0/0) interfaces. This method is required when the SRX management or system services must resolve DNS through an upstream interface that resides in a separate routing instance. 
    

     
    

    Step 1 — Configure Logical Tunnel and Physical Interfaces
    

    The logical tunnel interface (lt-0/0/0) creates a virtual point-to-point link between the two routing instances.Assign a dedicated subnet not used elsewhere in the network.
    

     
    

    set interfaces lt-0/0/0 unit 0 encapsulation ethernet
    set interfaces lt-0/0/0 unit 0 peer-unit 1
    set interfaces lt-0/0/0 unit 0 family inet address 10.10.10.2/30
    

    set interfaces lt-0/0/0 unit 1 encapsulation ethernet
    set interfaces lt-0/0/0 unit 1 peer-unit 0
    set interfaces lt-0/0/0 unit 1 family inet address 10.10.10.1/30
    

    set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.2/24
    

     
    

    Step 2 — Assign Interfaces to Security Zones
    

    lt-0/0/0.0 remains in inet.0 (master instance). lt-0/0/0.1 is assigned to the custom routing instance.Each unit is placed in its own security zone.
    

     
    

    set security zones security-zone UNTRUST interfaces ge-0/0/1.0
    set security zones security-zone lt-zone-0 interfaces lt-0/0/0.0 host-inbound-traffic system-services ping
    set security zones security-zone lt-zone-1 interfaces lt-0/0/0.1 host-inbound-traffic system-services ping
    

     
    

    Step 3 — Configure the Custom Routing Instance
    

    lt-0/0/0.1 and ge-0/0/1.0 are bound to Internet-Virtual-Router. A default static route points to the upstream gateway via ge-0/0/1.0.
    

     
    

    set routing-instances Internet-Virtual-Router instance-type virtual-router
    set routing-instances Internet-Virtual-Router interface lt-0/0/0.1
    set routing-instances Internet-Virtual-Router interface ge-0/0/1.0
    set routing-instances Internet-Virtual-Router routing-options static route 0.0.0.0/0 next-hop 192.168.1.1
    

     
    

    Step 4 — Configure DNS and Static Route in Master Instance
    

    A host route for 8.8.8.8 is added to inet.0 pointing to lt-0/0/0.1 (10.10.10.1) as the next hop, which moves 
    the packet from inet.0 into Internet-Virtual-Router.inet.0.
    

     
    

    set system name-server 8.8.8.8 routing-instance Internet-Virtual-Router
    set routing-options static route 8.8.8.8/32 next-hop 10.10.10.1
    


    Step 5 — Configure Security Policy
    

    Allow DNS traffic traversing from lt-zone-1 to UNTRUST within the Internet-Virtual-Router instance.
    

     
    

    set security policies from-zone lt-zone-1 to-zone UNTRUST policy DNS-Allow match source-address any
    set security policies from-zone lt-zone-1 to-zone UNTRUST policy DNS-Allow match destination-address any
    set security policies from-zone lt-zone-1 to-zone UNTRUST policy DNS-Allow match application any
    set security policies from-zone lt-zone-1 to-zone UNTRUST policy DNS-Allow then permit
    

     
    

    Step 6 — Configure Source NAT
    

    The DNS query originates with source IP 10.10.10.2 (lt-0/0/0.0 in inet.0). The DNS server must return traffic to a routable address within Internet-Virtual-Router. Source NAT translates 10.10.10.2 to the ge-0/0/1.0 interface address (192.168.1.2) to ensure the response is correctly routed back.
    

     
    

    set security nat source rule-set DNS-Req-Nat from interface lt-0/0/0.1
    set security nat source rule-set DNS-Req-Nat to interface ge-0/0/1.0
    set security nat source rule-set DNS-Req-Nat rule 1 match destination-address 8.8.8.8/32
    set security nat source rule-set DNS-Req-Nat rule 1 then source-nat interface
    

     
    

     
    

    Verification: 
    

     
    

    root@SRX> show host juniper.net
    juniper.net has address x.x.x.x
    juniper.net mail is handled by 5 p-mailhub03.juniper.net.
    juniper.net mail is handled by 5 p-mailhub01.juniper.net.
    


    root@SRX> show security flow session destination-port 53
    

    Session ID: 7618, Policy name: self-traffic-policy/1, Timeout: 2, Session State: Valid
      In:  10.10.10.2/50450  --> 8.8.8.8/53;udp,       If: .local..0,    Pkts: 1, Bytes: 57
      Out: 8.8.8.8/53     --> 10.10.10.2/50450;udp,     If: lt-0/0/0.0,   Pkts: 1, Bytes: 73
    

     
    

    Session ID: 7619, Policy name: DNS-Allow/4, Timeout: 2, Session State: Valid
      In:  10.10.10.2/50450  --> 8.8.8.8/53;udp,        If: lt-0/0/0.1,   Pkts: 1, Bytes: 57
      Out: 8.8.8.8/53     --> 192.168.1.2/12355;udp,    If: ge-0/0/1.0,   Pkts: 1, Bytes: 73
    

     
    

     
    Modification History
    05/21/2026 - Article Created
    

    05/25/2026 - Removed Public IP addresses
    

    05/26/2026 - Method #2 added
    

    05/27/2026 - KB IP addressing updated to RFC1978 
    Related Information
    KB82697 [juniper.net] [SRX] DNS Requests Across Different Routing Instances  
    

    https://supportportal.juniper.net/s/article/SRX-DNS-Requests-Across-Different-Routing-Instances
    

     
    

    KB19855 [juniper.net] [SRX] Example - How to import routes from the default routing table into other routing instance tables using policies 
    

    https://supportportal.juniper.net/s/article/SRX-Example-How-to-import-routes-from-the-default-routing-table-into-other-routing-instance-tables-using-policies