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

Next-Hop-Style service-set configuration for Network Address Translation (NAT) and Stateful-Firewall (SFW)

0

0

Article ID: KB8241 KB Last Updated: 12 Jul 2012Version: 4.0
Summary:

When configuring NAT and SFW in a next-hop-style service-set, a static route can be used to direct return traffic to the source host.

Symptoms:

With source-based dynamic NAT and Stateful Firewall configured on the router, ICMP echo replies from the outside (untrusted) network are not forwarded to the inside (trusted) network.

Solution:

The trusted zone is configured in a virtual router, while the untrusted zone remains in inet.0, using a next-hop service-set.

Topology

                         Trust                   Untrust
1.1.1.0/24-----Niles------------------Felix-----------------Crunch
                           ^                         ^
                      41.41.41.0/24           42.42.42.0/24

pre-NAT SRC  IP: 1.1.1.1
post-NAT SRC IP: 68.238.167.250
Final DST IP: 11.11.11.11 (Crunch lo0)


Relevant configuration info for Felix:

routing-instances {
    TEST {
        instance-type virtual-router;
        interface sp-1/2/0.1;
        interface fe-0/1/3.0;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop sp-1/2/0.1;
            }
        }
    }
}
interfaces {
    sp-1/2/0 {
        unit 1 {
            family inet;
            service-domain inside;
        }
        unit 2 {
            family inet;
            service-domain outside;
        }
    }
}
services {
    stateful-firewall {
        rule TEST-SFW {
            match-direction input;
            term ping {
                then {
                    accept;
                }
            }
        }
    }
    nat {
        pool TEST-NAT-POOL {
            address 68.238.167.250/32;
            port automatic;
        }
        rule TEST-NAT-RULE {
            match-direction input;
            term 10 {
                then {
                    translated {
                        source-pool TEST-NAT-POOL;
                        translation-type source dynamic;
                    }
                }
            }
        }
    }
    service-set TEST {
        stateful-firewall-rules TEST-SFW;
        nat-rules TEST-NAT-RULE;
        next-hop-service {
            inside-service-interface sp-1/2/0.1;
            outside-service-interface sp-1/2/0.2;
        }
    }
}


ICMP echo requests are sent from Niles to Crunch:

 

felix-re0> show services stateful-firewall flows extensive
Interface: sp-1/2/0, Service set: TEST
Flow                                                State    Dir       Frm count
ICMP           1.1.1.1:2300  ->    11.11.11.11       Watch    I             112
    NAT source         1.1.1.1:2300    ->  68.238.167.250:1024
  Byte count: 86688
  Flow role: Master, Timeout: 30
ICMP       11.11.11.11:4     -> 68.238.167.250       Watch    O             112
    NAT dest    68.238.167.250:4       ->         1.1.1.1:64557
  Byte count: 86688
  Flow role: Responder, Timeout: 30, Protocol detail: echo reply
ICMP       11.11.11.11:252   ->        1.1.1.1       Drop     I               2
  Byte count: 1548
  Flow role: Initiator, Timeout: 4


Crunch is sending the corresponding ICMP echo replies back towards Niles:

 

crunch-re0> monitor traffic interface fe-0/1/3
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Listening on fe-0/1/3, capture size 96 bytes
20:06:34.719503  In IP 68.238.167.250 > 11.11.11.11: ICMP echo request seq 60937, length 1480
20:06:34.719592 Out IP 11.11.11.11 > 68.238.167.250: ICMP echo reply seq 60937, length 1480


The ICMP echo replies are getting dropped by the Adaptive Services PIC (AS-PIC) at Felix, because the traffic is incorrectly routed from within the virtual-router.  The only available route to 1.1.1.1 points towards the inside services interface, by means of a default route. Thus, the ICMP echo replies are incorrectly sent back to the AS-PIC for transmission. This is resolved by configuring a static route that points to the correct next-hop:

routing-instances {
    TEST {
        instance-type virtual-router;
        interface fe-0/1/3.0;
        interface sp-1/2/0.1;
        routing-options {
            static {
                route 1.1.1.0/24 next-hop 41.41.41.1;
                route 0.0.0.0/0 next-hop sp-1/2/0.1;
            }
        }
    }
}


The newly-configured static route is now correctly pointing towards the destination of the ICMP echo replies. Packets destined towards the untrusted zone continue to point to the inside service interface (as seen above).

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