Excellent info. Thanks. Scenario 1, while admittedly silly, can occur when the public ip is what's in dns and rather than playing dns tricks (because perhaps in a given situation dns tricks are not available or are onerous). Very happy to hear scenario 2 Just Works.
I'm nabbing an srx100 - not having gear is driving me bonkers.. Thanks again- Ryan On Feb 4, 2011, at 10:51 PM, "Doug Hanks" <dha...@juniper.net> wrote: > I forgot to mention that your option 2 "just works" with the SRX with all > variations. > > Doug > > -----Original Message----- > From: Doug Hanks > Sent: Friday, February 04, 2011 8:42 PM > To: 'Ryan Goldberg'; Julien Goodwin > Cc: juniper-nsp@puck.nether.net > Subject: RE: [j-nsp] SRX advice > > That's a silly setup, because 10.1.1.33 should just talk directly to > 10.1.1.200 because they're on the same subnet. > > This also creates an interesting packet trace > > 1) SA: 10.1.1.33, DA: 123.123.123.123 > 2) SRX NATs 123.123.123.132 to 10.1.1.200 > 3) SA: 10.1.1.33, DA: 10.1.1.200 > 4) 10.1.1.200 receives the packet, since the SA is 10.1.1.33 and is on the > same subnet, it just looks at its local arp table and replies back via L2 and > bypasses the SRX for the return traffic. > > I just tried it for kicks, and it works just fine. The only problem is just > like I said the return traffic bypasses the SRX, so it's really not usable. > > Doug > > -----Original Message----- > From: Ryan Goldberg [mailto:rgoldb...@compudyne.net] > Sent: Friday, February 04, 2011 6:34 PM > To: Doug Hanks; Julien Goodwin > Cc: juniper-nsp@puck.nether.net > Subject: RE: [j-nsp] SRX advice > > 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
