SRX

Hi all.

I've prepared HA cluster for business continuity deployment, but the 'invoke' process required reth1 interfaces(s) to be plugged in. 

I was hoping to use the 'trust' zone reth1 IP to manage the cluster remotely, but if the physicals will not be plugged into anything, so the VPN will not come UP (?)

We have routing across the VPN to a single subnet only, so I was thinking of pinching one IP address from 192.168/23 block and assigning to a loopback interface so; A the VPN will come UP, and B, I'll be able to manage remotely 'through the VPN rather than having to enable mgmt to the public IP.

.

Hello Ajaz ,

If you keep the LAN and the FXP on same subnet , make sure it does not create any asymetric routing in the LAN network .

Good point though I believe that whilst possible, its not recommended to have fxp's share same network as trust, or for that matter any other lan/zone

probably another reason for deploying separate switch, create two vlans, one for Mgmt and second for Trust. and job done. 

Hello ,

Or we can have the FXP in inet.0 and put all other interfaces (reth) in Virtual router so that the routing will not be interfeared .

Agred this is a good idea, though it doesn't facilitate in bringing UP the lan-2-lan VPN.

great piece of advice nonetheless - thanks man !

Hello ,

For VPN , the Loopback should work .

For VPN , the Loopback should work ...

Indeed the loopback does work. don't you just love these SRXs !

Its not possible to do what i just did on Cisco. It would complain 'address overlaps with another interface'.

this is the power of SRX. absolutely phenominal !!

Hello anawaz , 

Thanks for the update . Indeed , SRx is powerful in many ways and at many time . 

May I ask, would the loopback mask need to be a /32, or is it OK to have this interface in the same network?

Also is it necessary to have the loopback address to be in the same subnet as the LAN?

One would assume having the loopback in another reserved loopback address range, and adding it to the proxy-id of the VPN both sides and relevant rule-sets, we can avoid have interfaces with an address that overlaps with the other. I think we would achieve the same, imho maybe seen as little more clean.

Hello Bilal ,

The loopback IP should be in /32 . But you can or cannot have Loopback  IP from LAN segment , it does not matter . What matters is that the routing part .

Thanks Sam, thought so, I guess one thing to take note of is not to allocate or to reserve the ip address used for the loopback, and not be accidentally be assigned to a host on the LAN segment. I wonder what would happen to the packets coming from a host with the same IP as the loopback, first assumption would be that the SRX would drop it right?

Hello ,

Yes you are right , if the  Loopback and the external interfaces are in diff Zone , it will drop saying Ip spoofing /re-route failed .

If they both are in same zone also the return packet will never make it to that host since packets teminate on loopback IP .

So either way its failure .

May I ask, would the loopback mask need to be a /32, or is it OK to have this interface in the same network?

I have it in exactly the same network. Whilst I haven't tested applying a different mask I'd hazard a guess the SRX would accept it.

Also is it necessary to have the loopback address to be in the same subnet as the LAN?

In the given scenario, lan-2-lan routing is provisioned for single subnet only i.e. 192.168/23. There is no console connectivity, nor FXPs for that matter. All connections seen south of cluster are physically disconnected. Disaster recovery is invoked by plugging in Ge-0/0/4 & Ge-9/0/4. with LAN essentially 'down' at one end of a site-to-site VPN, I believe tunnel not reach a state of 'established', thus I would be unable to manage it through a tunnelled session.

btw i think this loopback solution is really really cool.