SRX

Hi, 

We have the following setup:

** Policy Based VPN between a SRX 1400 and a Palo-Alto.

Extra info on why we are using Policy-Based VPN:

1- We need one phase2 per local/remote network pair (proxy-id).

2- Right now in the SRX side it is one network, but in the future there will be more.

3- Our current JunOS version is just behind the relase that included traffic selectors.

SRX side: 

10.10.10.0/24 (lan_1)

PaloAlto side:

192.168.8.0/24 (vpn_net_1)

192.168.9.0/24 (vpn_net_2)

192.168.10.0/24 (vpn_net_3)

We have the following rules:

[edit security policies from-zone untrust to-zone management-lan]
     policy vpnpolicy-untrust-management-lan-1 {
         match {
             source-address vpn_net_1;
             destination-address lan_1;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-management-lan-untrust-1;
                 }
             }
         }
     }
     policy vpnpolicy-untrust-management-lan-2 {
         match {
             source-address vpn_net_2;
             destination-address lan_1;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-management-lan-untrust-2;
                 }
             }
         }
     }
     policy vpnpolicy-untrust-management-lan-3 {
         match {
             source-address vpn_net_3;
             destination-address lan_1;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-management-lan-untrust-3;
                 }
             }
         }
     }

[edit security policies from-zone management-lan to-zone untrust]

     policy vpnpolicy-management-lan-untrust-1 {
         match {
             source-address lan_1;
             destination-address vpn_net_1;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-untrust-management-lan-1;
                 }
             }
         }
     }
     policy vpnpolicy-management-lan-untrust-2 {
         match {
             source-address lan_1;
             destination-address vpn_net_2;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-untrust-management-lan-2;
                 }
             }
         }
     }
     policy vpnpolicy-management-lan-untrust-3 {
         match {
             source-address lan_1;
             destination-address vpn_net_3;
             application any;
         }
         then {
             permit {
                 tunnel {
                     ipsec-vpn ipsec-vpn-1;
                     pair-policy vpnpolicy-untrust-management-lan-3;
                 }
             }
         }
     }

{primary:node0}[edit]

The VPN is established correctly, and traffic works in both directions.

Now, how can you filter specific traffic on that VPN? As we have "application any", all traffic is allowed.

For outgoinf traffic (SRX->PaloAlto) I think it would be enough to just add a deny rule before the tunnel rule. But, how can I filter inbound traffic (PaloAlto->SRX) ? I'm not sure the same approach would work.

If for example, we want remote server 192.168.8.200 to only be able to access 10.10.10.0/24 on port 80/TCP, where should we do it? Or do we have to actually modify the tunnel rule? If so, wouldn't that then create a different phase2 per tunnel rule created?

Thanks for the input!

Best regards.

In order to do more specific filtering than just the matched subnets you need to have a route based vpn.  The policy based vpn policy is used to create the proxy-id pairs and these only work when they have that "any" for application.

And as you already pointed out to have multiple proxy id for a route based vpn you need the traffic selectors.

Upgrading to a version of Junos with traffic selectors is your best bet.

If you really cannot upgrade, you would need to apply the security policies after the tunnel.  So you could move the tunnel termination to a virtual router routing instance, then pass that traffic into another routing instance where you apply security policies to the traffic in both directions as desired.  But this is considerably more complex a setup.

Hi Steve, to be honest, I think we can probably upgrade. We have a cluster of 2 nodes. Technically we should be able to upgrade without any downtime right?

Any suggestions on what is the safest upgrade procedure? Can you maybe point me to any doc?

Thanks again for your help!

Best regards.

Yes, ISSU is supported on the Data Center series devices.

https://kb.juniper.net/InfoCenter/index?page=content&id=KB20959

Do review the release notes for the new version carefully for the upgrade notations.  And if you are going up multiple major releases this is best done form an EEOL release (the last release of the year of the train).

Hi Steve, 

I'm preparing this, one last thing:

There is a NOTE on the doc you mentioned:

TSB16905 - On SRX High-End platforms, when NAT is configured, ISSU upgrade from 12.1X46-D40 to any higher releases results in loss of security policies

In our case, our cluster is on 12.1X44-D30.4. According to:

https://kb.juniper.net/InfoCenter/index?page=content&id=TSB16905&actp=search

JTAC recommends Junos 12.3X48-D35 for SRX 1400.

We should be safe to use ISSU right? Because our version is < 12.1X46-D40.

So going from 12.1X44-D30.4 to 12.3X48-D35 should not be affected by TSB16905 correct?

Thanks again.

Yes, that is how I read this TBS as well, your version is not affected per the notes on the bottom.

 Other releases in 12.1X46 besides D40 do not have this issue and can perform ISSU to higher releases correctly.

Again thanks for your help!