I'm not quite understanding your NAT requirement. On the other hand I can tell you from personal experience that SRX has some of the best NAT support I've used.
Here are some common deployment methods for NAT and how to use them on the SRX. http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/Junos_NAT_Examples.pdf You can do: 1) source NAT 2) destination NAT 3) static NAT 4) interface source NAT 5) pool-based NAT 6) source NAT with address shifting 7) pool-based source NAT with PAT I'm sure I missed a few, but you get the idea. Doug -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ryan Goldberg Sent: Friday, February 04, 2011 4:29 PM To: Julien Goodwin Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX advice Regarding the odd-setup.... Can SRX boxes do (for lack of a better term) "nat loopback"? In other words, say you have private net x src natted to public address y. And you have private network a src natted to public address b. Additionally you have some dst nat going the other direction for publicly accessible stuff. Now two scenarios: box in net x wants to access some resource available at address On Feb 3, 2011, at 11:50 PM, "Julien Goodwin" <jgood...@studio442.com.au> wrote: > On 04/02/11 16:12, Ryan Goldberg wrote: >> watchguard a) is the outbound nat box for about 70 small offices (we are a >> small ISP too, these are fiber-connected customers). it also handles some >> amount of inbound nat for those customer's various servers, which may be in >> the customers office, or a virtual host in our racks. and maybe a half >> dozen ssl-vpn road-warrior types. There's also a dozen or so lan-to-lan >> ipsec tunnels on it. sustained 2-20 inbound. light outbound. > > That's an odd setup. > >> watchguard b) is for internet facing windows boxes. lotsa inbound nat. >> sustained 2-20Mbit outbound >> watchguard c) is for our office, 55ish users. some inbound nat too. >> 0-50Mbit inbound, widely varying >> watchguard d) is for one particular hosting customer where stability is >> paramount. The other firewalls get touched a lot (and as of late, have been >> puking when they feel like it). 2-15Mbit of sustained web traffic, with the >> odd spike or lull. > > These three are fairly trivial. > >> a 2821) terminates a bunch of lan-to-lan ipsec tunnels (VTI style) to 1841s >> all over the place. box is completely VRFed, no global table, all the >> tunnels land in the INTERNET vrf and pop out in customer vlans, each their >> own vrf. 10-30Mbit >> >> So - goal is to collapse all this onto a single pair of boxes running in an >> HA config. Watchguard a, b, and c are problematic, and are becoming more >> problematic. watchguard d is pretty quiet, but we are contractually >> obligated to remove all SPOF from that clients setup. the 2821 is very >> quiet, no troubles. > >> My main question revolves around number of virtual routers. We can't afford >> a big enough box to stuff everything (as in, every customer network) in its >> own vrf/routing-instance. I will admit that I've become hooked on using >> vrfs in cisco land on ISRs (a lot of double-ISP configs, random dirty >> hacks). But for our future firewall setup, I don't know what a bunch of >> routing-instances really buys us, if anything (aside from the psychological >> aspect). All we really need is for all the private networks behind this >> thing to get natted to their corresponding public ip(s), and if something >> behind the firewall needs to talk to something else behind the firewall, it >> should go out and back in (getting source nattted, then dest natted). If >> the J-boxes can do that without separate routing-instances, then we're good. > > You only need instances (on SRX) for two things: > * Overlapping IP's need forwarding instances > * Multiple protocol instances (eg, seperate OSPF on either side) take > non-forwarding instances > >> My other question involves HA stability. I've seen instances with other kit >> where introducing "HA" actually reduced availability. SRX boxes like >> running in HA, or are they fussy? > > I don't run SRX's in HA, the only issues I've had in production are > firmware related (note that you can't do an online firmware upgrade of a > HA cluster, there's still a hit). > > I would suggest an SRX650 over the SRX240, would be far more confident > in that handling your traffic load (on the services side, forwarding > should be trivial for even an SRX100). > > -- > Julien Goodwin > Studio442 > "Blue Sky Solutioneering" > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
