SRX

Fairly new to the SRX firewalls, having previously used an SSG I am more familiar with it.

I just recently deployed a pair of SRX220s clustered.  I had the VPN working perfectly sound, however when I was going through and cleaning up some of the cruft from experimenting/learning, I seem to have inadvertently broken connectivity to one of the subnets over the VPN.  VPN is an ipsec VPN using VPN Tracker 6 on OS X.

My configuration is such: I have two internal zones on separate subnets.  One is the DMZ and the other is Trusted.  DMZ is on 172.16.1.0/24 and trust is on 172.16.16.0/22.  I set it up on a /22 since they're physical servers with remote management cards, so the system's IP can be 172.16.16.10 and that system's corresponding management IP is 172.16.17.10.

I can access the DMZ network, however I can't access the trust zone over the VPN.  I can ping the SRX on 172.16.1.1, but not on 172.16.16.1, however connectivity between the zones is fine.  As far as I can tell, there isn't anything different from the configuration for dmz over trust.  The VPN users are set up on 10.20.30.0/24 using .40-.50.

Below is most of the information I thought was pertinent.  I left out the ipsec VPN config, since that itself is working, its just zone access that is broken.

set interfaces reth0 unit 0 family inet address A.B.C.D/Z

set interfaces reth1 unit 0 family inet address 172.16.1.1/24

set interfaces reth2 unit 0 family inet address 172.16.16.1/22

set security nat proxy-arp interface reth2.0 address 10.20.30.0/24

set security nat proxy-arp interface reth2.0 address 172.16.1.0/24

set security nat proxy-arp interface reth1.0 address 10.20.30.0/24

set security nat proxy-arp interface reth1.0 address 172.16.16.0/22

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match source-address any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match destination-address any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy match application any

set security policies from-zone untrust to-zone trust policy dyn-vpn-policy then permit tunnel ipsec-vpn dyn-vpn

set security policies from-zone untrust to-zone dmz policy dyn-vpn-policy match source-address any

set security policies from-zone untrust to-zone dmz policy dyn-vpn-policy match destination-address any

set security policies from-zone untrust to-zone dmz policy dyn-vpn-policy match application any

set security policies from-zone untrust to-zone dmz policy dyn-vpn-policy then permit tunnel ipsec-vpn dyn-vpn

set security dynamic-vpn access-profile dyn-vpn-access-profile

set security dynamic-vpn clients all remote-protected-resources 172.16.16.0/22

set security dynamic-vpn clients all remote-protected-resources 10.20.30.0/24

set security dynamic-vpn clients all remote-protected-resources 172.16.1.0/24

set security dynamic-vpn clients all remote-exceptions 0.0.0.0/0

set security dynamic-vpn clients all ipsec-vpn dyn-vpn

set access profile dyn-vpn-access-profile address-assignment pool dyn-vpn-address-pool

set access address-assignment pool dyn-vpn-address-pool family inet network 10.20.30.0/24

set access address-assignment pool dyn-vpn-address-pool family inet range dvpn-range low 10.20.30.40

set access address-assignment pool dyn-vpn-address-pool family inet range dvpn-range high 10.20.30.50

In the ruleset for untrust->trust, there are two rules before the VPN rule to grant SSH and HTTP access to one of the internal hosts, but nothing fancy.

I've also been trying to look at my own system to see if it is an issue just with it, but not seeing any overlapping routes or anything:

Internet:

Destination        Gateway            Flags        Refs      Use   Netif Expire

default            10.10.10.1         UGSc          125        0     en1

default            link#7             UCSI            1        0     en0

10.10.10/24        link#4             UCS            31        0     en1

10.10.10.1         30:e4:db:fb:95:f6  UHLWIi        125       24     en1    473

A.B.C.D            10.10.10.1         UGHS            0        0     en1

127                localhost          UCS             0        0     lo0

localhost          localhost          UH             20    61832     lo0

169.254            link#4             UCS             1        0     en1

169.254.255.255    64:0:f1:aa:8:c2    UHLSW           0        0     en1

172.16.1/24        gif0               USc             1        2    gif0

172.16.16.0        10.20.30.42        UH              0        0    gif0

172.16.16/22       gif0               USc             0        2    gif0

172.16.141/24      link#8             UC              2        0  vmnet1

172.16.141.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        2  vmnet1

172.16.184/24      link#9             UC              2        0  vmnet8

172.16.184.255     ff:ff:ff:ff:ff:ff  UHLWbI          0        2  vmnet8

192.168.2          link#7             UCS             2        0     en0

192.168.2.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        2     en0

239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0        6     en0

In this case, vmnet1 and vmnet8 are used by VMware Fusion, and gif0 is the VPN connection.

Any help would be greatly appreciated.

Hi,

I had witnessed this kind of issue before ,during extensive troubleshooting i found that the packet was dropped because it was unable to find the tunnel. I suspect you might be facing the same issue as traffic through one policy is passing without any issues.

As a workaround I disconnected the Junos Pulse client and deactivated the policy ,which was not permitting the traffic.
After deactivating/reactivating the policy it started working.

In your case it will be

# deactivate security policies from-zone untrust to-zone trust policy dyn-vpn-policy
#commit
#activate security policies from-zone untrust to-zone trust policy dyn-vpn-policy
#commit

If it does not help try deactivating all the security polciy called in the vpn and activate them again

Hope this helps.

Regards,

Visitor

-------------------------------------------------------------------------------------------------------

If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated!

Wow, I think that was it.

I was working on rebuilding the config and thought I had found the problem being with the remote-protected-resources needing to be two /24s instead of the /22, but then managed to break it again.  Then I just deactivated/activated the rule and it was sorted out again.

I'll keep an eye out for it happening again.  Did you notice any triggers in particular that seemed to cause it?

Currently I'm running 10.4R8.5.  Do you know if the issue still exists in the 11 releases?

Thanks again!

Ken

Hi Ken,

I am not sure if this issue is present in 11 code. It happens in those cases when the vpn sa are missing from
the forwarding table.

Hope this helps.

Regards,

Visitor

-------------------------------------------------------------------------------------------------------

If this post was helpful, please mark this post as an "Accepted Solution".Kudos are always appreciated!