SRX

If this has been covered in another thread I appologize.  I couldn't concoct a search on the subject that didn't bring up every NAT conversation since time began.

What I currently have:

1.2.3.4/32 <- Public IP, exists as a proxy-arp'd IP on the SRX

10.0.0.4/32 <- Private IP of my internal server

security nat static {

   rule server-BIMAP-1 {

      match {

         destination-address 1.2.3.4/32;

      }

      then {

         static-nat {

            prefix {

                10.0.0.4/32;

            }

         }

      }

   }

}

security nat proxy-arp {

   interface reth1.10 {

      address {

         1.2.3.4/32;

      }

   }

}

Nice and straight forward.  The box is doing outbound SMTP so knowing exactly what IP it NATs out via is important.  Now I need to add a new service to that server, and because I'm using SSL and a different common name, I need to put it on a separate public IP with different reverse dns.  This wasn't something I was anticipating having to do when I initially setup this system.  My initial instinct is to setup destination-nat for the ports involved on a new proxy-arp'd public IP with a pool defined as the server's private IP.  Then I read this:

http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-es-swconfig-security/understanding-static-nat-on-srx-series-services-gateways.html

What I'm anticipating happening is incoming connections to 1.2.3.4/32, the existing public facing IP with static NAT will continue to NAT to the internal IP with no port translation as before.  New outbound connections from the server will NAT out via 1.2.3.4/32 again with no port translation.

Incoming connections to 1.2.3.99/32, the newly defined and proxy-arp'd IP should hit the destination-nat rule and translate to the server's internal IP.  Where I get fuzzy is how replies from the server would be handled.  Will the static NAT mapping clobber the destination mapping, causing replies to come from the old public IP?  Or will JUNOS see the overlap during configuration and not allow me to commit without fixing?

Hi Kurlon,

Static nat has more priority than source nat. So when configuring an extra source nat rule for your new public IP address it will not work when the servers IP is already configured as (source or destination) in a static nat rule. So connections intiated from the server will be translated to the address defined in the static nat rule.

Z.

Lab testing yesterday confirmed that.  Any new sessions initiated by the server are NATed out via the static mapping, as anticipated.  The good news is, at least on 10.4R9.2 sessions initiated by the outside to the destination NAT recieve their replies from the destination NAT target, NOT the static NAT IP, which is exactly what I wanted.

You could transition your config to using only destination NATs for your incoming services, and a source NAT rule to map your default outgoing connections to whichever default public IP you want to use.

That way, you can have more flexibility in the future if necessary, and a more deterministic behavior for the traffic.

You are correct in that traffic that matches a flow that came in via a certain destination NAT IP will be sent back out with the same IP.

You could do:

Destination NAT:

1.2.3.4 (25) -> 10.0.0.4 (25)

1.2.3.5 (443) -> 10.0.0.4 (443)

...

etc.

And your source NAT:

10.0.0.4 -> 1.2.3.4

Which will NAT all traffic sourced from the server to the 1.2.3.4 address.

It's the same effect as what you're doing with the static + destination NAT combos, but to me it's more "cleanly defined."

I agree, that configuration style is much easier to read and comprehend so I'll be migrating to it shortly.  Thank you for the tip!