SRX

Expand all | Collapse all

DMZ on a vSRX

Jump to Best Answer
  • 1.  DMZ on a vSRX

    Posted 02-07-2019 00:19

    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



  • 2.  RE: DMZ on a vSRX

    Posted 02-07-2019 00:56

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

     



  • 3.  RE: DMZ on a vSRX

    Posted 02-07-2019 01:15

    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.

     

     



  • 4.  RE: DMZ on a vSRX

    Posted 02-07-2019 02:47

    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

     



  • 5.  RE: DMZ on a vSRX

    Posted 02-07-2019 03:32

    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

     



  • 6.  RE: DMZ on a vSRX

    Posted 02-07-2019 05:10

    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;
    }
    }
    }



  • 7.  RE: DMZ on a vSRX

    Posted 02-07-2019 06:31

    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



  • 8.  RE: DMZ on a vSRX

    Posted 02-07-2019 08:01

    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



  • 9.  RE: DMZ on a vSRX
    Best Answer

    Posted 02-07-2019 08:25

    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

     

     



  • 10.  RE: DMZ on a vSRX

    Posted 02-07-2019 09:36
    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


  • 11.  RE: DMZ on a vSRX

    Posted 02-08-2019 03:00

    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