SRX

I have a simple dynamic VPN which comes in on the untrust and allows users access to 2 internal zones,  DEG and Trust.

This has been working fine, I downgraded to 11.1 R4.4 from 11.2 as there is a bug in how the dynamic-vpn page is not redirected properly.

Since then traffic is working only to the DEG zone. I can get no response from the other.

What is "session closed unset" and why is it happening?

This is from my policy logs:

Sep 15 22:35:06 192.168.1.1 Sep 15 22:35:07 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed response received: 192.168.30.6/74->192.168.220.35/1 icmp 192.168.30.6/74->192.168.220.35/1 None None 1 trust_dyn_vpn untrust DEG 117141 1(60) 1(60) 4   N/A(N/A) vlan.1
   

Sep 15 22:35:06 192.168.1.1 Sep 15 22:35:07 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed unset: 192.168.30.6/75->192.168.1.222/1 icmp 192.168.30.6/75->192.168.1.222/1 None None 1 deg_dyn_vpn untrust trust 117168 0(0) 0(0) 1   N/A(N/A) vlan.1

      from-zone untrust to-zone trust {
            policy trust_dyn_vpn {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn wizard_dyn_vpn;
                        }
                    }
                    log {
                        session-init;
                        session-close;
                    }
                }
            }

        from-zone untrust to-zone DEG {
            policy deg_dyn_vpn {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn wizard_dyn_vpn;
                        }
                    }
                    log {
                        session-close;
                    }
                }
            }

I set up a trace with packet filter:

MatchTrafficIn from 192.168.30/0/24 to 192.168.1.0/24

MatchTrafficOut from 192.168.1.0/24 to 192.168.30.0/24

I can see traffic coming in but nothing going back out?

Sep 16 10:02:16 10:02:15.1075241:CID-0:RT:<192.168.30.7/33->192.168.1.100/1;1> matched filter MatchTrafficIn:
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT:  vlan.1:192.168.30.7->192.168.1.100, icmp, (8/0)
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT: find flow: table 0x493482b0, hash 47233(0xffff), sa 192.168.30.7, da 192.168.1.100, sp 33, dp 1, proto 1, tok 7
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT:flow_ipv4_rt_lkup success 192.168.30.7, iifl 0x0, oifl 0x46
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT:search gate for untrust:192.168.30.7/33->192.168.1.100/1,1
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT:search widecast gate for untrust:192.168.30.7/33->192.168.1.100/1,1
Sep 16 10:02:16 10:02:15.1075273:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.30.7, x_dst_ip 192.168.1.100, in ifp vlan.1, out ifp N/A sp 33, dp 1, ip_proto 1, tos 0
Sep 16 10:02:16 10:02:15.1075773:CID-0:RT:  dip id = 0/0, 192.168.30.7/33->192.168.30.7/33
Sep 16 10:02:19 10:02:18.1233354:CID-0:RT:ageout 70,192.168.30.7/33->192.168.1.100/1,1, (0/0)
Sep 16 10:02:20 10:02:20.703925:CID-0:RT:<192.168.30.7/34->192.168.1.100/1;1> matched filter MatchTrafficIn:
Sep 16 10:02:20 10:02:20.704030:CID-0:RT:  vlan.1:192.168.30.7->192.168.1.100, icmp, (8/0)
Sep 16 10:02:20 10:02:20.704030:CID-0:RT: find flow: table 0x493482b0, hash 7089(0xffff), sa 192.168.30.7, da 192.168.1.100, sp 34, dp 1, proto 1, tok 7
Sep 16 10:02:20 10:02:20.704030:CID-0:RT:flow_ipv4_rt_lkup success 192.168.30.7, iifl 0x0, oifl 0x46
Sep 16 10:02:20 10:02:20.704030:CID-0:RT:search gate for untrust:192.168.30.7/34->192.168.1.100/1,1
Sep 16 10:02:20 10:02:20.704030:CID-0:RT:search widecast gate for untrust:192.168.30.7/34->192.168.1.100/1,1
Sep 16 10:02:20 10:02:20.704030:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.30.7, x_dst_ip 192.168.1.100, in ifp vlan.1, out ifp N/A sp 34, dp 1, ip_proto 1, tos 0
Sep 16 10:02:20 10:02:20.704532:CID-0:RT:  dip id = 0/0, 192.168.30.7/34->192.168.30.7/34

Some more logs which may be more helpfull:

Cannot obtain tunnel from Policy?  Any Ideas?

This is from Traffic between Trust and Untrust Zones:

Sep 16 11:50:53 OfficeFW01 clear-log[7926]: logfile cleared
Sep 16 11:50:55 11:50:54.1465871:CID-0:RT:<192.168.30.15/132->192.168.1.222/1;1> matched filter MatchTrafficIN:

Sep 16 11:50:55 11:50:54.1465871:CID-0:RT:packet [60] ipid = 383, @423c6640

Sep 16 11:50:55 11:50:54.1465871:CID-0:RT:---- flow_process_pkt: (thd 2): flow_ctxt type 1, common flag 0x0, mbuf 0x423c6400, rtbl_idx = 0

Sep 16 11:50:55 11:50:54.1465871:CID-0:RT: in_ifp <junos-self:.local..0>

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:flow_process_pkt_exception: setting rtt in lpak to 531580a8

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:pkt out of tunnel.Proceed normally

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  vlan.1:192.168.30.15->192.168.1.222, icmp, (8/0)

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT: find flow: table 0x493482b0, hash 55308(0xffff), sa 192.168.30.15, da 192.168.1.222, sp 132, dp 1, proto 1, tok 7

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  no session found, start first path. in_tunnel - 1291609452, from_cp_flag - 0

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  flow_first_create_session

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  flow_first_in_dst_nat: in <vlan.1>, out <N/A> dst_adr 192.168.1.222, sp 132, dp 1

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  chose interface N/A as incoming nat if.

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 192.168.1.222(1)

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.30.15, x_dst_ip 192.168.1.222, in ifp vlan.1, out ifp N/A sp 132, dp 1, ip_proto 1, tos 0

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:Doing DESTINATION addr route-lookup

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  routed (x_dst_ip 192.168.1.222) from untrust (vlan.1 in 0) to vlan.0, Next-hop: 192.168.1.222

Sep 16 11:50:55 11:50:54.1465974:CID-0:RT:  policy search from zone untrust-> zone trust (0x0,0x840001,0x1)

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT:  app 0, timeout 60s, curr ageout 60s

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT:  dip id = 0/0, 192.168.30.15/132->192.168.30.15/132

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT: get_nsp_tunnel - Tunnel not found. if vlan.0, nexthop ip 0xc0a801de, policy id 10

Sep 16 11:50:55 11:50:54.1466254:CID-0:RT:  packet dropped, cannot obtain tunnel from policy

Sep 16 11:50:55 11:50:54.1466384:CID-0:RT:cannot obtain tunnel from policy
Sep 16 11:50:55 11:50:54.1466715:CID-0:RT:  flow find session returns error.

Sep 16 11:50:55 11:50:54.1466715:CID-0:RT:flow_process_pkt_exception: Freeing lpak 3fcec9e8 associated with mbuf 0x423c6400

Sep 16 11:50:55 11:50:54.1466737:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc 0)

This is betwen DEG Zone and Untrust Zone:

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:packet [60] ipid = 557, @423e7dc0

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:---- flow_process_pkt: (thd 2): flow_ctxt type 1, common flag 0x0, mbuf 0x423e7b80, rtbl_idx = 0

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT: in_ifp <junos-self:.local..0>

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:flow_process_pkt_exception: setting rtt in lpak to 531580a8

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:pkt out of tunnel.Proceed normally

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:  vlan.1:192.168.30.15->192.168.220.10, icmp, (8/0)

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT: find flow: table 0x493482b0, hash 7312(0xffff), sa 192.168.30.15, da 192.168.220.10, sp 140, dp 1, proto 1, tok 7

Sep 16 12:01:32 12:01:31.1263543:CID-0:RT:  no session found, start first path. in_tunnel - 1291609452, from_cp_flag - 0

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  flow_first_create_session

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  flow_first_in_dst_nat: in <vlan.1>, out <N/A> dst_adr 192.168.220.10, sp 140, dp 1

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  chose interface N/A as incoming nat if.

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 192.168.220.10(1)

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:flow_first_routing: call flow_route_lookup(): src_ip 192.168.30.15, x_dst_ip 192.168.220.10, in ifp vlan.1, out ifp N/A sp 140, dp 1, ip_proto 1, tos 0

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:Doing DESTINATION addr route-lookup

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  routed (x_dst_ip 192.168.220.10) from untrust (vlan.1 in 0) to vlan.2, Next-hop: 192.168.2.1

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  policy search from zone untrust-> zone DEG (0x0,0x8c0001,0x1)

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  app 0, timeout 60s, curr ageout 60s

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  dip id = 0/0, 192.168.30.15/140->192.168.30.15/140

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:  choose interface vlan.2 as outgoing phy if

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:is_loop_pak: No loop: on ifp: vlan.2, addr: 192.168.220.10, rtt_idx:0

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT:jsf sess interest check. regd plugins 18

Sep 16 12:01:32 12:01:31.1263753:CID-0:RT: Allocating plugin info block for 18 plugin(s) from OL

I have exactly the same problem. Any solutions?

Hi,

Is any new policy added pointing to the tunnel which is already up?

When the tunnel is up,if we add new  policy which uses same tunnel,then the  tunnel pointer will not be synced with new policy.we need to disconnect the client and connect it back to be get synced.

Thanks,

Deebika

nope

This was a bug in 11.1 R4.4.

The workaround when you have multiple zones accessed by the VPN coming in on the untrust, to permit one tunnel and do a basic permit on the other policy.

from-zone untrust to-zone trust {
    policy Inbound_VPN {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn DynVPN;
                }
            }
        }
    }

from-zone untrust to-zone DEG {
    policy Untrust_to_DEG {
        match {
            source-address any;
            destination-address Destination_Subnet;
            application any;
        }
        then {
            permit;
        }
    }

I have this bug in 10.4R6.5 and 10.4R8.5, too. But I solved it without any tunnel definitions in the policies. I define only the Source and Destination Networks.

policy pol-dynamic_vpn-to-trust {
    match {
        source-address net-vpn_dynamic-vpn;
        destination-address net-trust;
        application any;
    }
    then {
        permit;
        count;
    }
}

I was facing same issue on 11.2R4.3

Thanks it worked for me

Hello,

This is just a remark, I've bumped into this post while researching similar (or even the same) behavior I got on Junos 12.1X44-D35.5  which was outlined in PR988263

After change to 12.1X44-D40.2 - seems to be fine

The solution above didn't help for this release.

Sorry for burrying out the old post.

Hi,

I'm runnin also version 12.1X44-D35.5, the suggested solution to remove the tunnel from one of the intra-zone policies did solved the issue.

Thanks.

I can confirm this bug and that it has been fixed in D40.2. This was particularly annoying for us because an upgrade from 11.4 to 12.1D35.5 resulted in non-working VPN connections which essentially logged me out of the device.

Thanks for everyone posting here, I doubt that I would have otherwise identified it as a JunOS issue.