SRX

I have two zones:

1. DMZ which is used by dynamic VPN users to gain restricted access to the network. (ip pool: 10.10.10.0/30)

2. Trust (ip pool: 10.1.1.0/24)

I have added 10.1.1.0/24 to my dynamic VPN's remote-protected-resources option which should allow VPN users access to the trust zone's network devices. However, when I setup a VPN connection and try to ping 10.1.1.1 I get a timeout.

I have attached the config.

Traceoptions output for "ping 10.1.1.1 -n 1" below:

packet [60] ipid = 860, @0x436962d0
---- flow_process_pkt: (thd 2): flow_ctxt type 1, common flag 0x0, mbuf 0x43696080, rtbl_idx = 0
in_ifp <junos-host:.local..0>
flow_process_pkt_exception: setting rtt in lpak to 0x680feed0
pkt out of tunnel.Proceed normally
ge-0/0/15.0:10.10.10.2->10.1.1.1, icmp, (8/0)
find flow: table 0x510e1138, hash 11219(0xffff), sa 10.10.10.2, da 10.1.1.1, sp 390, dp 1, proto 1, tok 20489
no session found, start first path. in_tunnel - 0x5733e170, from_cp_flag - 0
flow_first_create_session
flow_first_in_dst_nat: in <ge-0/0/15.0>, out <N/A> dst_adr 10.1.1.1, sp 390, dp 1
chose interface N/A as incoming nat if.
flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.1.1.1(1)
flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 10.10.10.2, x_dst_ip 10.1.1.1, in ifp ge-0/0/15.0, out ifp N/A sp 390, dp 1, ip_proto 1, tos 0
Doing DESTINATION addr route-lookup
routed (x_dst_ip 10.1.1.1) from dmz (ge-0/0/15.0 in 0) to ge-0/0/15.0, Next-hop: 195.xx.xx.97
flow_first_policy_search: policy search from zone dmz-> zone dmz (0x0,0x1860001,0x1)
Policy lkup: vsys 0 zone(9:dmz) -> zone(9:dmz) scope:0
10.10.10.2/2048 -> 10.1.1.1/19413 proto 1
app 0, timeout 60s, curr ageout 60s
permitted by policy default(4)
packet passed, Permitted by policy.
flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False
flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.
dip id = 0/0, 10.10.10.2/390->10.10.10.2/390 protocol 0
choose interface ge-0/0/15.0 as outgoing phy if
is_loop_pak: No loop: on ifp: ge-0/0/15.0, addr: 10.1.1.1, rtt_idx:5
-jsf : Alloc sess plugin info for session 96154
[JSF]Normal interest check. regd plugins 19, enabled impl mask 0x0
-jsf int check: plugin id 2, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 3, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 5, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 6, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 7, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 8, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 12, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 15, svc_req 0x0, impl mask 0x0. rc 4
+++++++++++jsf_test_plugin_data_evh: 3
-jsf int check: plugin id 16, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 22, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 23, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 26, svc_req 0x0, impl mask 0x0. rc 4
-jsf int check: plugin id 27, svc_req 0x0, impl mask 0x0. rc 2
-jsf int check: plugin id 28, svc_req 0x0, impl mask 0x0. rc 4
[JSF]Plugins(0x0, count 0) enabled for session = 140069716, impli mask(0x0), post_nat cnt 96154 svc req(0x0)
-jsf : no plugin interested for session 96154, free sess plugin info
flow_first_service_lookup(): natp(0x57573290): app_id, 0(0).
service lookup identified service 0.
flow_first_final_check: in <ge-0/0/15.0>, out <ge-0/0/15.0>
flow_first_complete_session, pak_ptr: 0x50a2ee38, nsp: 0x57573290, in_tunnel: 0x5733e170
construct v4 vector for nsp2
existing vector list 0x204-0x48c08dd0.
Session (id:96154) created for first pak 204
flow_first_install_session======> 0x57573290
nsp 0x57573290, nsp2 0x57573310
make_nsp_ready_no_resolve()
reverse route is optional
no need update ha
Installing s2c NP session wing
flow got session.
flow session id 96154
vector bits 0x204 vector 0x48c08dd0
skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
encap vector
no more encapping needed
mbuf 0x43696080, exit nh 0x100010
flow_process_pkt_exception: Freeing lpak 0x50a2ee38 associated with mbuf 0x43696080
----- flow_process_pkt rc 0x0 (fp rc 0)

Attachment(s)

conf.txt   10 KB 1 version

Hi,

I see that you have this in your config :

from-zone trust to-zone dmz {
            policy default {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit {
                        tunnel {
                            ipsec-vpn dyn-vpn;
                        }
                    }
                }
            }
        }

What you are doing here is that all traffic comming from trust to dmz , only traffic permitted is to go into an ipsec-vpn,

the system is then only allowing the traffic if the srx has buildup an ipsec-vpn with the name dyn-vpn to an other remote site. A dynamic-vpn is normaly sourced from the client the srx is the destination.

You need to change this policy to the next

from-zone trust to-zone dmz {
            policy default {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit 
                }
            }
        }

Now you allow all traffic from the trust zone to the dmz zone. The traffic will be allowed into the dynamic-vpn when a tunnel is setup from a client this cause the client is sourcing the traffic "request" to the dmz zone. The srx knows where to send the return traffic comming from the trust zone towards the clients.

I also see that you have two nat rules inplace that are a bit "redundant"

nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
            rule-set trust-to-dmz {
                from zone trust;
                to zone dmz;
                rule dmz-rule {
                    match {
                        source-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }

it really has no use to try to nat the same trust zone outside via to different zones. That will give you some headache on a moment you need to troubleshoot.

if you need to do something like this I would suggest something like below:

nat {
source {
    pool src-nat-pool-dmz {
        address {
            213.x.x.20/32;
        }
    }
    pool src-nat-pool-trust {
        address {
            213.x.x.2/32;
        }
    }
    source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 10.1.0.0/0;
                        destination-address 0.0.0.0/0
                    }
                    then {
                source-nat {
                    pool {
                        src-nat-pool-trust;
                    }
                }
            }
        }
    }
           rule-set trust2-to-dmz {
                from zone trust2;
                to zone dmz;
                rule dmz-rule {
                    match {
                        source-address 10.2.0.0/24;
                         destination-address 0.0.0.0/0;
            }
            then {
                source-nat {
                    pool {
                        src-nat-pool-dmz;
                    }
                }
            }
        }
    }

In the situation you are in right now the below nat config will be (I think) the best solution:

nat {
        source {
            rule-set trust-to-untrust {
                from zone trust;
                to zone untrust;
                rule source-nat-rule {
                    match {
                        source-address 10.1.1.0/24;
                        destination-address 0.0.0.0/0
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
       }

Off Option

It is possible to identify traffic that you specifically don’t want to NAT. This would be useful if you are NAT’ing everything coming from DMZ going to UNTRUST, but you didn’t want to NAT a specific flow that is supposed to go over a VPN tunnel. To conduct something like that you would use the off option. Here is an example:

set security nat source rule-set NAT-DMZ-TO-UNTRUST from zone DMZset security nat source rule-set NAT-DMZ-TO-UNTRUST to zone UNTRUST
set security nat source rule-set NAT-DMZ-TO-UNTRUST rule NAT-OFF match source-address 192.168.0.0/16set security nat source rule-set NAT-DMZ-TO-UNTRUST rule NAT-OFF match destination-address 172.16.57.0/24set security nat source rule-set NAT-DMZ-TO-UNTRUST rule NAT-OFF then source-nat off
set security nat source rule-set NAT-DMZ-TO-UNTRUST rule PAT-INTERFACE match source-address 192.168.0.0/16set security nat source rule-set NAT-DMZ-TO-UNTRUST rule PAT-INTERFACE match destination-address 0.0.0.0/0set security nat source rule-set NAT-DMZ-TO-UNTRUST rule PAT-INTERFACE then source-nat interface

Notice there are two rules. The first is called NO-NAT which specifically says source-nat off if the traffic matches the criteria. That is because this traffic is going over a VPN and we don’t want it to be NAT’d but everything else must be source NAT’d to the interface IP.

This is the Cisco equivalent to doing a NAT Zero, NAT 0, No NAT, or Identity NAT.

Hope this helps a bit!

Thanks Marc; a well structured response, as usual 🙂

I have sorted out the highlighted issues; the primary problem still persists, I still cannot access protected resources on the network. 

Latest config is attached.

the remote-protected-resources IP is set to 10.1.1.1/32 - if I ping that IP I get a timeout; if however I ping 10.1.1.30 for example, I get a "general error"; so the packet is getting through, but it is being lost somewhere.

VPN IP: 10.10.10.2 (dmz zone)

Restricted resource: 10.1.1.1 (trust zone)

command: ping -S 10.10.10.2 10.1.1.1

flow debug output:

<10.10.10.2/434->10.1.1.1/1;1> matched filter dmz_to_trust:

packet [60] ipid = 187, @0x436a1dd0

---- flow_process_pkt: (thd 2): flow_ctxt type 1, common flag 0x0, mbuf 0x436a1b80, rtbl_idx = 0

 in_ifp <junos-host:.local..0>

flow_process_pkt_exception: setting rtt in lpak to 0x680feed0

pkt out of tunnel.Proceed normally

  ge-0/0/15.0:10.10.10.2->10.1.1.1, icmp, (8/0)

 find flow: table 0x510e1138, hash 24339(0xffff), sa 10.10.10.2, da 10.1.1.1, sp 434, dp 1, proto 1, tok 20489

  no session found, start first path. in_tunnel - 0x5d0f7f90, from_cp_flag - 0

  flow_first_create_session

  flow_first_in_dst_nat: in <ge-0/0/15.0>, out <N/A> dst_adr 10.1.1.1, sp 434, dp 1

  chose interface N/A as incoming nat if.

flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.1.1.1(1)

flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 10.10.10.2, x_dst_ip 10.1.1.1, in ifp ge-0/0/15.0, out ifp N/A sp 434, dp 1, ip_proto 1, tos 0

Doing DESTINATION addr route-lookup

  routed (x_dst_ip 10.1.1.1) from dmz (ge-0/0/15.0 in 0) to ge-0/0/15.0, Next-hop: 195.xx.xx.97

flow_first_policy_search: policy search from zone dmz-> zone dmz (0x0,0x1b20001,0x1)

Policy lkup: vsys 0 zone(9:dmz) -> zone(9:dmz) scope:0

             10.10.10.2/2048 -> 10.1.1.1/19369 proto 1

  app 0, timeout 60s, curr ageout 60s

  permitted by policy default(4)

  packet passed, Permitted by policy.

flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

  dip id = 0/0, 10.10.10.2/434->10.10.10.2/434 protocol 0

  choose interface ge-0/0/15.0 as outgoing phy if

is_loop_pak: No loop: on ifp: ge-0/0/15.0, addr: 10.1.1.1, rtt_idx:5

-jsf : Alloc sess plugin info for session 307386

[JSF]Normal interest check. regd plugins 19, enabled impl mask 0x0

-jsf int check: plugin id  2, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id  3, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id  5, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id  6, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id  7, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id  8, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 12, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 15, svc_req 0x0, impl mask 0x0. rc 4

+++++++++++jsf_test_plugin_data_evh: 3

-jsf int check: plugin id 16, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 22, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 23, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 26, svc_req 0x0, impl mask 0x0. rc 4

-jsf int check: plugin id 27, svc_req 0x0, impl mask 0x0. rc 2

-jsf int check: plugin id 28, svc_req 0x0, impl mask 0x0. rc 4

[JSF]Plugins(0x0, count 0) enabled for session = 140069716, impli mask(0x0), post_nat cnt 307386 svc req(0x0)

-jsf : no plugin interested for session 307386, free sess plugin info

flow_first_service_lookup(): natp(0x5d14f390): app_id, 0(0).

  service lookup identified service 0.

  flow_first_final_check: in <ge-0/0/15.0>, out <ge-0/0/15.0>

flow_first_complete_session, pak_ptr: 0x50a2ee38, nsp: 0x5d14f390, in_tunnel: 0x5d0f7f90

construct v4 vector for nsp2

  existing vector list 0x204-0x48c08dd0.

  Session (id:307386) created for first pak 204

  flow_first_install_session======> 0x5d14f390

 nsp 0x5d14f390, nsp2 0x5d14f410

  make_nsp_ready_no_resolve()

  reverse route is optional

no need update ha

Installing s2c NP session wing

  flow got session.

  flow session id 307386

 vector bits 0x204 vector 0x48c08dd0

skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0

  encap vector

  no more encapping needed

mbuf 0x436a1b80, exit nh 0x100010

flow_process_pkt_exception: Freeing lpak 0x50a2ee38 associated with mbuf 0x436a1b80

 ----- flow_process_pkt rc 0x0 (fp rc 0)

Attachment(s)

conf.txt   11 KB 1 version

Hi,

I see that you have a route in your routing-instance :

route 10.10.10.1/32 {
                    next-hop 10.1.1.1;
                    preference 1;

You are routing the ip of the dynamic-vpn users towards a next-hop of 10.1.1.1 which is the ip of the srx in the main instances / trust zone.

Traffic will be pushed towards that interface instead of going on to the dynamic-vpn. You need to remove this route.

You need to have leak routes between the two routing instances by using rib groups

Thanks; I completely forgot about that static route; added it to test something and was supposed to remove it, thanks.

I have never setup leak routes nor rib groups. I did some reading on it and still don't really get the jist of how it'll work in my scenario. Do you mind providing some guidance in that regard?

Hi,

something like this will get the trick done

under the :

 edit routing-options

The rib group we will be using:  

    interface-routes {
        rib-group inet vpnroutes;
} 

Little note: The order of the tables referred under the import-rib does not matter for this 'Interface route' configuration. However, the order of the tables for the other configurations (Dynamic Routing Protocol (OSPF) and Static Routes) does matter.

edit routing-options

    rib-groups {
        vpnroutes {
            import-rib [ inet.0 VPN1.inet.0 ];
        }
    }

VPN1 {
    instance-type virtual-router;
    interface ge-0/0/15.0;
    routing-options {
        interface-routes {
            rib-group inet vpnroutes; 
        }
    }
}

Thanks Marc; I managed to get it sorted.

In the end, I took  your advice from your other post on my other thread and have simplified the setup. I scrapped the DMZ zone, moved VPN to ge-0/0/0 and set the protected resource to a /32 address which is ample protection from a security standpoint. It works as expected.

Thanks for you help one again.