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

[MX] Traffic is incorrectly forwarded when using the same IP address for NAT pool and a physical interface

0

0

Article ID: KB31994 KB Last Updated: 26 Jul 2017Version: 1.0
Summary:

When using the same IP address for the Network Address Translation (NAT) pool and a physical interface on MX series, traffic is not correctly forwarded to the service interface.

Symptoms:

Example topology and setup:

ge-1/1/0 >> 50.1.1.10/24
ge-1/2/9 >> 50.1.1.100/24
ge-1/2/4 >> 60.1.1.100/24
ge-1/0/4 >> 60.1.1.10/24

 
R2 doing the translation
 
From R2 configuration:

user@R2# show services
service-set sset1{
    stateful-firewall-rules sf1;
    nat-rules rule1;
    interface-service {
        service-interface ms-3/0/0;
    }
}
stateful-firewall {
    rule sf1 {
        match-direction input-output;
        term nat-apps {
            from {
                application-sets accept-algs;
            }
            then {
                accept;
            }
        }
        term accept {
            then {
                accept;
            }
        }
    }
}
nat {
    pool pool1 {
        address 60.1.1.100/32; ## same address as in R2’s ge-1/2/4 interface
        port {
            automatic {
                random-allocation;
            }
            secured-port-block-allocation block-size 256 max-blocks-per-address 2 active-block-timeout 1200;
        }
        address-allocation round-robin;
    }
    rule rule1 {
        match-direction input;
        term nat {
            from {
                source-prefix-list {
                    test-prefix-list;
                }
            }
            then {
                translated {
                    source-pool pool1;
                    translation-type {
                        napt-44;
                    }
                }
                syslog;
            }
        }
        term else {
            then {
                no-translation;
            }
        }
    }
}
 
user@R2# show policy-options prefix-list test-prefix-list
50.1.1.0/24;
 
user@R2# show interfaces
ge-1/2/4 {
    unit 0 {
        family inet {
            address 60.1.1.100/24; ## same address as in the NAT pool
        }
    }
}
ge-1/2/9 {
    unit 0 {
        family inet {
            service {
                input {
                    service-set sset1;
                }
                output {
                    service-set sset1;
                }
            }
            address 50.1.1.1/24;
        }
    }
}
ms-3/0/0 {
    }
    unit 0 {
        family inet
    }
}



When sourcing traffic from R1 destined to R3 (matching the NAT rule so it can be processed by the service interface):
 
user@R1> ping source 50.1.1.10 60.1.1.10
PING 60.1.1.10 (60.1.1.10): 56 data bytes
^C
--- 60.1.1.10 ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss
>>>>>>>>>>> No response

 
From R3 we see the echo request and reply for the new IP address after R2 device NATed the traffic:
 
user@R3> monitor traffic interface ge-1/0/4 size 1500 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-1/0/4, capture size 1500 bytes
 
08:14:04.638117  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 30131, seq 0, length 64
08:14:04.638147 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 0, length 64
08:14:05.638713  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 30131, seq 1, length 64
08:14:05.638741 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 1, length 64
08:14:06.639689  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 30131, seq 2, length 64
08:14:06.639717 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 2, length 64

 
If we take a look at R2:
 
user@R2> monitor traffic interface ge-1/2/4 size 1500 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-1/2/4, capture size 1500 bytes 

15:14:04.638408  In IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 0, length 64
15:14:05.638972  In IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 1, length 64
15:14:06.639922  In IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 30131, seq 2, length 64

The packets are not being forwarded back into the service interface to reach the originator.

Cause:

The cause of this behavior can bee seen on the routing table:

user@R2> show route 60.1.1.100
 
inet.0: 8 destinations, 9 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
60.1.1.100/32    *[Local/0] 00:29:26 
                              Local via ge-1/2/4.0 ### IP configured on the physical interface
                        [Static/1] 00:33:35
                              Service to sset1

In inet.0 (the routing-instance in which the outside interface resides), a static route (preference 1) will be automatically created for the NAT pool pointing to the service outside interface for the return traffic to be de-NAT'd.The route preference for the local route will always be more preferred than the static route pointing to the service interface so traffic will not hit the service interface and will be treated as host-inbound.

Solution:

The configured address, either on the interface or the NAT pool, has to be changed so that they do not match.

user@R2# show interfaces ge-1/2/4
unit 0 {
    family inet {
        address 60.1.1.1/24; ## different from the address configured on the pool
    }
}
 
The following behavior is seen:
 
user@R1> ping source 50.1.1.10 60.1.1.10 count 5
PING 60.1.1.10 (60.1.1.10): 56 data bytes
64 bytes from 60.1.1.10: icmp_seq=0 ttl=63 time=1.387 ms
64 bytes from 60.1.1.10: icmp_seq=1 ttl=63 time=0.906 ms
64 bytes from 60.1.1.10: icmp_seq=2 ttl=63 time=0.896 ms
64 bytes from 60.1.1.10: icmp_seq=3 ttl=63 time=0.865 ms
64 bytes from 60.1.1.10: icmp_seq=4 ttl=63 time=0.851 ms
 
--- 60.1.1.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.851/0.981/1.387/0.204 ms
 
user@R3> monitor traffic interface ge-1/0/4 size 1500 n
verbose output suppressed, use <detail> or <extensive> for full
Address resolution is OFF.
Listening on ge-1/0/4, capture size 1500 bytes
 
08:32:29.900661  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 61586, seq 0, length 64
08:32:29.900691 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 61586, seq 0, length 64
08:32:30.901362  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 61586, seq 1, length 64
08:32:30.901391 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 61586, seq 1, length 64
08:32:31.902352  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 61586, seq 2, length 64
08:32:31.902381 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 61586, seq 2, length 64
08:32:32.903319  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 61586, seq 3, length 64
08:32:32.903346 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 61586, seq 3, length 64
08:32:33.904313  In IP 60.1.1.100 > 60.1.1.10: ICMP echo request, id 61586, seq 4, length 64
08:32:33.904340 Out IP 60.1.1.10 > 60.1.1.100: ICMP echo reply, id 61586, seq 4, length 64
 
 
user@R1> monitor traffic interface ge-1/1/0 size 1500 no-resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-1/1/0, capture size 1500 bytes
 
08:32:29.899929 Out IP 50.1.1.10 > 60.1.1.10: ICMP echo request, id 40836, seq 0, length 64
08:32:29.901101  In IP 60.1.1.10 > 50.1.1.10: ICMP echo reply, id 40836, seq 0, length 64
08:32:30.900920 Out IP 50.1.1.10 > 60.1.1.10: ICMP echo request, id 40836, seq 1, length 64
08:32:30.901708  In IP 60.1.1.10 > 50.1.1.10: ICMP echo reply, id 40836, seq 1, length 64
08:32:31.901909 Out IP 50.1.1.10 > 60.1.1.10: ICMP echo request, id 40836, seq 2, length 64
08:32:31.902685  In IP 60.1.1.10 > 50.1.1.10: ICMP echo reply, id 40836, seq 2, length 64
08:32:32.902900 Out IP 50.1.1.10 > 60.1.1.10: ICMP echo request, id 40836, seq 3, length 64
08:32:32.903658  In IP 60.1.1.10 > 50.1.1.10: ICMP echo reply, id 40836, seq 3, length 64
08:32:33.903891 Out IP 50.1.1.10 > 60.1.1.10: ICMP echo request, id 40836, seq 4, length 64
08:32:33.904638  In IP 60.1.1.10 > 50.1.1.10: ICMP echo reply, id 40836, seq 4, length 64
 

Packets are now being forwarded correctly. 
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