SRX Services Gateway
Reply
Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Dest NAT/PAT Issue

Hi all,

 

The code below is a representation of what I'm trying to achieve, however the SRX1400 I've applied this code to does not perform as [I] expected.

 

Summary:

- 2 destination NAT rules that match the same destination address on incoming packets (10.10.10.10/32)

- 1 of the rules (rule nat-1) is also looking for a specific destination port (9028) in order to send this specific traffic to a different internal server

 

Problem:

ALL traffic destined to 10.10.10.10, regardless of destination port number, is being picked up by the first rule "nat-1" and being NATted to "server-1".

 

Have I misinterpreted the way SRX NAT should behave, or is this a valid configuration that should work?

 

Though not shown in the config below, these are definitely applied in the "security nat destination" hierarchy.

 

pool server-1 {
    address 1.1.1.1/32 port 3389;
}
pool server-2 {
    address 2.2.2.2/32;
}

rule-set xlate-ext-2-int {
    from zone [ untrust ];

    rule nat-1 {
        match {
            destination-address 10.10.10.10/32;
            destination-port 9028;
        }
        then {
            destination-nat pool server-1;
        }
    }
    rule nat-2 {
        match {
            destination-address 10.10.10.10/32;
        }
        then {
            destination-nat pool server-2;
        }
    }

 

Thanks for any assistance offered.

 

Ben.

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Super Contributor
johnrbaker
Posts: 210
Registered: ‎02-17-2011
0

Re: Dest NAT/PAT Issue

Hi

 

What Junos version are you running?

 

There are two parts to setup when doing DST NAT.  The NAT rule and then the policy.

 

 

Your NAT rules look ok, can you post the corresponding security policy where the traffic is permitted.

 

 

Also, you could add protocol tcp to your match rule.  I had to add this recently to allow TCP 443 and UDP 4500 to allow my SA700 to use ESP correctly

 

 

 

        match {

            destination-address 10.10.10.10/32;

            destination-port 9028;

          protocol tcp;

        }

 

 

Super Contributor
AdamLin
Posts: 167
Registered: ‎08-02-2010
0

Re: Dest NAT/PAT Issue

Actually, destination NAT occurs before policy, hence you should use the private addresses in the security policy; for this example 1.1.1.1 and 2.2.2.2.
Are you certain it doesn't actually do both NAT's correctly?
show security nat destination rule all.
See if the translation hits increase.
Regards,
Adam

(if my post helped solve your problem, mark it as accepted solution)
Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Re: Dest NAT/PAT Issue

Hi John,

 

Thanks for the suggestion.  The second rule, NATing to 2.2.2.2, has been present and working for a number of weeks, so I'm certain of the policy/NAT relationship being correct there.  The problem only began to occur when I created the newer rule (nat-1) and inserted it above nat-2.  Traffic that was being correctly translated and forwarded by nat-2 (ie. anything destined to 10.10.10.10 on any port OTHER than 9028) then started to be picked up by nat-1, despite the specification that nat-1 should only relate to traffic with a dst port of 9028.

 

As you, quite correctly, pointed out, the traffic is then denied by policy.  If this same traffic was processed by nat-2, as it should be, it would get through policy successfully as it always has done in the past.

 

My issue is more about why nat-1 is picking up the traffic NOT destined to port 9028.

 

Cheers,

Ben

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Re: Dest NAT/PAT Issue

Hi Adam,

 

Yes, I'm certain both NATs are not being done correctly.  "nat-1" was set up yesterday for a specific customer sending traffic to a specific port.  Prior to that, as I mentioned in my response to John (above), nat-2 worked perfectly well for all customers.

 

The situation appears to be that, since the introduction of nat-1, the SRX is now matching all traffic destined to 10.10.10.10 to nat-1 regardless of whether the dest port is 9028 or not.  If the dest port is 9028 then nat-1 works correctly, both NAT and policy.

 

Junos version is 11.4R2.14

 

Cheers,

Ben.

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Super Contributor
johnrbaker
Posts: 210
Registered: ‎02-17-2011
0

Re: Dest NAT/PAT Issue

I still suggest adding the protocol to the DST NAT Rule

 

E.G.

        destination {
            pool DSTNAT-SSL-VPN-LAN-HTTPS {
                address 192.168.252.253/32 port 443;
            }
            pool DSTNAT-SSL-VPN-LAN-ESP {
                address 192.168.252.253/32 port 4500;
            }
            rule-set PAT_FROM_UNTRUST_TO_TRUST {
                from zone untrust;
                rule PAT_SSL_VPN {
                    match {
                        destination-address xxx.xxx.xxx.xx7/32;
                        destination-port 4500;
                        protocol udp;
                    }
                    then {
                        destination-nat pool DSTNAT-SSL-VPN-LAN-ESP;
                    }
                }
                rule PAT_HTTPS_SSL_VPN {
                    match {
                        destination-address xxx.xxx.xxx.xx07/32;
                        destination-port 443;
                        protocol tcp;
                    }
                    then {
                        destination-nat pool DSTNAT-SSL-VPN-LAN-HTTPS;
                    }
                }
            }
        }

 

 

And then the policy

 

policies {
        from-zone untrust to-zone DMZ_ZONE {
            policy WAN_SSL_ALLOW {
                match {
                    source-address any;
                    destination-address SSL-VPN-WAN;
                    application [ junos-https junos-ike-nat ];
                }
                then {
                    permit;
                }
            }
        }
}

 

My DST Nat rule would not work until I entered the IP/Port/Protocol when I wanted UDP4500 setup.

 

You can show the NAT sessions via the CLI

 

 show security flow session nat

Recognized Expert
rasmus
Posts: 379
Registered: ‎02-28-2010
0

Re: Dest NAT/PAT Issue

Hi Ben,

 

you have a strange issue ..

 

can you post related security policy config and show security flow session output to troubleshoot ...

 

i dont see and tcp/udp issue ..

 

kind regards

 

Hafiz Muhammad Farooq
JNCIE-SEC, JNCIP-SEC, JNCIS-SEC, JNCIS-FWV
JNCIS-SP, JNCIS-SA, JNCIA-JUNOS
IBM Qradar Deployment Professional

[Please mark it as Accepted Solution if it works, Kudos if you like]

Contributor
ben_johnson
Posts: 17
Registered: ‎05-12-2011
0

Re: Dest NAT/PAT Issue

Hi rasmus,

 

Security policy that related to nat-1:

 

policy gbl-extvpn-2-intnet {
    match {
        source-address [ cust-net-1 cust-net-2 ];
        destination-address [ xlate-10.10.10.10 int-2.2.2.2 ];
        application [ app-tcp-9028 app-rdp-3389 ];
    }
    then {
        permit;
        log {
            session-init;
        }
        count;
    }
}

 

There is a reason that both the NAT address and the internal address are included in the policy but, for the purpose of illustration of this issue, I don't think the explanation is worth your time :smileyhappy:  As you can see from the policy, only a specific set of customer networks are able to use this policy and therefore nat-1.

 

nat-2 is used by many different customers and thus the internal IPs are referenced in many policies.  Suffice to say, until the introduction of nat-1, nat-2 worked perfectly well.

 

To reiterate, the problem appeared to be that nat-1 was capturing ALL traffic destined to 10.10.10.10, not just 10.10.10.10:9028.

 

I can't supply the output of show security flow session as I had to deactivate the NAT fairly quickly once it was discovered that production traffic was being negatively affected.  The traffic that was affected was traffic that was working perfectly (using nat-2) immediately prior to the introduction of nat-1.

 

Cheers,

Ben.

Ben Johnson
JNCIS-SEC, JNCIS-ENT, JNCIA-JUNOS

"Breathe. Deeply."
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.