SRX

Hello,

I have a site-to-site VPN set up between a SRX320 and a SRX100H2. The SRX320 has a static public IP address. The SRX100H2 is behind a dynamic IP address so I have set up a dynamic VPN tunnel using the dynamic hostname <hostname> directive. The security associations come up fine with the SRX100H2 as the initiator.

I am seeing some odd traffic flow into the SRX100H2. I have security policies to match the VPN traffic in both directions on the SRX100H2 but traffic is slipping past the security policies and hitting my default deny policy.

The SRX100H2 seems to identify the correct policy (VPN - LAN) but then does a second policy lookup and identifies the  (global - global) policy instead. I have this policy as a deny all policy but in the traceoptions capture below, I changed that to a permit all to get traffic flowing.

This is the security flow traceoption capture of what's happening:

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:Policy lkup: vsys 0 zone(8:VPN) -> zone(7:LAN) scope:0

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:             10.21.6.205/2048 -> 10.1.11.16/31074 proto 1

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:Policy lkup: vsys 0 zone(5:global) -> zone(5:global) scope:0

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:             10.21.6.205/2048 -> 10.1.11.16/31074 proto 1

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:  app 0, timeout 60s, curr ageout 60s

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:  permitted by policy deny-and-log(6)

Mar 17 20:14:12 20:14:10.949529:CID-0:RT:  packet passed, Permitted by policy.

The external-interface on the SRX100H2 is set as the vlan interface attached to the LAN security zone. The VPN has the interface st0.0 attached.

Any advice on what is going on here? I can add more details as necessary.

Thanks!

Hi kleinhhl,

I hope you're doing well.

Thank you for providing the flow traces, that helps eliminate a lot of causes here.

So the policy lookup, is accurately happening between VPN -> LAN, but the flow doesn't seem to think there's an existing policy that matches the IP addresses in question for the traffic.

Can you check if the source/destination/application contexts configured on your desired security policy in the VPN->LAN transit are correct? Especially check if there are NAT'd IPs specified here instead of the IP addresses the flow is reflecting just before the policy lookup?

The 2nd policy lookup occurs because the flow sees no match for VPN->LAN and goes onto to check the global rules - which is the correct behavior if there isn't a match.

Chances are, your defined source/destination/application configuration on the security policy under VPN->LAN is different.

Could you please check or alternately paste this security policy configuration, along with the address set definitions here for us?

Cheers

Pooja 

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!

Hello Pooja,

Thank you for your reply. I believe the security policies are correct with source/destination/application settings. Here they are for the SRX100H2 device:

security {
	policies {
		from-zone LAN to-zone VPN {
			policy Allowed {
				match {
					source-address 10.1.0.0/16;
					destination-address 10.1.11.0/24;
					application any;
				}
				then {
					permit;
				}
			}
		}
		from-zone VPN to-zone LAN {
			policy Allowed {
				match {
					source-address 10.1.0.0/16;
					destination-address 10.1.11.0/24;
					application any;
				}
				then {
					permit;
				}
			}
		}
		global {
			policy deny-and-log {
				match {
					source-address any;
					destination-address any;
					application any;
				}
				then {
					permit;
				}
			}
		}
		default-policy {
			deny-all;
		}

	}
	address-book {
		LAN {
			address 10.1.11.0/24 10.1.11.0/24;
			attach {
				zone LAN;
			}
		}
		VPN {
			address 10.1.0.0/16 10.1.0.0/16;
			attach {
				zone VPN;
			}
		}
	}
}

There is no NAT configuration in the SRX100H2 device which is the device that is in question.

There is NAT configured on the SRX320 device but nothing that should be affecting traffic sent out of the IPSec tunnel.

Regards,

Hugo

Hello Hugo,

The attempted traffic context: (8:VPN) -> zone(7:LAN)
10.21.6.205/2048 -> 10.1.11.16/31074 proto 1

Existing policy context: (8:VPN) -> zone(7:LAN)
from-zone VPN to-zone LAN {
policy Allowed {
match {
source-address 10.1.0.0/16;                 <<<<< doesn't cover traffic context source 10.21.6.205/2048
destination-address 10.1.11.0/24;       <<<covers traffic context source
application any;
}
then {
permit;
}

Please edit the source-address in the policy to include 10.21.0.0/16 OR, make it a /8  to accomodate the traffic?

Cheers

Pooja 

Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too!!!

Pooja,

I can't believe I overlooked that! I literally stared at these policies over the course of two days and didn't see that I was missing that whole subnet in the policy.

Thank you very much for your assistance on what was a dumb mistake!

You are very welcome Hugo!

Have a good one!

Cheers

Pooja