[j-nsp] Making an SRX a Router and Security Device, for an enterprise

[Mike Williams]

Hi all,

Two of us here have almost lost our minds trying to do this. So we're hoping 
for a suitably strong fu-injection.

We have an MX80 and an SRX650, and shortly we'll have another MX and SRX, with 
further to come.
Elsewhere we've got a mixture of SRX, J-series (some Js all packet-mode, some 
flow-mode), and a couple Ms. Little of this is relevant though.

Obviously we got the little SRX to offer "security", as only certain traffic 
has to be filtered. We also got it so all our intersite traffic can be nicely 
encrypted (IPSec).


We're pretty happy with policy filters, routing instances, interface 
rib-groups, etc, on the MX to send the right traffic to the SRX.

But one area we're seriously stuck on is the IPSec, and the asymmetry in 
intersite routing that will occur. We're anycasting services.

The available documentation, and examples floating around the interwebs, are 
aimed more at service providers doing MPLS with customers, but we're an 
enterprise with little interest in MPLS and no customers routes we need to 
carry separately.

What I *think* we need is;

st0.X/Y/Z in the master.
gr-0/0/0.X/Y/Z over st0.X/Y/Z tied to a packet-mode VR. Intersite OSPF.
ge-2/0/8.X tied to the same packet-mode VR. OSPF to the MX.
ge-2/0/9.X/Y/Z tied to another VR, but flow-mode. Various interfaces and zones 
for the MX to forward to, policies and snat, an interface for the SRX to 
return SNAT'd traffic, and a couple static routes for it to return the 
traffic to the right unit on the MX.

How to go about making a "packet-mode VR" and a "flow-mode VR", and whether I 
am infact using the right terms, is where I'm mostly stuck.

One thing I don't believe we want, and is something fairly central to one 
document (3500192-en.pdf) is the lt- interface between "Services-VR" 
and "Packet-VR".
We think that's counter-productive for us, as having flow-mode services act 
as 'an-SRX on a stick' is right, so traffic to the MX from another site is 
only "seen" (i.e. not encapsulated) and statefully tracked if we explicitally 
choose it to be so.


Any hints on configuration, pointers to the One True Path (TM), or even 
confirmation we're already on the right path, all gladly welcomed.

Thanks

-- 
Mike Williams