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" <[email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
