SRX Services Gateway
SRX Services Gateway

Security Policies best practice for HUB and SPOKE IPSEC VPN

05.28.12   |  
‎05-28-2012 05:49 AM

Hi Experts

 

I have SRX3600 cluster on HUB site and SRX240 at spokes sites. All the VPN are route based VPN. There are two communications for these VPN.

 

1- SPOKE to SPOKE through HUB

2- SPOKE to HUB

3- HUB to SPOKE

 

Now if we take SPOKE-1 to SPOKE-2 communication then there are three points where we have to make security policies.

1- On SPOKE-1 from zone Trust to VPN

2- On HUB from VPN to VPN

3- On SPOKE-2 frm zone VPN to Trust

 

My question is that, where I need to do hardening. I mean what is the best practice to make such policies. My idea is that on spokes. I will make Trust to VPN, all allow and similaryly VPN to Trust, all allow. Then on HUB, I will make VPN to VPN more specific policies to control applications etc.

 

Some body can tell me more good option?

 

Thanks

2 REPLIES
Highlighted
SRX Services Gateway

Re: Security Policies best practice for HUB and SPOKE IPSEC VPN

05.28.12   |  
‎05-28-2012 08:27 AM

I don't know if there is necessarily a right/best way to do this.

 

But I prefer to place the most restrictive policy on the firewall closest to the protected resource.  So if the device that needs restrictions is in spoke 2 the most restrictive policy is no the spoke 2 firewall.

 

The reason I do it this way, is if there are connectivity problems there are frequently many sources of the traffic but only one destination.  So if the most restrictive rules are always next to the destination I know where to go for troubleshooting.

Steve Puluka BSEET
Juniper Ambassador
Senior IP Engineer - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
JNCIA-Junos JNCIS-SEC JNCIP-SEC JNCSP-SEC
JNCIS-FWV
JNCDA JNCDS-DC JNCDS-SEC
JNCIS-SP
ACE PanOS 6 ACE PanOS 7
http://puluka.com/home
SRX Services Gateway

Re: Security Policies best practice for HUB and SPOKE IPSEC VPN

05.29.12   |  
‎05-29-2012 06:21 AM

I'm with spuluka on that one.

 

Also, if you have your restrictive policy on the spokes, you can potentially reduce the un-needed bandwidth usage for it to just be dropped at the hub anyways