Yep, familiar with the concept and practice. Our level of control over the networks/boxes in question varies, so it's nice to know what tools I've got in the toolbox..
Ryan On Feb 4, 2011, at 11:01 PM, "Doug Hanks" <[email protected]> wrote: > There's a feature in DNS called "views." It's a bit similar to source > routing. Depending on where the DNS request comes from, it's able to return > a different result. > > Doug > > -----Original Message----- > From: Ryan Goldberg [mailto:[email protected]] > Sent: Friday, February 04, 2011 8:57 PM > To: Doug Hanks > Cc: Julien Goodwin; [email protected] > Subject: Re: [j-nsp] SRX advice > > 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" <[email protected]> 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: [email protected] >> 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:[email protected]] >> Sent: Friday, February 04, 2011 6:34 PM >> To: Doug Hanks; Julien Goodwin >> Cc: [email protected] >> 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:[email protected]] >>> Sent: Friday, February 04, 2011 8:03 PM >>> To: Ryan Goldberg; Julien Goodwin >>> Cc: [email protected] >>> 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: [email protected] [mailto:juniper-nsp- >>> [email protected]] On Behalf Of Ryan Goldberg >>> Sent: Friday, February 04, 2011 4:29 PM >>> To: Julien Goodwin >>> Cc: [email protected] >>> 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" >>> <[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 >> >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
