SRX Fun with Tap Mode and Logging

 To do a tap mode on the SRX is more than just what is in the user guide for security policies.  I had to use this site to find out more.  

First, set up your interface for promiscuity.  

set interfaces ge-0/0/10 promiscuous-mode

Next setup the tap mode under security forwarding-options 

set security forwarding-options mode tap interface ge-0/0/0

You can then setup a routing instance if you need but I didn't worry about that.  I set up my flow and log settings 

set security flow tcp-session no-syn-check
set security flow tcp-session no-sequence-check
set security log mode stream
set security log report

After that was setting up the zone configuration

set security zones security-zone tap-zone interfaces ge-0/0/10.0
set security zones security-zone tap-zone application-tracking

Finally I setup the policy for testing.  

set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match source-address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match destination -address any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy match application any
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then permit
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-init
set security policies from-zone tap-zone to-zone tap-zone policy tap-policy then log session-close

The switch was easier to setup for SPAN.

set forwarding-options analyzer SRX_SPAN input ingress interface xe-0/0/10.0
set forwarding-options analyzer SRX_SPAN input ingress interface xe-0/0/6.0
set forwarding-options analyzer SRX_SPAN input egress interface xe-0/0/6.0
set forwarding-options analyzer SRX_SPAN output interface xe-0/0/5.0

To verify TAP mode, use run show security flow status.

root@SRX03> show security flow status     
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Tap mode: enabled
    Enhanced services mode: Disabled
  Flow trace status
    Flow tracing status: off
  Flow session distribution
    Distribution mode: Hash-based
    GTP-U distribution: Disabled
    SCTP distribution: Enabled
  Flow ipsec performance acceleration: off
  Flow gre performance acceleration: off
  Flow packet ordering
    Ordering mode: Hardware
  Flow power mode: Enabled
  Flow power mode IPsec: Enabled
  Flow power mode IPsec QAT: Disabled
  Fat core group status: off
  Flow inline fpga crypto: Disabled
root@SRX03> 

And to verify the flow is being seen with policies

root@SRX03> show security flow session    
Session ID: 1389, Policy name: tap-policy/5, Timeout: 60, Session State: Valid
  In: 172.18.33.33/514 --> 10.1.1.100/514;udp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 3, Bytes: 3422, 
  Out: 10.1.1.100/514 --> 172.18.33.33/514;udp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 0, Bytes: 0, 

Session ID: 1390, Policy name: tap-policy/5, Timeout: 4, Session State: Valid
  In: 192.168.1.100/24 --> 10.1.1.10/12044;icmp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 1, Bytes: 84, 
  Out: 10.1.1.10/12044 --> 192.168.1.100/24;icmp, Conn Tag: 0x0, If: ge-0/0/10.0, Pkts: 0, Bytes: 0, 

Now logging was not right either in the user guide.  It missed the part of seeting the mode.  After playing this was my final security log config.

set security log mode stream
set security log format sd-syslog
set security log report
set security log source-address 172.18.33.33
set security log stream trafficlogs severity debug
set security log stream trafficlogs host 10.1.1.100

Security Policies

 So I learned something interesting.  Sounds fundamental but just never really thought about it.  

I was trying to ping from an SRX loopback to another.  I had ping allowed on the zone host-inbound-traffic but it would not ping.  Interfaces were in the correct zone.  I could see the traffic going to the firewall on a packet capture but could not ping.  

Finally after playing and playing I found out that what I had to do was allow the traffic to go from zone UNTRUST to zone UNTRUST.  I had it already in UNTRUST to junos-host so that was not an issue.  I was under the impression that since my external interface and my loopback were in UNTRUST and I was allowing it from UNTRUST to junos-host, it would be good.  Boy was I wrong.  

Which after I got it working it made since.  I was going from UNTRUST to UNTRUST to junos-host.  Explained why my VPN was not working as well.  

Anyways, live and learn.  Time for more labbing. 

SRX Flow Logging

So I am loving me some Juniper over Cisco for sure.  But there are a lot of things to get used to anymore as well.  One is logging.  How does it work?  What happened to seeing stuff fly across the screen and lock my console up?  Ah the fun old days.  

So trying to troubleshoot some BGP on the SRX I had to play with logging.  I tried and tried to make it work and well kept falling flat.  That is because I was in the wrong dang area.  I was trying to look at flows coming across the device and tried doing traceoptions in security and in policies.  Both did not work.  To make this work I found an article on what i was missing.

Basically I had to enable logging under security flow.  Some people are probably reading that and going duh but these are my notes so whatever.  

Anyways I didn't do a packet filter because I am on a small home grown network but I did play around and found what I wanted and more.  

Below is my setup for a quick logging setup to see what is passing through the firewall

jmctsm@srx05# show security flow    

traceoptions {

    file flow_log size 1m files 100;

    flag basic-datapath;

}

That way all I had to do was run a show log flow_log to see what was passing.  That showed me what I wanted to see and more.  That BGP to my device didn't work as I wanted it not to but BGP from the device to an outside device did work.  

And on to other things.

Firewall Filters vs Host Inbound Services vs Junos-Host Zone

 So many ways to block traffic with Juniper SRX.  So you can either do a firewall filter (think ACL), allow or deny a service on host-inbound, and also control it via the junos-host zone.  Time to see how they all play together.

Based on this topology I have the CORE and the SRX05 doing BGP with each other.  I have both ge-0/0/0 and ge-0/0/1 in security zone UNTRUST.  Actually before I mention that, let's not forget that if an interface is not in a security zone, it is in the NULL zone and that means it accepts nothing.  It does nothing.  It just sits there and tells things to go away.

I started out with allowing only specific traffic in on my zone and then said I am testing to screw it.  

jmctsm@srx05# show security zones security-zone UNTRUST 
host-inbound-traffic {
    system-services {
        ping;
        all;
    }
    protocols {
        bgp;
        all;
    }
}
interfaces {
    ge-0/0/0.0;
    ge-0/0/1.0;
}

That allowed BGP to come up on both sides (skipping BGP configuration).  So that worked.  But what happens if I put a filter in place.  Hmmmm

jmctsm@srx05# show firewall 

filter INCOMING_UNTRUST {

    term DENY_BGP {

        from {

            protocol tcp;

            port bgp;

        }

        then {

            reject;

        }

    }

    term ALLOW_ALL {

        then accept;

    }

}

jmctsm@srx05# show interfaces ge-0/0/0    

unit 0 {

    family inet {

        filter {

            input INCOMING_UNTRUST;

        }

        address 172.16.5.5/24;

    }

}

[edit]

jmctsm@srx05# run show bgp summary 

Threading mode: BGP I/O

Default eBGP mode: advertise - accept, receive - accept

Groups: 1 Peers: 2 Down peers: 1

Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending

inet.0               

                       0          0          0          0          0          0

Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...

172.16.5.1            65000          0          0       0       3       26:56 Connect

172.16.55.1           65000         62         61       0       2       26:53 Establ

  inet.0: 0/0/0/0

So a firewall filter blocked my BGP.  So that tells me it is 

firewall filter -> host-inbound 

So now let's play with the junos-host zone.  I created a policy of 

from-zone UNTRUST to-zone junos-host {

    policy DENY_BGP {

        match {

            source-address any;

            destination-address any;

            application junos-bgp;

        }

        then {

            deny;

        }

    }

    policy ALLOW_ALL {

        match {

            source-address any;

            destination-address any;

            application any;

        }

        then {

            permit;

        }

    }

}

default-policy {

    deny-all;                           

}

That did nothing.  BGP still formed for my 55.1 neighbor.  So what happens if I remove the host-inbound services?  Nothing changed yet again.  The BGP session still came back up.   So starting over from scratch I then removed the interface from the UNTRUST zone and now BGP drops.  Time to figure this out more.

So even with no host-inbound and no junos-host security policy, BGP still forms to the neighbor on the UNTRUST interface.  Just freaking weird. 

And I think that I found my issue.  BGP is allowed to connect no matter if I have host-inbound-traffic on or not or allowed in a policy for junos-host.  

So let's try something easier.  Ping.  Without a host-inbound policy I cannot ping. Easy enough.  But let's allow that there and deny it on the junos-host policy and see what happens.

[edit security policies from-zone UNTRUST to-zone junos-host]

jmctsm@srx05# show 

policy DENY_BGP {

    match {

        source-address BGP_PEER_05;

        destination-address any;

        application junos-bgp;

    }

    then {

        deny;

    }

}

policy DENY_PING_FROM_5_1 {

    match {

        source-address BGP_PEER_05;

        destination-address any;

        application junos-ping;

    }

    then {

        deny;

    }

}

policy ALLOW_ALL {

    match {

        source-address any;

        destination-address any;        

        application any;

    }

    then {

        permit;

    }

}

That blocks traffic from 172.16.5.1 as expected.  So again this is good to find out that apparently some traffic is allowed through always and some can be denied.  Interesting.

Also even if the policy is there for zone junos-host but no host-inbound-traffic, the traffic can be denied.

So what we have is a firewall filter will block before any policies then if no junos-host zone is used and only host-inbound-traffic, all things allowed by host-inbound-traffic can come into the firewall.  To be specific you can use either a firewall filter (which has to be applied at all possible interfaces) or use the junos-host zone.  

Fun time with SRX. 

UPDATE:

I figured out finally why BGP would still come up from a neighbor even if BGP is not allowed via junos-host zone or host-inbound-traffic.  BGP is a TCP server client protocol that either side can initiate from.  Looking at the logs, when the CORE device tries to initiate to the SRX, the SRX denies the traffic.  BUT if the SRX initiates the traffic to the CORE it works.  The policy is not blocking that by any outside method and since the SRX is stateful it allows all communications back in from the "server".

To SRX from CORE = BAD

From SRX to CORE = Established

 

My Path to JNCIE-SEC

On Friday (11 Oct 2024), I passed my JCNIP-SEC.  That was 13 Juniper certifications in less than 12 months.  I have done in no particular order.

JNCIA-JUNOS/DEVOPS/DC/SEC/MISTAI

JNCIS-ENT/SP/DC/SEC/DEVOPS

JNCIP-ENT/DC/SEC

I started down the path of Juniper certifications because I wanted to do something new.  I wanted to try and learn something else beside Cisco.  I didn't know where to start so I started with JNCIA-JUNOS.  I used the Open Learning and Eve-NG to watch the videos and then get hands-on with what I was seeing.  I fell in love with the command line syntax of Juniper and their way of displaying the configurations.  That lead to following the path of more free learning to see what parts I like of Juniper. 

After I started to get some Juniper under my belt my company reached out to see about doing certain tests for partner requirements, so I did things like DC and Devops (wasn't going to do them but they paid so away I go to learn).  I also did JNCIS-SEC for that reason.  That brought back my love of security.  So I figured then that is where I want to go for my JNCIE.  But first I had some other personal goals like the 5A-3S-1P and 5S Credly badges because I wanted them.

Security for me has always been fun because there is always someone out there smarter than you so it keeps you having to learn.  It means you have to keep pushing to know what is happening.  Learn the new bad techniques and the new good techniques.  So I said heck with it and did the JNCIP-SEC, got my 3P along the way as well, and said time for the JNCIE-SEC.

Having a CCIE I know that there is more than hands on for an Expert level test.  There is understanding other ways of doing things, what happens if I do something over here, and the understanding of what in the crap is going on behind the scenes.  Those pieces are what made me miss my first attempts at my CCIE and once I had them down I was more prepared and could pass.  So for this Expert level test I have a reading list already planned that will grow and grow I am sure.  I am starting with 

Juniper SRX Series: A Comprehensive Guide to Security Services on the SRX Series

Juniper Day One: SRX Series Up and Running with Advanced Security Services

SRX Getting Started - Configuration Examples & Troubleshooting (JumpStation)

The Unofficial JNCIE-ENT Prep Guide 

The last one I know is for JNCIE-ENT but Jeff has some really good info in it for configurations so I am going to read through it.  Combine these four things with all the docs that I can get my hands on from Juniper and any blog posts as well, I am hoping to go into this with as much as I can from more than just configuration but theory.  We will see what happens.  

For the hands on I have an Eve-NG lab that I use as well as the Study Bundle from Juniper.  I also signed up for some classes from them for ATP and just other pieces again to make sure that I cover all that I can.  I am expecting this test to be rough.  My goal is 6 to 8 months that I sit for it but we will see.  

I am using this blog as nothing more than a note place for me.  It may or may not have pretty pictures.  It will be more on my thoughts of what I learned that day more than likely so probably incoherent.  But we will see what comes from it.  

NetSkope Fun

 Well not exactly JNCIE related but still a pain to talk about. 

My company uses NetSkope and while I am not a fan of it because of personal reasons I am learning to live with it.  Today though was a fun time.  I have a virtual Ubuntu machine that I was going to use for dev stuff in AWS.  And because I was NAT'ing from the virtual machine to the internet NetSkope threw a nice little hissy fit.  After working with help desk for an hour we found the issue.  

So let's start local.  My physical machine.  The error was 

SSL validation failed for https://ec2.us-east-2.amazonaws.com/ [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1006)

Which was the same error on my linux box.  To fix this I had to run an AWS command to point to the correct CA even if it was trusted already on the computer.

aws configure set default.ca_bundle “C:\ProgramData\Netskope\STAgent\data\nscacert_combined.pem"

And voila.  Fixed the issues on Windows.

For Linux I had to get the root CA cert used for NetSkope and my company and append it to the aws cert file

cat rootca.pem >> ~/aws/dist/aws-cli/awscli/botocore/cacert.pem

Then I had to create an environment variable and put that in my .bashrc file

export AWS_CA_BUNDLE=/path/to/ca-cert/cacert.pem

And again a voila moment.  But one last thing.  Firefox didn't like that and didn't like that I added it to the trust store of the actual system so I had to import that manually.  But now all works and I am good.  Things work great when you have great tech support.  

Time to Start Back

 Well the time has come to start back with blogging what I learn.  I am starting on the journey of my JNCIE and that will be either ENT or DC.  I have been working on learning Juniper for the past 8 months or so and have done all the free training that I can from them. Now I have to really buckle down.  I have to put my money where my mouth is.

Overall the path to where I am now (JNCIA-JUNOS/DC/DEVOPS/SEC, JNCIS-ENT/SP, JNCIP-ENT) hasn't been that bad.  I am studying right now for the JNCIP-DC (let's see how that goes next week) and that has the most new stuff for me.  Having a strong route/switch background from Cisco helped to prepare me with really only learning the nuances of how to program their devices.

Now on to the fun stuff. I know that no matter the path, I have to learn and make sure that I have routing protocols down like a champ.  That is where I will start.  I won't be writing every day.  I will try every week though to talk about some new thing that I did that week in a protocol.  

To do this I will be using EVE-NG Pro with vMX, vEX, and vQFX images. I have also loaded Apstra and Junos Space on their so that I can do either way on that one.  

This is just my way of making sure that I hold myself accountable to all my studying.