SRX

I'm trying to set up a DMZ on a vSRX
I have a ge-0/0/0 interface in an untrust zone and a ge-0/0/1 interface in a trust zone
Behind the ge-0/0/1 interface I have a level 3 switch with a declared level 3 vlan

I added a ge-0/0/2 interface, I assigned an IP adress and I created a new DMZ zone.

I added all DMZ rules in security policies (DMZ to untrust pass all)

 

If I put the ge-0/0/2 interface in the trust zone everything works fine: internet access and ping response from the vlan behind the vSRX. So the routing is correct.

 

If I put the ge-0/0/2 interface in the DMZ zone, nothing works: no more access to the internet and no more response to the ping of the vlan which is behind the vSRX

 

I  think I forgot something but I do not know what

 

Thanks for your help

 

Gilles

Do you have source nat configured for trust to untrust zone? If yes, please check NAT config for DMZ

 

Hello Nellikka

 

The network for the DMZ is on a public class (134.59.x.222/27).

For now I do not use NAT because all networks are public.

 

 

Try to ping vSRX gateway ip with using source as trust interface ip and dmz interface ip. If you are able to ping using trust interface ip but dmz ip, gateway may not have reverse route for dmz network (134.59.x.222/27)

 

Are you able to ping DMZ interface ip from DMZ PC  and vice versa?

If possible, please share configuration

 

Hi,

 

I hope you are not using any custom VR etc and vSwitch etc connectivity is fine.

When you put ge-0/0/2 in trust zone, do you use same IP as 134.59.x.222/27 or the one from the ge-0/0/1 subnet ? If you use the IP from the 134.59.x.222/27 subnet and it works then please check your security policy  from DMZ to untrust.

If you use IP from ge-0/0/1 subnet and it works then please check security policy and NAT from DMZ to untrust. Even it's public IP , you can try using source NAT ( for test only) to ensure it's not issue with the return route on the upstream device.

 

> show security nat source rule all

> show security policies from-zone DNZ to-zone untrust

 

Thanks,

Vikas

 

The configuration (below) is very simple, I don't use any NAT

> show security policies from-zone DMZ1 to-zone untrust
From zone: DMZ1, To zone: untrust
Policy: DMZ1-to-untrust, State: enabled, Index: 7, Scope Policy: 0, Sequence number: 1
Source addresses: any
Destination addresses: any
Applications: any
Dynamic Applications: any
Action: permit

 

I have a PC (134.59.21.221) doirectly connecte to ge-0/0/2 interface

With the ge-0/0/2 interface on DMZ1 zone

Ping from PC (134.59.21.222) to ge-0/0/2.0 (134.59.21.222) is successful

tracert command from PC to 8.8.8.8 fails (never reach the first hop

 

With the ge-0/0/2 interface on trust zone, without changing anything else

Ping from PC (134.59.21.222) to ge-0/0/2.0 (134.59.21.222) is successful

tracert command from PC to 8.8.8.8 is succesful and the first hop is 134.59.21.222

 

That's why I think there is no route problem and it's a zone problem

 

Thanks

## Last changed: 2019-02-07 09:04:43 CET
version 18.4R1.8;
system {
services {
ssh;
web-management {
http {
interface [ ge-0/0/0.0 fxp0.0 ge-0/0/1.0 ];
}
https {
system-generated-certificate;
interface [ ge-0/0/0.0 fxp0.0 ge-0/0/1.0 ];
}
}
}
}
security {
alg {
dns disable;
}
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
queue-size 2000;
timeout 20;
}
land;
}
}
}
policies {
from-zone trust to-zone trust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone untrust {
policy default-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone DMZ1 to-zone untrust {
policy DMZ1-to-untrust {
match {
source-address any;
destination-address any;
application any;
dynamic-application any;
}
then {
permit;
}
}
}
from-zone trust to-zone DMZ1 {
policy trust_to_DMZ1 {
match {
source-address any;
destination-address any;
application any;
dynamic-application any;
}
then {
permit;
}
}
}
from-zone DMZ1 to-zone trust {
policy DMZ1_to_trust {
match {
source-address any;
destination-address any;
application any;
dynamic-application any;
}
then {
permit;
}
}
}
from-zone DMZ1 to-zone DMZ1 {
policy default-permit_61 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone untrust {
inactive: screen untrust-screen;
host-inbound-traffic {
system-services {
ping;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone DMZ1 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/2.0;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 172.16.21.1/30;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 172.16.21.6/30;
}
}
}
ge-0/0/2 {
description DMZ1;
unit 0 {
description DMZ1;
family inet {
address 134.59.21.222/27;
}
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.*.*/22;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 {
next-hop 172.16.21.2;
active;
}
route 134.59.x.x/32 {
next-hop 192.168.23.254;
active;
}
route 134.59.21.128/28 {
next-hop 172.16.21.5;
active;
}
route 134.59.21.144/28 {
next-hop 172.16.21.5;
active;
}
route 134.59.21.160/28 {
next-hop 172.16.21.5;
active;
}
}
}

Config looks fine. Can you check the flow traceoptions:

 

#set security flow traceoptions file flow-trace
# set security flow traceoptions flag basic-datapath
# set security flow traceoptions packet-filter f0 source-prefix <134.59.21.221> destination-prefix <8.8.8.8>
# set security flow traceoptions packet-filter f1 source-prefix <8.8.8.8> destination-prefix <134.59.21.221> <-- filter for the return traffic, IPs will interchange.

# commit
initiate the ping test to 8.8.8.8 and let it fail and
#run show log flow-trace
#deactivate security flow traceoptions
#commit

 

Thanks,

Vikas

Feb 7 16:33:26 vSRX-SG-01 clear-log[11503]: logfile cleared
Feb 7 16:55:41 16:55:41.032708:CID-0:RT:<134.59.21.221/1003->8.8.8.8/1;1,0x0> matched filter pf1:

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:packet [60] ipid = 7193, @0x2da22048e

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:---- flow_process_pkt: (thd 4): flow_ctxt type 15, common flag 0x0, mbuf 0x401a9a00, rtbl_idx = 0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: flow process pak fast ifl 75 in_ifp ge-0/0/2.0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: ge-0/0/2.0:134.59.21.221->8.8.8.8, icmp, (8/0)

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: find flow: table 0x7a139940, hash 386984(0xfffff), sa 134.59.21.221, da 8.8.8.8, sp 1003, dp 1, proto 1, tok 10, conn-tag 0x00000000

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: flow_first_create_session

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:Save init hash spu id 0 to nsp and nsp2!

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:First path alloc and instl pending session, natp=0x93031700, id=524850

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: flow_first_in_dst_nat: in <ge-0/0/2.0>, out <N/A> dst_adr 8.8.8.8, sp 1003, dp 1

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: chose interface ge-0/0/2.0 as incoming nat if.

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 8.8.8.8(1)

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:[JSF] Do ingress interest check. regd ingress plugins(1)

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:[JSF][0]plugins(0x0) enabled for session = 524850 implicit mask(0x0), service request(0x0)

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:-jsf : no plugin ingress interested for session 524850
Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 134.59.21.221, x_dst_ip 8.8.8.8, in ifp ge-0/0/2.0, out ifp N/A sp 1003, dp 1, ip_proto 1, tos 0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:Doing DESTINATION addr route-lookup

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_ipv4_rt_lkup success 8.8.8.8, iifl 0x4b, oifl 0x46

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: routed (x_dst_ip 8.8.8.8) from DMZ1 (ge-0/0/2.0 in 0) to ge-0/0/0.0, Next-hop: 172.16.21.2

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_first_policy_search: policy search from zone DMZ1-> zone untrust (0x0,0x3eb0001,0x1)

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:Policy lkup: vsys 0 zone(10:DMZ1) -> zone(8:untrust) scope:0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: 134.59.21.221/2048 -> 8.8.8.8/18800 proto 1

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_first_policy_search: dynapp_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: app 0, timeout 60s, curr ageout 60s

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: packet dropped, denied by policy

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: denied by policy default-policy-logical-system-00(2), dropping pkt

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: packet dropped, policy deny.

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_initiate_first_path: first pak no session

Feb 7 16:55:41 16:55:41.032708:CID-0:RT: flow find session returns error.

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_proc_rc: -1.

 

Interesting but I don't understand "denied by policy default-policy-logical-system-00(2), dropping pkt"

 

Thanks for your help

Remove "dynamic-application any"from DMZ to untrust policy.
delete security policies from-zone DMZ1 to-zone untrust policy DMZ1-to-untrust match dynamic-application any

 

 

Feb 7 16:55:41 16:55:41.032708:CID-0:RT:flow_first_policy_search: dynapp_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0 Probably ICMP traffic is not categorised as any dynamic app so it's not trying to match with the security policies which have the dynamic-app configured. And failing with default deny. https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/dynamic-application-security-policies.html Either remove the denamic-app from the security policy or try configuring none . Thanks, Vikas

It works now !

Actually this is a new feature I did not think it would block the ping command.
Thank you again for your help, which has been precious to me.

Best regards

Gilles