VPNs

Background: I'm a Netscreen ScreenOS administrator and I'm coming to grips with JunOS. These are my notes on VPNs.

A Note About Naming And Commands

JunOS is smart, in that you can have objects of different types, and JunOS will use the correct object based on the context of the request. So you can have a gateway, phase-1 policy, phase-2 policy, and vpn all named "MyVPN" (or even "FOO") and JunOS will use the correct one in context.

However I prefer to give things explicit type names because I look at this infrequently and it makes things easier to find definitions with vi if you properly name everything.

Also, the ScreenOS-to-JunOS translator thing inconsistently uses underscores and dashes to separate words in object labels. Dashes seem to always work (and frankly are easier to type). Not sure what the rules are. Beware.

Regarding the commands presented here, I listed the entire from-root set commands rather than show the edit commands that would save a bunch of typing. I do this for two reasons:

• doing so this way makes it absolutely clear what command is for what; and
• this is how I did it in my notes, which I'm basically transcribing here.

Rough Guide To VPNs On JunOS

The main thing to remember here is: you can define every individual parameter involved. The follow-through from this is: you MUST define every individual parameter. There are a few convenience macros, but they are much fewer than the ScreenOS ones.

So a basic VPN looks like this, a connection of a gateway and a phase-2 policy:

set security ipsec vpn MyVPN ike gateway MyVPNGateway
set security ipsec vpn MyVPN ike ipsec-policy MyVPN-Phase2-Policy

If you want a Proxy-ID, you do it at the VPN:

set security ipsec vpn MyVPN proxy-identity local 192.168.0.0/24
set security ipsec vpn MyVPN proxy-identity remote 10.0.10.0/24
set security ipsec vpn MyVPN proxy-identity service any

Notes about Proxy-ID:

• the local and remote values are IP networks, not address book objects
• you can only have one ProxyID per VPN

• you probably have to forget about using Proxy-IDs and use policy-based VPNs instead as those set up the requisite phase-2 tunnels per policy; or
• you can update to 12.1XX46-D30 or higher and use the traffic-selector functionality -- however A) as of today's writing is not a recommended firmware version and B) traffic-selectors cannot discriminate services, the any is implied and doesn't appear to be over-ridable.

set security ipsec policy MyVPN-Phase2-Policy proposal-set standard

You can use one of the canned options of

• standard
• compatible
• basic

A custom Phase-2 proposal defines your protocol, authentication, and encryption rules, and looks like this:

set security ipsec proposal MyProposal protocol esp
set security ipsec proposal MyProposal authentication-algorithm hmac-sha1-96
set security ipsec proposal MyProposal encryption-algorithm aes-128-cbc

This would be the equivalent of ScreenOS's pre-defined nopfs-esp-aes128-sha. It would be included in the Phase-2 definition like this:

set security ipsec policy ATL-HQ-phase2-policy proposals MyProposal
set security ipsec policy ATL-HQ-phase2-policy proposals MyOtherProposal

Custom Phase-2 lists can NOT co-exist with one of the canned options.

If you want to do perfect forward secrecy, you do it at the policy level:

set security ipsec proposal esp-3des-sha protocol esp
set security ipsec proposal esp-3des-sha authentication-algorithm hmac-sha1-96
set security ipsec proposal esp-3des-sha encryption-algorithm 3des-cbc
set security ipsec policy g2-esp-3des-sha perfect-forward-secrecy keys group2
set security ipsec policy g2-esp-3des-sha proposals esp-3des-sha

This is the equivalent of ScreenOS's g2-esp-3des-sha phase 2 proposal. Note that creating policies like this only really works if you only have a single proposal for the remote side. If you need more than one proposal for a remote side you are going to be creating per-site custom policies to contain them.

If you do have a lot of VPNs that use the canned phase-2 proposal types, I think it does make sense to create corresponding policies:

set security ipsec policy basic proposal-set basic
set security ipsec policy compatible proposal-set compatible
set security ipsec policy standard proposal-set standard

A gateway is an association of:

• a Phase-1 policy
• the IP address or other unique identifier of the remote gateway
• the outgoing interface to bind the local connection to
• other options as required.

set security ike gateway MyVPNGateway ike-policy MyVPN-Phase1-Policy
set security ike gateway MyVPNGateway address 0.0.0.0
set security ike gateway MyVPNGateway external-interface reth2.0
set security ike gateway MyVPNGateway local-identity user-at-hostname "someuser@someplace"
set security ike gateway MyVPNGateway no-nat-traversal

A Phase-1 policy is a list of parameters required to set up the phase 1 connection, including:

• the mode (main or aggressive)
• a list of acceptable proposals (or one of the canned options)
• the authentication information, ie pre-shared key or certificate information

set security ike policy MyVPN-Phase1-Policy mode agg
set security ike policy MyVPN-Phase1-Policy proposal-set compatible
set security ike policy MyVPN-Phase1-Policy pre-shared-key ascii-text SampleSecretText

A custom Phase-1 proposal is defined as so:

set security ike proposal MyPhase1Proposal authentication-method pre-shared-keys
set security ike proposal MyPhase1Proposal dh-group group2
set security ike proposal MyPhase1Proposal authentication-algorithm sha1
set security ike proposal MyPhase1Proposal encryption-algorithm aes-128-cbc

...and gets included in the Phase-1 policy as so:

set security ike policy MyVPN-Phase1-Policy proposals MyPhase1Proposal

There are two ways to proceed from here. Either you need to set up a pair of tunneling policies associated with your VPN, or you have to set up a secure tunnel interface and use route-based VPNs (probably with some policies as well).

Policy Based Tunneling

You have to have two policies, one for inbound traffic, one for outbound traffic. These must match the policies on the other end of the VPNs, or the Phase-2 will tell you that the SAs (Security Associations, I think) don't match.

set security policies from-zone trust to-zone untrust policy MyVPNOutbound match source-address MyLocalSubnet
set security policies from-zone trust to-zone untrust policy MyVPNOutbound match destination-address RemoteSubnet
set security policies from-zone trust to-zone untrust policy MyVPNOutbound match application any
set security policies from-zone trust to-zone untrust policy MyVPNOutbound then permit tunnel ipsec-vpn MyVPN
set security policies from-zone trust to-zone untrust policy MyVPNOutbound then permit tunnel pair-policy MyVPNInbound
set security policies from-zone untrust to-zone trust policy MyVPNInbound match source-address RemoteSubnet
set security policies from-zone untrust to-zone trust policy MyVPNInbound match destination-address MyLocalSubnet
set security policies from-zone untrust to-zone trust policy MyVPNInbound match application any
set security policies from-zone untrust to-zone trust policy MyVPNInbound then permit tunnel ipsec-vpn MyVPN
set security policies from-zone untrust to-zone trust policy MyVPNInbound then permit tunnel pair-policy MyVPNOutbound

Now the important thing to know here is: in match statements, you can only use objects. You will see definitions like this:

set security policies from-zone untrust to-zone trust policy MyVPNInbound match source-address 192.168.0.0/24

...but in order for this to work, you have to set up an address book entry in the appropriate security zone first:

set security zones security-zone untrust address-book address 192.168.0.0/24 192.168.0.0/24

...and yes, this leads to the possibility that the object listed isn't what it appears, ie it is perfectly legal to define:

set security zones security-zone untrust address-book address 192.168.0.0/24 10.0.0.0/8

You should also know that JunOS is strict about network object definitions. The defined network has to be defined with the network base. So for example, this isn't valid:

set security zones security-zone untrust address-book address 192.168.3.45/22 192.168.3.45/22

...you have to define it like so:

set security zones security-zone untrust address-book address 192.168.3.45/22 192.168.0.0/22

Again, note you can set the object label to anything you want. So you can keep the ScreenOS-friendly name, but apply the JunOS-required strictness.

Tunnel Based Tunneling (...erm… aka Route-Based VPNs)

Tunnel-based VPNs use the Secure Tunnel (st) interface. The st interface does not show up in my J-Web, but you can define it anyways.

There is only one st interface, st0. You define units (sub-interfaces) as explicit tunnel instances, then bind your VPN to the appropriate unit.

So first you need your interface defined, and in the correct zone:

set interfaces st0 unit 3 family inet
set security zones security-zone untrust interfaces st0.3

The JTAC tells me that the interface doesn't require an IP address (a state ScreenOS interfaces call being unnumbered). If you do want to use IPs instead of interface names in your routes, you'll need to apply an IP address to the interface (and of course you'll need to apply an IP address to the other end, too):

set interfaces st0 unit 3 family inet address 192.168.254.1/30

You need to bind the VPN to the correct unit:

set security ipsec vpn MyVPN bind-interface st0.3

You need a routing statement to tell the firewall when to use the tunnel:

set routing-options static route 192.168.0.0/24 next-hop st0.3

...and finally you need the appropriate inter-zone policies to permit the traffic if you don't have explict permission (ie through a trust to untrust any/any/any permit).

Putting It All Together

So I presented this upside-down to you in terms of how you'd actually configure it. Either you have to type this all in, correctly, in one go before you commit, or you have to do it in a different order.

I like to write small pieces and then commit after each section to ensure the section is correct. I do this because JunOS will frequently let you type anything as an object name, even if the object doesn't already exist, because as long as you get around to defining that object before the next commit you're all good.

So I do my VPNs like this:

• phase 1 proposal (if necessary) and commit
• phase 1 policy and commit
• gateway and commit
• phase 2 policy and commit
• tunnel interface (if necessary) and commit
• vpn and commit
• routes and policies and commit