I apologize - that was a premature "send" from my phone due to an errant thumb...
I'll rephrase a little.. Let's say I have (on the same box): Private net 10.1.1.0/24 src-natted on its way to the internet to public address 123.123.123.123 Also, 123.123.123.123:80 is dst-natted to 10.1.1.200:80 and Private net 10.2.2.0/24 src-natted to public address 200.200.200.200 Along with 200.200.200.200:25 dst-natted to 10.2.2.50:25 Now - the two scenarios: 1) machine 10.1.1.33 wants to talk to 123.123.123.123.:80 - does it work at all? and if so does it Just Work, or does it require some amount of special config? 2) machine 10.1.1.33 wants to talk to 200.200.200.200:25 - same questions... Variations on the above might be: the two private nets are a) different dot1q ints in the same zone b) in different zones c) in different routing-instances... In my ideal world, scenarios 1 and 2 would Just Work, and in all three variations.. As far as I can figure, this is called "NAT Loopback" (I do not like the term, but whatever...) Again, many thanks for the replies- Ryan > -----Original Message----- > From: Doug Hanks [mailto:dha...@juniper.net] > Sent: Friday, February 04, 2011 8:03 PM > To: Ryan Goldberg; Julien Goodwin > Cc: juniper-nsp@puck.nether.net > Subject: RE: [j-nsp] SRX advice > > 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_Ex > amples.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