SRX

Hi all,

i sucesfully established an IPsec-Tunnel between the PfSense and the SRX-100.

The tunnel is UP (IKE and IPSEC) - however i have a strange problem:

The subnet behind the PfSense can reach the subnet behind the SRX without a problem.

However the subnet behind the SRX cannot reach the subnet behind the PfSense.

Has anyone encountered this before or can anyone give me a "hint" where to look at?

This is driving me insane...

Regards

Chris

Follow the troubleshooting steps outlined inKB10093.  Post and questions about the messages or results.

How to troubleshoot a VPN that is up, but is not passing traffic

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

Hi Steve,

via show security ipsec security-associations detail I get:

Last Tunnel Down Reason: More than two SA pairs

Behind the PfSense I have 3 Phase 2 entry's - if I only use one, it works fine.

I could create more tunnels - however then i end up with 3 tunnels to the same location, correct?

I have to use policy based VPN, since pfsense does not support route-based VPN's.

Is there a solution for this?

Regards

Chris

Hi Chris,

Do you have 3 phase 2 entries because you have 3 subnets? 

@ Regalis: 

Yes.

Behind the SRX there is only one Subnet.

Behind the PfSense there are 3 Subnets - therefore 3 Phase2-entries.

With multiple subnets on a policy VPN you will create the addtiion proxy-id pair in the Configuring Security Policy section

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/ipsec-policy-based-vpn-configuring.html

This sample is one pair.  Duplicate for the next two changing only the source and destination address objects for the other subnets to match.

set security policies from-zone trust to-zone untrust policy vpn-tr-untr match source-address sunnyvale
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match destination-address chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match application any
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel pair-policy vpn-untr-tr
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match source-address chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match destination-address sunnyvale
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match application any
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel pair-policy vpn-tr-untr

The phase 2 and phase 1 sections do have only one entry as shown in the example

So do you mean:

set security policies from-zone trust to-zone untrust policy vpn-tr-untr match source-address sunnyvale
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match destination-address chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match destination-address boston
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match destination-address nyc
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match application any
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel pair-policy vpn-untr-tr


set security policies from-zone untrust to-zone trust policy vpn-untr-tr match source-address chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match source-address boston
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match source-address nyc
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match destination-address sunnyvale
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match application any
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel pair-policy vpn-tr-untr

or

set security policies from-zone trust to-zone untrust policy vpn-tr-untr match source-address sunnyvale
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match destination-address chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr match application any
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr then permit tunnel pair-policy vpn-untr-tr
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-2 match source-address sunnyvale
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-2 match destination-address boston
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-2 match application any
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-2 then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-2 then permit tunnel pair-policy vpn-untr-tr
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-3 match source-address sunnyvale
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-3 match destination-address nyc
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-3 match application any
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-3 then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone trust to-zone untrust policy vpn-tr-untr-3 then permit tunnel pair-policy vpn-untr-tr


set security policies from-zone untrust to-zone trust policy vpn-untr-tr match source-address chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match destination-address sunnyvale
set security policies from-zone untrust to-zone trust policy vpn-untr-tr match application any
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr then permit tunnel pair-policy vpn-tr-untr
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-2 match source-address boston
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-2 match destination-address sunnyvale
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-2 match application any
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-2 then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-2 then permit tunnel pair-policy vpn-tr-untr
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-3 match source-address nyc
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-3 match destination-address sunnyvale
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-3 match application any
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-3 then permit tunnel ipsec-vpn ike-vpn-chicago
set security policies from-zone untrust to-zone trust policy vpn-untr-tr-3 then permit tunnel pair-policy vpn-tr-untr

Sorry for the confustion, yes the second example.  You create three complete policies one for each set of proxy-id.  local address on the SRX the same for each and one policy for each remote subnet with the tunnel action and paired policies.  

As in the example linked you have only one phase 2 policy which basically only handles the cryto settings.

The policy based vpn proxy-id are created with each policy pair in this security policy list.  And you can keep creating as many as you need for the subnets involved.

I tried to create separate Policy's, however nothing changed...

First error was:

Last Tunnel Down Reason: SA not initiated

After 2 Minutes, the Error is again:

Last Tunnel Down Reason: More than two SA pairs

After 10 Minutes, 2 Subnets are working, the 3rd is not - it is not even showing in the "show security ipsec security-associations detail" anymore... Very Strange...

This is driving me nuts...

If anyone is experiencing the same:

delete security ipsec policy ipsec-policy-external perfect-forward-secrecy

I had perfect-forward-secrecy keys group5 active - however pfsense and juniper seem to "dislike" pfs - after disabling pfs everything started immideatly to work. We recreated this a couple of times and could reproduce this.

Thank you all very very much for all your help.