Alex, Hans -- thanks for the pointers. I was aware of the UTM features, but I'm targeting SRX 3600s and 5600s.
The pointer to the [security screen ids-options] feature looks promising. Thanks for the tip -- I'll get this labbed out and see what happens! Cheers, jof On Tue, Oct 30, 2012 at 9:15 AM, Hans Kristian Eiken <[email protected]> wrote: > You could limit the number of sessions each ip address in your internal zone > can initiate. Here is an example on limiting an ip address in the zone trust > to only be able to create 10000 session. > > set security screen ids-option session-limit limit-session source-ip-based > 10000 > set security zones security-zone trust screen session-limit > > There should be no license needed for this feature.Here is how to configure > this: > > http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/denial-of-service-firewall-source-based-session-limit-setting-cli.html > > -- > Hans Kristian Eiken > > 2012/10/29 Jonathan Lassoff <[email protected]> >> >> So, I'm working on tuning an SRX deployment and am wondering if >> something is possible. >> >> This deployment is doing a lot of source NAT for a wide variety of >> endpoints as they egress out to the Internet. Pretty vanilla >> configuration. >> Specific sources are mapped via NAT rules to specific egress IPs (for >> IP filtering in some places, outside of the SRXes in question). >> >> And once in a while, some endpoint will have a legitimate need to open >> up *many* connections (and then NAT states) that pass over this SRX >> deployment. >> Unfortunately, the rate of connection establishment relative to the >> application timeouts means that these heavy users can use up all of >> the ephemeral ports, blocking new flows from becoming established. >> >> We've been playing a bit of whack-a-mole, assigning more IP space to >> the various source NAT pools, but would like to find a more proper >> solution. >> >> >> So, my question is this: is there any mechanism anyone knows of to >> rate-limit or block-past-a-threshold a "source NAT" source if it >> starts making too many connections? >> I don't see anything obvious in the SRX documentation, so I figured >> I'd ask here for pointers. >> >> Right now, it's way to easy for one bad actor (malicious or >> benevolent) to max out a source NAT pool. >> >> Cheers, >> jof >> _______________________________________________ >> 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
