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?