Hi
you search for persistent nat: http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-swconfig-security/understand-persistent-nat-section.html But configuring splitted src-NAT isn't such a burden. Just go to your src-nat rulset and insert a second rule, that covers the one half of your internal network via the match statement. It's quite simple. If you need explicit help, post your config. Klaus — Sent from Mailbox for iPhone On Fri, Jul 19, 2013 at 7:08 AM, William McLendon <[email protected]> wrote: > hi all, > We have an issue where we have enough internal users and sessions using the > general outbound NAT that we are hitting the session limit for the single > public IP due to running out of ports. (really its due to how Source NAT is > carved up on an HA pair…see http://kb.juniper.net/KB14958 ) > However I think if just add additional IPs to NAT the users to, it may end up > breaking some applications as they establish a new outbound session from > clicking a URL or something, but that session gets NAT'd to the other IP that > the far side is not expecting to see it from. > I think ScreenOS had something called Sticky DIP that could help mitigate > this where for some NAT Timer, any session initiated by an IP address would > always be NAT'd to the same public IP -- does SRX have a similar feature? If > not, I think my only other option then would be to carve up the internal > networks, ie 10.10.10/24 NATs to public IP A, and 11.11.11.0/24 NATs to > public IP B, etc. which is probably ok, but can get a little cumbersome. > Or if anyone knows another way please share :) > Thanks, > Will > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
