SRX

Hello all,

I am currently trying to have two of my zones communicate with the Internet (untrust zone) without success. I have other zones that work fine. Machines can also communicate from one zone to another without issues.

Unfortunately I've inherited the current configuration with little explanations, and I'm no network expert to start with, so I'm a bit at a loss currently. I did try to troubleshoot but there are many things I don't really understand.

My zones use the 192.168.5.X and the 192.168.6.X prefixes. Zones are called PRA-MF and DMZ-PRA-MF. Here is the current configuration (all information unrelated to my issue have been removed as well as public IP addresses) :

#show interfaces

reth0 {
    description "VLANS PRODUCTION";
    vlan-tagging;
    redundant-ether-options {
        redundancy-group 1;
    }
    unit 300 {
        description "VLAN PRA-MF";
        vlan-id 300;
        family inet {
            address 192.168.5.254/24;
        }
    }
    unit 301 {
        description "VLAN DMZ-PRA-MF";
        vlan-id 301;
        family inet {
            address 192.168.6.254/24;
        }
    }
}

reth2 {
    redundant-ether-options {
        redundancy-group 1;
    }
    unit 0 {
        family inet {
            filter {
                input mf-pra;
            }
            address XXX.XXX.XXX.XXX {
                preferred;
            }
        }
    }
}

#show security zones security zone PRA-MF

host-inbound-traffic {
    system-services {
        ping;
        telnet;
    }
}
interfaces {
    reth0.300 {
        host-inbound-traffic {
            system-services {
                ping;
                telnet;
            }
        }
    }
}

#show security zones security zones DMZ-PRA-MF

address-book {
    address 192.168.6.50 192.168.6.50/32;
    address-set set1 {
        address 192.168.6.50;
    }
}
host-inbound-traffic {
    system-services {
        ping;
        telnet;
    }
}
interfaces {
    reth0.301 {
        host-inbound-traffic {
            system-services {
                ping;
                telnet;
            }
        }
    }
}

#show security zones security zone untrust

host-inbound-traffic {
    system-services {
        ike;
        http;
        https;
        ping;
        ssh;
    }
}
interfaces {
    reth2.0 {
        host-inbound-traffic {
            system-services {
                ike;
                ssh;
                https;
                ping;
                http;
            }
        }
    }
}

#show security policies

from-zone PRA-MF to-zone DMZ-PRA-MF {
    policy flux_DMZ-PRA-MF {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone DMZ-PRA-MF to-zone PRA-MF {
    policy flux_PRA-MF {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone PRA-MF to-zone untrust {
    policy flux_untrust {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone untrust to-zone PRA-MF {
    policy flux_untrust {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone DMZ-PRA-MF to-zone untrust {
    policy flux_untrust {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone untrust to-zone DMZ-PRA-MF {
    policy flux_untrust {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

#show firewall filter mf-pra

 show firewall filter mf-pra
term 1 {
    from {
        destination-address {
            XXX.XXX.XXX.XXX/XXX;
        }
        destination-port [ 6330 1763 6331 22 5822 6537 990 4822 ];
    }
    then {
        routing-instance PRA-MF;
    }
}
term 2 {
    then accept;
}

#show routing-options
static {
    route 192.168.6.50/32 next-table PRA-MF.inet.0;
    route 192.168.5.50/32 next-table PRA-MF.inet.0;
    route 192.168.5.51/32 next-table PRA-MF.inet.0;
    route 192.168.5.52/32 next-table PRA-MF.inet.0;
    route 192.168.5.53/32 next-table PRA-MF.inet.0;
    route 192.168.5.54/32 next-table PRA-MF.inet.0;
    route 192.168.5.55/32 next-table PRA-MF.inet.0;
    route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX;
}
instance-import route-import-XXX-XXX-XXX;

#show routing-instances
PRA-MF {
    description "PRA MF";
    instance-type virtual-router;
    interface reth0.300;
    interface reth0.301;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX/XXX;
        }
        instance-import TO-PRA;
    }
}

#show policy-options policy-statement TO-PRA
term 1 {
    from {
        instance master;
        protocol direct;
        route-filter YYY.YYY.YYY.YYY/YYY exact; ##this is an old public IP address no longer in use
    }
    then accept;
}
term 2 {
    then reject;
}

#show security nat source

rule-set trust-to-untrust3 {
    from zone [ DMZ-PRA-MF PRA-MF ];
    to zone untrust;
    rule source-nat-rule3 {
        match {
            source-address 0.0.0.0/0;
            destination-address 0.0.0.0/0;
        }
        then {
            source-nat {
                interface;
            }
        }
    }
}
rule-set PRA-MF-to-reth2 {
    from routing-instance PRA-MF;
    to interface reth2.0;
    rule source-nat-PRA {
        match {
            source-address 0.0.0.0/0;
            destination-address 0.0.0.0/0;
        }
        then {
            source-nat {
                interface;
            }
        }
    }
}

#show security nat destination

pool DMZ-PRA-MF {
    address 192.168.6.50/32;
}

rule-set untrust {

 rule DMZ-PRA-MF-1763 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 1763;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }
    rule DMZ-PRA-MF-6331 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 6331;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }

rule DMZ-PRA-MF-6537 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 6537;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }
    rule DMZ-PRA-MF-5822 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 5822;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }
    rule DMZ-PRA-MF-4822 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 4822;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }
    rule DMZ-PRA-MF-990 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 990;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }
    rule DMZ-PRA-MF-22 {
        match {
            destination-address XXX.XXX.XXX.XXX/XXX;
            destination-port 22;
        }
        then {
            destination-nat {
                pool {
                    DMZ-PRA-MF;
                }
            }
        }
    }

}

I've also made traceoptions for the issue with the basic-datapath flag. Tried pinging the Google DNS server (8.8.8.8) from a machine that has the IP 192.168.5.52, and here are the results :

Oct 16 10:33:25 10:33:25.555056:CID-1:RT:<192.168.5.52/2525->8.8.8.8/1;1> matched filter MatchPRA:

Oct 16 10:33:25 10:33:25.555094:CID-1:RT:packet [60] ipid = 11491, @0x422bff24

Oct 16 10:33:25 10:33:25.555094:CID-1:RT:---- flow_process_pkt: (thd 3): flow_ctxt type 15, common flag 0x0, mbuf 0x422bfd00, rtbl_idx = 5

Oct 16 10:33:25 10:33:25.555132:CID-1:RT: flow process pak fast ifl 78 in_ifp reth0.300

Oct 16 10:33:25 10:33:25.555132:CID-1:RT:  reth0.300:192.168.5.52->8.8.8.8, icmp, (8/0)

Oct 16 10:33:25 10:33:25.555158:CID-1:RT: find flow: table 0x491f8d40, hash 45441(0xffff), sa 192.168.5.52, da 8.8.8.8, sp 2525, dp 1, proto 1, tok 20499

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:search gate for PRA-MF:192.168.5.52/2525->8.8.8.8/1,1

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:gate_search_specific_bucket: no gate found

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:search widecast gate for PRA-MF:192.168.5.52/2525->8.8.8.8/1,1

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:gate_search_widecast_bucket: no gate found

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:  flow_first_create_session

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:First path alloc and instl pending session, natp=0x4cd13980, id=47766

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:  flow_first_in_dst_nat: in <reth0.300>, out <N/A> dst_adr 8.8.8.8, sp 2525, dp 1

Oct 16 10:33:25 10:33:25.555158:CID-1:RT:  chose interface reth0.300 as incoming nat if.

Oct 16 10:33:25 10:33:25.555360:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 8.8.8.8(1)

Oct 16 10:33:25 10:33:25.555360:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.5.52, x_dst_ip 8.8.8.8, in ifp reth0.300, out ifp N/A sp 2525, dp 1, ip_proto 1, tos 0

Oct 16 10:33:25 10:33:25.555405:CID-1:RT:Doing DESTINATION addr route-lookup

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:Route-lookup for 8.8.8.8 yielded reject NH

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:  packet dropped, no route to dest

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 4294967295

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:  packet dropped, ROUTE_REJECT_GEN_ICMP.

Oct 16 10:33:25 10:33:25.555465:CID-1:RT:flow send icmp: pak->natp=0x4cd13980, pak->nsp=0x4cd13980

Oct 16 10:33:25 10:33:25.555465:CID-1:RT:Embedded ICMP outer iphdr before xlate: c0a805fe/768 -> c0a80534/42915

Oct 16 10:33:25 10:33:25.555465:CID-1:RT:Embedded ICMP inner iphdr before xlate: c0a80534/2048 -> 08080808/17278

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:flow_handle_icmp_xlate

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:xlate_icmp_pak

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:xlate_icmp_pak handle icmp4 embeded ip

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:Embedded ICMP outer iphdr after xlate: c0a805fe/768 -> c0a80534/42915

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:Embedded ICMP inner iphdr after xlate: c0a80534/2048 -> 08080808/17278

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:Sending icmp:3, code: 0

Oct 16 10:33:25 10:33:25.555558:CID-1:RT:flow_send_return_pak: lpak 0x48ae9eb0, npak 0x48df912c, npak->in_if N/A, outifp reth0.300.

Oct 16 10:33:25 10:33:25.555664:CID-1:RT:**** jump to packet:192.168.5.254->192.168.5.52

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:  encap vector

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:  no more encapping needed

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:  **** pak processing end.

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak: outifp reth0.300, iif 0, vr_id 5.

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak : Using iif 0

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_send_return_pak() 0x43036280 :  mbuf injected, return code 0

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_first_routing: Sending icmp/tcp-rst for route-lookup failure

Oct 16 10:33:25 10:33:25.555685:CID-1:RT:flow_initiate_first_path: first pak no session

Oct 16 10:33:25 10:33:25.555764:CID-1:RT:  flow find session returns error.

Oct 16 10:33:25 10:33:25.555764:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

Thanks in advance to anyone who might try to help.

HI !

there is a default route missing pointing to the internet

see:

Oct 16 10:33:25 10:33:25.555405:CID-1:RToing DESTINATION addr route-lookup

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:Route-lookup for 8.8.8.8 yielded reject NH

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:  packet dropped, no route to dest

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:flow_first_routing: DEST route-lookup failed, dropping pkt and not creating session nh: 4294967295

regards

alexander

Hello Alexander,

Thank you for your answer.  As shown in my previous post the routing configuration is as follow:

#show routing-options
static {
    route 192.168.6.50/32 next-table PRA-MF.inet.0;
    route 192.168.5.50/32 next-table PRA-MF.inet.0;
    route 192.168.5.51/32 next-table PRA-MF.inet.0;
    route 192.168.5.52/32 next-table PRA-MF.inet.0;
    route 192.168.5.53/32 next-table PRA-MF.inet.0;
    route 192.168.5.54/32 next-table PRA-MF.inet.0;
    route 192.168.5.55/32 next-table PRA-MF.inet.0;
    route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX; #This is the route to the internet
}
instance-import route-import-XXX-XXX-XXX;

#show routing-instances
PRA-MF {
    description "PRA MATIGNON FINANCES";
    instance-type virtual-router;
    interface reth0.300;
    interface reth0.301;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop XXX.XXX.XXX.XXX/XXX; #this is also the route to the internet, same as above
        }
        instance-import TO-PRA;
    }
}

Do you have any idea what might be wrong with it?

do a show route table <instance-name>.inet0 0.0.0.0/0 extensive for the default route, to see if it is active and working, and if not what is the reason for it.

also look for the next-hop in the default route . Is it on a directly connected network, if not you need to add the resolve keyword to the static route definition.

as you still need the next-hop address in the routing table you should update the following with the new and correct next-hop address.

#show policy-options policy-statement TO-PRA
term 1 {
    from {
        instance master;
        protocol direct;
        route-filter YYY.YYY.YYY.YYY/YYY exact; ##this is an old public IP address no longer in use
    }
    then accept;
}
term 2 {
    then reject;
}

regards

alexander

Hello Alexander,

Thank you once again for your reply. Here are the results of the command :

192.168.5.0/24 (1 entry, 0 announced)
        *Direct Preference: 0
                Next hop type: Interface
                Address: 0x15a09dc
                Next-hop reference count: 1
                Next hop: via reth0.300, selected
                State: <Active Int>
                Age: 12w5d 20:54:31
                Task: IF
                AS path: I

192.168.5.254/32 (1 entry, 0 announced)
        *Local  Preference: 0
                Next hop type: Local
                Address: 0x1174324
                Next-hop reference count: 24
                Next hop:
                Interface: reth0.300
                State: <Active NoReadvrt Int>
                Age: 12w5d 20:54:31
                Task: IF
                AS path: I

192.168.6.0/24 (1 entry, 0 announced)
        *Direct Preference: 0
                Next hop type: Interface
                Address: 0x15a0990
                Next-hop reference count: 1
                Next hop: via reth0.301, selected
                State: <Active Int>
                Age: 12w5d 20:54:31
                Task: IF
                AS path: I

192.168.6.254/32 (1 entry, 0 announced)
        *Local  Preference: 0
                Next hop type: Local
                Address: 0x1174324
                Next-hop reference count: 24
                Next hop:
                Interface: reth0.301
                State: <Active NoReadvrt Int>
                Age: 12w5d 20:54:31
                Task: IF
                AS path: I

Am I right to suppose that the mistake comes from the part in bold (no hop addresses)? Those addresses (5.254 & 6.254) are the interfaces addresses for the two problematic zones.

For information I am physically directly connected to the next hop, and other zones are using the same next-hop IP with no issues. I suppose something must be missing from the configuration, but I can't figure out what: 

-Zone to zone communication is open both ways

-Routing is configured by using the routing instance

-Interfaces are correctly configured

I've removed the TO-PRA instance-import  statementfrom the PRA-MF routing instance as I believe it is now obsolete, but no changes.

Hi Ztech,

Please share the following command:

> show route table PRA-MF.inet.0

Based on the traceoptions, the SRX is peforming the route-lookup in a custom routing-instance (assumed to be PRA-MF) and not finding a route to 8.8.8.8 (more likely the default route is missing). Running the above command will tell you if the default route is not showing up.

Oct 16 10:33:25 10:33:25.555360:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.5.52, x_dst_ip 8.8.8.8, in ifp reth0.300, out ifp N/A sp 2525, dp 1, ip_proto 1, tos 0

.
.
.

Oct 16 10:33:25 10:33:25.555422:CID-1:RT:Route-lookup for 8.8.8.8 yielded reject NH

I believe that the PRA-MF routing-instance is not aware of the subnet connected to reth2.0 (untrust zone) and that the next-hop address that PRA-MF routing-instance is trying to resolve is on that subnet connected to reth2.0 interface. Please let us know if this is correct.

If the above statement is correct, we need to make sure PRA-MF routing-instance knows reth2.0's subnet. You could apply some RIB groups to accomplish this:

1. Create a Rib-group to share routes from inet.0 table (Default routing-instance) to PRA-MF.inet.0 table. Also there is a routing-policy (RETH2-SUBNET-ONLY) to ensure that only reth2.0's subnet is shared between the mentioned tables.

	set routing-options rib-groups EXAMPLE import-rib [ inet.0 PRA-MF.inet.0 ]   
	set routing-options rib-groups EXAMPLE import-policy RETH2-SUBNET-ONLY
	
2. Create the routing-policy to match the subnet of reth2.0 only:

	set policy-statement RETH2-SUBNET-ONLY term RETH2 from route-filter [reth2_subnet] exact;
	set policy-statement RETH2-SUBNET-ONLY term RETH2 then accept;
	set policy-statement RETH2-SUBNET-ONLY term REJECT-REST then reject;

3. Apply the rib-group under the Default routing-instance, under interface-routes hierarchy, in order to share the directly connected subnets from inet.0 to PRA-MF.inet.0:

	set routing-options interface-routes rib-group EXAMPLE

Please let us know.

Hello epaniagua,

Thank you for this answer. Here is the output of the command :

>show route table PRA-MF.inet.0

PRA-MF.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.5.0/24     *[Direct/0] 12w6d 16:20:10
                    > via reth0.300
192.168.5.254/32   *[Local/0] 12w6d 16:20:10
                      Local via reth0.300
192.168.6.0/24     *[Direct/0] 12w6d 16:20:10
                    > via reth0.301
192.168.6.254/32   *[Local/0] 12w6d 16:20:10
                      Local via reth0.301

Your solution seems to be correct, after adding the rib-groups I am now able to ping the internet. I've marked your post as the solution.

Thank you very much for your help, I thought I'd have gone crazy at this rate.

Ztech,

You are very welcome, I am glad that it works now.