SRX IPv6 Basic Config

This post is about IPv6 and how the basics of it are really simple and not something anyone should be getting worried about.

For the purposes of this example I am configuring an IPv6 network between one of my PC NICs and the SRX interface fe-0/0/1. As this is considered a private network I will be following RFC4193.

I am using the website http://www.sixxs.net/tools/grh/ula/ in order to generate an IPv6 Unique Local Address (ULA)

The assigned IPv6 address space I will be using is fd13:17d7:1ad6::/48

I will be using fd13:17d7:1ad6::1/48 for my local PC and fd13:17d7:1ad6::2/48 for the SRX. As my test PC is running Windows XP I had to start by installing the IPv6 stack and then configure my NIC using Netsh:
netsh interface ipv6>add address "Local Area Connection" fd13:17d7:1ad6::1
netsh interface ipv6>add route fd13:17d7:1ad6::/48 "Local Area Connection"

We now need to configure the SRX. As mentioned the configuration is on the fe-0/0/1 interface
root@host# set interfaces fe-0/0/1 unit 0 family inet6 address fd13:17d7:1ad6::2/48

At this point I have set up the addressing correctly however I will not be able to ping the SRX from my test PC as by default the SRX series or J series devices drops IPv6 traffic. To enable processing of IPv6 via zones, screens and policies I must enable flow-based forwarding for IPv6 traffic.
root@host# set security forwarding-options family inet6 mode packet-based

Once done I can confirm connectivity

JUNIPER NETWORKS ACHIEVES INDUSTRY'S FIRST CERTIFICATION FOR UK GOVERNMENT PUBLIC SERVICES NETWORK ENCRYPTION

Great news for the Juniper SRX range

Juniper Certificate Details

SRX Static NAT - One to One

Here is a simple example of a static one to one NAT. My goal is to access the host machine from the Internet on 15.243.192.104/32 via RDP (TCP 3389)

As RDP is still not a pre-defined application/service on Juniper devices so we have to configure it

root@host# set applications application RDP_TCP_3389 protocol tcp destination-port 3389

We now need to configure the Proxy-Arp address that we will be using for the forwards

root@host# set security nat proxy-arp interface fe-0/0/0 address 15.243.192.104/32

We now need to create the Static NAT policy Incoming_NAT01 and bind a rule to it Incoming_Rule1, which is where the translation occurs.

root@host# set security nat static rule-set Incoming_NAT01 from zone Untrust_Zone

root@host# set security nat static rule-set Incoming_NAT01 rule Incoming_Rule1 match destination-address 15.243.192.104/32

root@host# set security nat static rule-set Incoming_NAT01 rule Incoming_Rule1 then static-nat prefix 172.16.201.3 routing-instance Trust-VR

Before we create the policy we will need to define the end host

root@host# set security zones security-zone Trust_Zone address-book address LAB_HOST_01 172.16.201.3/32

Finally we create the Security Policy Incoming_POL01 that will actually let the traffic through the SRX, remembering as always to enable logging and counting

root@host# set security policies from-zone Untrust_Zone to-zone Trust_Zone policy Incoming_POL01 match source-address any destination-address LAB_HOST_01 application RDP_TCP_3389

root@host# set security policies from-zone Untrust_Zone to-zone Trust_Zone policy Incoming_POL01 then permit

root@host# set security policies from-zone Untrust_Zone to-zone Trust_Zone policy Incoming_POL01 then log session-init

root@host# set security policies from-zone Untrust_Zone to-zone Trust_Zone policy Incoming_POL01 then log session-close

root@host# set security policies from-zone Untrust_Zone to-zone Trust_Zone policy Incoming_POL01 then count

SRX Route Based VPN - Proxy IDs

By default when you create an IPSEC tunnel on an SRX the Proxy IDs are set to 0.0.0.0/0. There are a number of occasions when you will have a need to explicitly define the proxy IDs, the first is for an additional layer of security so both sides need another authentication method before they establish. The second would be when you need to establish a VPN to non Juniper devices such as Cisco, Sonicwall or Checkpoint and the interesting traffic coming from the other side needs to match on the Proxy ID. There are other reasons however I see these as the more important in my environments.

The Config

In our example I am establishing a VPN with a Juniper SSG so in theory you can put anything in the Proxy IDs as long as both sides match. This is different when establishing with Cisco's or other vendors as they need to actually match the traffic being sent over the tunnel.

So in our example we are have a remote IP range of 10.10.11.0/24 and a local range of 172.16.201.0/24. However we are performing subnet overlap on the tunnel so to keep it in tune we are considering our local range of 192.222.222.0/24. That being the case the following code is used:

root@host# set security ipsec vpn LAB_VPN_01 ike proxy-identity local 192.222.222.0/24
root@host# set security ipsec vpn LAB_VPN_01 ike proxy-identity remote 10.10.11.0/24

Best Practices for High Availability Deployments using IPS, SRX and AppSecure

Live Webcast - July 13 Junos Security experts and authors present "Best Practices for High Availability Deployments using IPS, SRX and AppSecure."

Registration Link

SRX Route Based VPN - Overlapping Subnets

I read something recently that stated, 'as a network engineer if you have never had to deal with overlapping or duplicated IP ranges then you may also be the kind of person who wins at slot machines' 

Working for an outsourcing company who require VPN connections to all their clients sees this problem crop up all the time. Where possible a re-addressing of the client network is performed however more often that not a mapped IP range is used.
Using ScreenOS this is simply performed on the conflicting networks firewall by adding a MIP to the tunnel interface and then binding this to the policy.

JUNOS works slightly different but still just as simple. In this example the remote network has the same subnet as our lab 172.16.201.0/24. To enable routing between subnets we are mapping our 172.16.201.0/24 to 192.222.222.0/24. Once completed the remote network will just route 192.222.222.x/24 down the tunnel.

root@host# set security nat static rule-set Overlap_Subnet from zone VPN_Zone
root@host# set security nat static rule-set Overlap_Subnet rule Overlap_Rule1 match destination-address 192.222.222.0/24
root@host# set security nat static rule-set Overlap_Subnet rule Overlap_Rule1 then static-nat prefix routing-instance Trust-VR 172.16.201.0/24

Now this is working we need to consider proxy-ids....

SRX Route Based VPN

To create a route based VPN you require the usual building blocks:

• Tunnel Interface
• Proposals and VPN
• Routing
• Policies

Tunnel Interface and zone

As in ScreenOS I am using an unnumbered tunnel interface, in ScreenOS the tunnel interface will borrow the IP address of the interface it is bound to. In JUNOS this is slightly different, the IP address is borrowed from the security zone it is bound to. This does a raise a question for me as I have not assigned an IP to the Security zone so I am not sure what it is using, anyone?
root@host# set interfaces st0 unit 0 family inet
root@host# set security zones security-zone VPN_Zone
root@host# set security zones security-zone VPN_Zone interfaces st0.0

Additionally in order for incoming IKE connections to be accepted you need to enable IKE on the incoming interface zone, in our case this would be fe-0/0/0.0 which sits in the Untrust_Zone
root@host# set security zones security-zone Untrust_Zone host-inbound-traffic system-services ike

Proposals and VPN

For the purposes of this configuration I am using the SRX 'standard' proposal which is "esp-group2-3des-sha1” and “espgroup2-aes128-sha1”. These first statements basically define the IKE Policy and the Gateway
root@host# set security ike policy LAB_IKE_POL mode main
root@host# set security ike policy LAB_IKE_POL proposal-set standard 
root@host# set security ike policy LAB_IKE_POL pre-shared-key ascii-text "Password123"
root@host# set security ike gateway LAB_GW_POL ike-policy LAB_IKE_POL
root@host# set security ike gateway LAB_GW_POL address 65.9.248.130
root@host# set security ike gateway LAB_GW_POL external-interface fe0/0/0.0

Again I am using the SRX 'standard' proposal for the IPSEC Policy
root@host# set security ipsec policy LAB_VPN_POL proposal-set standard

Finally we bind the Tunnel Interface, Gateway and IKE together to create the VPN
root@host# set security ipsec vpn LAB_VPN_01 bind-interface st0.0
root@host# set security ipsec vpn LAB_VPN_01 ike gateway LAB_GW_POL ipsec-policy LAB_VPN_POL
root@host# set security ipsec vpn LAB_VPN_01 ike ipsec-policy LAB_VPN_POL 


Routing

I am using multiple VRs in my SRX configuration, if you come from a ScreenOS background then you work on the principle that the Tunnel Interface is bound to the VR that the outgoing (Untrust for example) interface is in. This is different in JUNOS and as you can see I have bound the Tunnel (st0.0) to the Trust-VR. JUNOS documentation (see earlier blog on VRs) has stated that a limitation at present, is that Tunnel Interfaces can only be bound to the inet.0 routing instance, as I have effectively created two new routing instances in Trust-VR.inet.0 and Untrust-VR.inet.0 it seems that the tunnel can be bound to another instance however that instance has to have the interface where the traffic over the VPN is destined, in our configuration this will be fe-0/0/1.0
root@host# set routing-instances Trust-VR routing-options static route 10.10.11.0/24 next-hop st0.0
root@host# set routing-instances Trust-VR interface st0.0


Policies

This is simply the configuration of the policies for the VPN
root@host# set security zones security-zone VPN_Zone address-book address LAB_LAN_10.10.11.0/24 10.10.11.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match source-address LAB_LAN_172.16.201.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match destination-address LAB_LAN_10.10.11.0/24
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit match application any
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then permit
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then log session-init
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then log session-close
root@host# set security policies from-zone Trust_Zone to-zone VPN_Zone policy OutboundVPN_Permit then count

root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match source-address LAB_LAN_10.10.11.0/24
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match destination-address LAB_LAN_172.16.201.0/24
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit match application any
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then permit
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then log session-init
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then log session-close
root@host# set security policies from-zone VPN_Zone to-zone Trust_Zone policy InboundVPN_Permit then count


Configure Tcp-mss to Eliminate Fragmentation of TCP Traffic Across Tunnel
root@host# set security flow tcp-mss ipsec-vpn mss 1350
Juniper note:
Tcp-mss is negotiated as part of the TCP 3-way handshake. It limits the maximum size of a TCP segment to better fit the maximum transmission unit (MTU) limits on a network. This is especially important for VPN traffic as the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting Encapsulating Security Payload (ESP) packet to exceed the MTU of the physical interface, thus causing fragmentation. Fragmentation increases bandwidth and device resources and is always best avoided. Note that the value of 1350 is a recommended starting point for most Ethernet-based networks with an MTU of 1500 or greater. This value may need to be altered if any device in the path has lower MTU, or if there is any added overhead such as Point-to-Point Protocol (PPP), Frame Relay, etc. As a general rule, you may need to experiment with different tcp-mss values to obtain optimal performance.

NSS Labs Report - Network Firewall Remediation for TCP Split Handshake

NSS Labs provide expert analysis of security products on an independent level so there is no vendor bias. Many of their reports are a paid for service however they do produce some free reports if you sign up.

NSS Labs - Register

Below is a link to an interesting article regarding a TCP Split Handshake attack on a cross section of security vendors. Interesting to see the particular vendors responses.

Analysis Brief: Network Firewall Remediation for TCP Split Handshake

SRX Management

As mentioned previously I come from a heavy ScreenOS background, anyone who has worked with ScreenOS knows that the WebUI is fantastic and very rarely do you have to jump on to the CLI, unless you need to run debugs etc. That does not mean I don't like the CLI, in fact I believe you should use whatever interface suits the engineer and product.

The SRX WebUI is a lot better since the JUNOS release Q4 2010 however I still find the CLI a lot more intuitive and will give you a better understanding of how JUNOS works.

So far in this blog I have been consoling into the SRX however now we have addressing set-up we can look at enabling SSH and HTTPs.

The default config of an SRX has a system generated certificate so all that you need to do is assign an interface to the web management. For the purpose of this I am using the Trust_Zone interface fe-0/0/1.0

root@host# set system services web-management https interface fe-0/0/1.0

In addition to this you will also need to allow the system services on the security zone, for this example it will be the Trust_Zone

root@host# set security zones security-zone Trust_Zone host-inbound-traffic system-services https
root@host# set security zones security-zone Trust_Zone host-inbound-traffic system-services ssh

Additionally you may want to enable ping to confirm connectivity

root@host# set security zones security-zone Trust_Zone host-inbound-traffic system-services ping

SRX Basic Policies

Now we have a routing and NAT configuration we need to configure some basic policies to allow traffic out.

Before the policies are set we should define some policy address elements

root@host#set security zones security-zone Trust_Zone address-book address LAB_LAN_172.16.201.0/24 172.16.201.0/24

Now the policy element is defined we can create the policies

root@host# set security policies from-zone Trust_Zone to-zone Untrust_Zone policy Outbound_Permit match source-address LAB_LAN_172.16.201.0/24
root@host# set security policies from-zone Trust_Zone to-zone Untrust_Zone policy Outbound_Permit match destination-address any
root@host# set security policies from-zone Trust_Zone to-zone Untrust_Zone policy Outbound_Permit match application any
root@host# set security policies from-zone Trust_Zone to-zone Untrust_Zone policy Outbound_Permit then permit

SRX Source NAT rule between VRs

We now have a basic routing configuration between VRs. The next thing we need to look at is the configuration so hosts can NAT via the VRs.

root@host# set security nat source rule-set Source_NAT from routing-instance Trust-VR
root@host# set security nat source rule-set Source_NAT to routing-instance Untrust-VR
root@host# set security nat source rule-set Source_NAT rule Source_NAT_Rule1 match source-address 172.16.201.0/24 destination-address 0.0.0.0/0
root@host# set security nat source rule-set Source_NAT rule Source_NAT_Rule1 then source-nat interface

Day One: Junos Tips, Techniques, and Templates 2011

What is says on the tin. Very useful!

JUNOS Tips and Techniques

You will need a J-Net account, if you are not a member you can sign up without any commitments. 

SRX Importing Routes Between VRs

In ScreenOS we create routes defining the virtual router as the next hop. Below is an example of pointing the default route to the Untrust-VR where the next hop will be defined.

->set vrouter "Trust-VR"
->set route 0.0.0.0/0 vrouter "Untrust-VR" preference 20 metric 1

JUNOS configuration is similar however we must create a term that imports the Untrust-VR routes into the Trust-VR and then apply it the Trust-VR as below

root@host# set policy-options policy-statement Untrust_to_Trust_Import term Untrust_Route_Import from instance Untrust-VR
root@host# set policy-options policy-statement Untrust_to_Trust_Import term Untrust_Route_Import then accept
root@host# set routing-instances Trust-VR routing-options instance-import Untrust_to_Trust_Import


Finally we need to actually add a route into the Untrust-VR that will be imported into the Trust-VR using the policy above.

root@host#set routing-instances Untrust-VR routing-options static route 0.0.0.0/0 next-hop 15.243.192.65

SRX Virtual Routers (VRs) and Zone Configuration

All my configs are built around custom VRs, Zones, Screens etc. This methodology will be very useful later on when configuring tunnel interfaces in multiple VRs.

Before defining the VRs and Zones we need to address the interfaces:

root@host# set interfaces fe-0/0/0 unit 0 family inet address 15.243.192.103/26
root@host# set interfaces fe-0/0/1 unit 0 family inet address 172.16.201.1/24

I have created two custom VRs and two custom Zones in this example:

Untrust-VR and Trust-VR, 
Untrust_Zone and Trust_zone

Set the Virtual Routers
root@host# set routing-instances Untrust-VR instance-type virtual-router
root@host# set routing-instances Trust-VR instance-type virtual-router

Assign interfaces to VRs
root@host# set routing-instances Untrust-VR interface fe0/0/0.0
root@host# set routing-instances Trust-VR interface fe0/0/1.0

Creating Zones for the VRs
root@host# set security zones security-zone Trust_Zone
root@host# set security zones security-zone Trust_Zone interfaces fe-0/0/1.0
root@host# set security zones security-zone Untrust_Zone
root@host# set security zones security-zone Untrust_Zone interfaces fe-0/0/0.0


Note from Juniper: http://kb.juniper.net/InfoCenter/index?page=content&id=KB16453
Note: Binding interfaces to zones is configured separately from binding interfaces to a virtual router (routing instance). The tasks to create a virtual router in JUNOS Software are slightly different from those in ScreenOS, where you would assign a zone to a virtual router and assign an interface to a zone. 
Keep the following in mind when configuring virtual routers:

• VPN interfaces (st) are currently terminated only in zones that are assigned to inet.0.
• For self-initiated management traffic (for example, system logs and traps), route lookup starts with inet.0.
• Interfaces that are not explicitly members of any custom virtual router are members of inet.0.

Virtual Routers (VRs)

Coming from a ScreenOS background I have always been taught and tried to instil on engineers I work with, the use of mutliple VRs. Where possible and dependant on the hardware, I look to configure VRs for each separate WAN interface and dependant on the requirements of the client I look to split the LAN interfaces as well.


There are many benefits for using multiple VRs:

• creates more secure routing tables that are simpler to administer
• allows you to use overlapping ip subnets or networks
• allows you to run multiple OSPF areas on one device
• is (obviously) more safe when dealing with multiple ISP's and dynamic routing
• allows you to set different protocol preferences per vrouter

SRX Default Config

For the purpose of this blog I will be configuring an SRX100.
When either taking an SRX out of the box or entering the following commands, you will get the Juniper default configuration.


root@host# load factory-default
root@host# set system root-authentication plain-text-password
root@host# commit and-quit
root@host> request system reboot


Personally I prefer to work from a blank canvas, so the following commands removes all Juniper applied config, adds a few tweaks and gives us a starting point to build up our configurations.


Remove the interface Ethernet Switching
root@host# delete interfaces fe-0/0/1 unit 0 family ethernet-switching
"Repeat for interfaces range 1-7"
root@host# delete interfaces vlan unit 0 family inet address 192.168.1.1/24
root@host# delete interfaces vlan unit 0 family inet


Remove the fe0/0/0.0 interface from Security Zone
root@host# delete security zones security-zone untrust interfaces fe-0/0/0.0


Remove the Zone Interfaces and Policies
root@host# delete security zones security-zone trust host-inbound-traffic
root@host# delete security zones security-zone trust interfaces vlan.0


Remove Default Policies
root@host# delete security policies from-zone trust to-zone untrust


Remove Default Web Management
root@host# delete system services web-management http interface vlan.0
root@host# delete system services web-management https interface vlan.0


Remove NAT rule
root@host# delete security nat source rule-set trust-to-untrust


Remove Screening on Untrust Zone
root@host# delete security zones security-zone untrust screen


Remove Existing Name Servers and add Google ones
root@host# delete system name-server 208.67.222.222
root@host# delete system name-server 208.67.220.220
root@host# set system name-server 8.8.8.8
root@host# set system name-server 8.8.4.4
root@host# delete system services dhcp


Remove Default Security Zones
root@host# delete security zones security-zone untrust
root@host# delete security zones security-zone trust

root# run show configuration | display set
set version 11.1R2.3
set system root-authentication encrypted-password "$1$sF9Tjm/m$zu6xvdjAUIqeeHSP69Vfm0"
set system name-server 8.8.8.8
set system name-server 8.8.4.4
set system services ssh
set system services telnet
set system services xnm-clear-text
set system services web-management http
set system services web-management https system-generated-certificate
set system syslog archive size 100k
set system syslog archive files 3
set system syslog user * any emergency
set system syslog file messages any critical
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands error
set system max-configurations-on-flash 5
set system max-configuration-rollbacks 5
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set interfaces fe-0/0/0 unit 0
set interfaces fe-0/0/1 unit 0
set interfaces fe-0/0/2 unit 0
set interfaces fe-0/0/3 unit 0
set interfaces fe-0/0/4 unit 0
set interfaces fe-0/0/5 unit 0
set interfaces fe-0/0/6 unit 0
set interfaces fe-0/0/7 unit 0
set interfaces vlan unit 0
set protocols stp
set security screen ids-option untrust-screen icmp ping-death
set security screen ids-option untrust-screen ip source-route-option
set security screen ids-option untrust-screen ip tear-drop
set security screen ids-option untrust-screen tcp syn-flood alarm-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood attack-threshold 200
set security screen ids-option untrust-screen tcp syn-flood source-threshold 1024
set security screen ids-option untrust-screen tcp syn-flood destination-threshold 2048
set security screen ids-option untrust-screen tcp syn-flood timeout 20
set security screen ids-option untrust-screen tcp land
set security policies
set vlans vlan-trust vlan-id 3
set vlans vlan-trust l3-interface vlan.0