[j-nsp] SRX advice

Fri Feb 4 23:56:39 EST 2011

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" <dhanks at 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 at 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:RGoldberg at compudyne.net] 
> Sent: Friday, February 04, 2011 6:34 PM
> To: Doug Hanks; Julien Goodwin
> Cc: juniper-nsp at 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:dhanks at juniper.net]
>> Sent: Friday, February 04, 2011 8:03 PM
>> To: Ryan Goldberg; Julien Goodwin
>> Cc: juniper-nsp at 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-bounces at puck.nether.net [mailto:juniper-nsp-
>> bounces at puck.nether.net] On Behalf Of Ryan Goldberg
>> Sent: Friday, February 04, 2011 4:29 PM
>> To: Julien Goodwin
>> Cc: juniper-nsp at 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"
>> <jgoodwin at 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 