[j-nsp] SRX advice

[Ryan Goldberg]

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