Thursday, 7 July 2011

JUNOS Pulse Gateway - MAG2600

I get to work with most of the Juniper security range and I feel one of the best bits of kit they have is the SSL VPN boxes.

Recently Juniper have brought out the JUNOS Pulse Gateway MAG series devices, at first I was unsure whether these were a replacement for the Juniper SA range or not. Additionally it is not easy to find any Juniper documentation that states that they do the same job.

Juniper do state that the MAG devices are SSL VPN boxes and the 2600 series for example (as it is on my desk) can sustain 100 concurrent users. As well as the SSL VPN function they can also be converted to perform NAC services but that is another discussion. The bottom line was that I needed to know whether it could perform all the other funky features such as secure meeting, virtual desktops, folder redirection, host checking etc. that were available on the SA boxes and which my clients love so much. I was aware that the MAG Series still uses IVE but needed to be certain that they could perform all the same tasks.

That being the case I was able to get a box on eval to play with.

For anyone that has used the SA boxes before then the principle is still the same. You console onto the box, set the networking, certificate and credentials. Then browse to the box via IP and login via the /admin page.

As you can see from the screenshots the WebUI is still exactly the same and the functionality is also still the same.

Thursday, 30 June 2011

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

Tuesday, 28 June 2011

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

Monday, 27 June 2011

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