SRX ADSL

Here is a couple of SRX ADSL configs to 2 different ISPs.
Both these configs have been tested to actually work.

1) Telstra  - PPPOA

    at-1/0/0 {
        mtu 1540;
        encapsulation atm-pvc;
        atm-options {
            vpi 8;
        }
        dsl-options {
            operating-mode auto;
        }
        unit 0 {
            encapsulation atm-ppp-vc-mux;
            vci 8.35;
            ppp-options {
                chap {
                    default-chap-secret "$9$78fgoJGD.fT3JtuBIcS"; ## SECRET-DATA
                    local-name "yourname@direct.telstra.net";
                    passive;
                }
            }
            family inet {
                negotiate-address;
            }
        }
    }

routing-options {
    static {
        route 0.0.0.0/0 next-hop at-1/0/0.0

2) Netspace - PPPOE

at-1/0/0 {
        mtu 1492;
        encapsulation ethernet-over-atm;
        atm-options {
            vpi 8;
        }
        dsl-options {
            operating-mode auto;
        }
        unit 0 {
            encapsulation ppp-over-ether-over-atm-llc;
            vci 8.35;
        }
    }
    pp0 {
        unit 0 {
            point-to-point;
            ppp-options {
                pap {
                    default-password "$9$CYEtAOwKvLXNdpqvLx92g5Qz"; ## SECRET-DATA
                    local-name "yourname@netspace.net.au";
                    local-password "$9$vMwMxdoraUDHq7XaUjhTQRhc"; ## SECRET-DATA
                    passive;
                }
            }
            pppoe-options {
                underlying-interface at-1/0/0.0;
                idle-timeout 0;
                auto-reconnect 2;
                client;
            }
            family inet {
                negotiate-address;
            }
        }
    }

routing-options {
    static {
        route 0.0.0.0/0 next-hop pp0.0

SRX UTM: Web Filtering (Enhanced Web Filtering)

This summary is not available. Please click here to view the post.

SRX UTM: Web Filtering (Local)

Time to test the UTM Web Filtering feature.

The first thing to know is that there are 4 different ways to do this on the SRX.

1) Surfcontrol - This is know as Integrated Web Filtering and uses a cloud based Surfcontrol server to categorise URLs. This option requires a license and of course you can test with the 30 day trial license. The cloud based Surfcontrol server doesn't permit or deny anything. When queried by the SRX it provides a category that is permitted or denied by the policy you create on the SRX. The URL-to-category site results from the Surfcontrol server are cached locally which means subsequent requests for the same site don't require a lookup on the Surfcontrol server. This is a sensible approach as it means you dont have to download the whole database from Surfcontrol every time you start the SRX - it just requests the info from Surfcontrol on as as needed realtime basis.

Note: Surfcontrol is now owned by Websense though Juniper still name this option as Surfcontrol.

2) Enhanced Web Filtering - This is another type of Integrated solution which uses the Websense ThreatSeeker Cloud (TSC). Similar to Surfcontrol option above it provides a cattergory for the site to be checked but in addition also provides a reputation for the site.
A license is required for this option.

Juniper consider this option "next-generation URL filtering solution, building upon the existing SurfControl solution".

3) Websense - This is known Redirect Web Filtering and uses your local Websense server. This option does not require a licence. The main difference here to the Surfcontrol option is the the Websense server itself, through its own polices is doing the denying or permitting.

4) Local lists. This option uses local black and white lists to permit or deny access to URLs. No license required.

In this post I will configure and test the Local lists 

SRX IDP

This post will show you how to get IDP on an SRX100H going and tested to be working.

I will be using a Trial licence which is valid for 30days.

1) GET AND INSTALL THE IDP LICENSE

a) First make sure you can ping a URL from your SRX as the download process will use name lookups.

blogger@LEFTY> ping www.juniper.net inet

PING e1824.dscb.akamaiedge.net (184.87.23.148): 56 data bytes

64 bytes from 184.87.23.148: icmp_seq=0 ttl=54 time=33.373 ms

64 bytes from 184.87.23.148: icmp_seq=1 ttl=54 time=30.299 ms

64 bytes from 184.87.23.148: icmp_seq=2 ttl=54 time=29.531 ms

^C

--- e1824.dscb.akamaiedge.net ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max/stddev = 29.531/31.068/33.373/1.660 ms

If that doesn’t work, setup name servers in the config.

SRX Traceoptions: Security Flow

Following on from the last post lets quickly see how we go using TCPDUMP with reth interfaces;

Using the same methodology as in my last post...I.e having separate input and output filters and applying those filters on the reth interface, I find that the SRX generates 2 files, one for the reth and one for the (I assume active) physical interface.Eg.

-rw-r--r--  1 root  wheel  1878 Apr 27 18:15 dumptest.fe-0.0.2
-rw-r--r--  1 root  wheel  1298 Apr 27 18:15 dumptest.reth0

Looking at the 2 files we can capture what we want however each file only shows the traffic in one direction. So you need to look at both files to see everything that is going on. For sure not too handy.

At any rate in the Junos release notes (Branch SRX) they state..
                Sampling features like J-FLow, packet capture, and port mirror on the reth interface are not supported.
And thats from 12.1! So its not a limitation that will disappear soon if ever.

If your insistent and put the filters on the physical interface instead of the reth like this ..

fe-0/0/2 {
        fastether-options {
            redundant-parent reth0;
        }
        unit 0 {
            family inet {
                filter {
                    input INGRESS-TCPDUMP;
                    output EGRESS-TCPDUMP;
                }
            }
        }
   }

Well your out of luck there as that will again only show the one direction. Not recommended!

So Is there another way to see whats going on at a very raw level on the firewall?

Yup..Hello traceoptions.

Logging Policy and TCPDUMP (SRX)

How can we know if our policies are being hit or if traffic is getting to the firewall?

* SETUP

The policy in question for all the below work is just the default trust to untrust policy on the SRX. The source IP on trust is 192.168.56.50 and the destination on IP on untrust is 172.20.123.2

blogger@LEFTY> show configuration security policies from-zone trust to-zone untrust
policy trust-to-untrust {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

* LOGGING

First lets look at logging. Lets add logging to the policy. If your going to have logging you must choose session-init or session-close or both. From my perspective session-init is way more useful as if you have very long lasting sessions you may never know that you got a policy hit. Sure you might want to know when a session ends but at the very least you would want to know when and if your policy even got hit so make sure you at least use session-init.

DHCP server (SRX)

Just a quick one today about setting up an SRX as a DHCP server.
First you need to define the DHCP parameters..

                   dhcp {
            router {
                192.168.1.1;
            }
            pool 192.168.1.0/24 {
                address-range low 192.168.1.2 high 192.168.1.254;
                default-lease-time 3600;
                domain-name blogger.net.au;
                name-server {
                    192.168.1.1;
                }
            }
        }

Login timeout (SRX and Olive) - updated

Juniper states that by default there is no idle-timout. That applies for my olive and my SRXs.
Indeed when I do check out the cli parameters on the olive after login I see..

user@olive-core> show cli
CLI complete-on-space set to on
CLI idle-timeout disabled
CLI restart-on-upgrade set to on
CLI screen-length set to 51
CLI screen-width set to 136
CLI terminal is 'vt100'
CLI is operating in enhanced mode
CLI timestamp disabled
CLI working directory is '/var/home/user'

And indeed I can confirm that my ssh session to olive-core never times out.

That's fine for the lab but in the real world corporate environment not so good. So what do we do to fix that? Define a login class.

NTP

It is very simple to setup NTP. In summary here is the 3 steps.

1) Set the timezone

2) Set the time via CLI to get an immediate update

3) Sync up with an NTP source for persistent time sync.

Below is the steps fleshed out.

Load hierarchical config

You can, if you want, load hierarchical config directly under the edit prompt if you have such a piece of config. For example you just want to copy a section of config you already have working from one device to another or maybe you want to copy a piece of config you have seen.

Here we copy a user definition into another device using the load merge command.
Also note the use of the "relative" keyword as we are not loading at the top of the hierarchy

Logging (Olive - Firewall)

Now we can login to the olive, control the login through a firewall filter and see hits on the filter. But that only gives us a packet and byte count. It doesn't tell us when the counts happened or where they were sourced from. For that we need logging.

An easy way to do this is to use the action "log" on the term..

user@olive-core> show configuration firewall
filter ACCESS-CNTRL {
    term TELNET-BLOCK {
        from {
            destination-port telnet;
        }
        then {
            count COUNTER-TELNET-BLOCK;
            log;
            discard;
        }
    }
    term PERMIT-ALL {
        from {
            source-address {
                0.0.0.0/0;
            }
        }
        then {
            count COUNTER-PERMIT-ALL;
            accept;
        }
    }
}

To see the log..(And there must be hits against the term to see the kind of output below)

Access (Olive)

All you need to access the device, an Olive on VirtualBox in this case, is this config.

system {
      services {
        ssh;
        telnet;
    }

This config would allow ssh and telnet access to all interfaces.
Note: Root will not authenticate with telnet.

Now suppose you would like to block access on one or more interfaces.
You need a firewall filter.