Basic IPsec tunnel on Juniper’s SRX

juniperThis article is a first part of a mini-series about the Juniper’s branch router-firewalls – the SRXes. I will start with an simple example of how to build a simple VPN between two branch routers later I will do a cisco-to juniper VPN scenario and the last article will be comparing real vs. the advertised throughput.

The example I am using here is done on vSRX (also known as firefly) and ranze of physical SRX from 110 to SRX550. The configurations are virtually the same as the syntax doesn’t differ between the platforms.

Topology used for this is as follows:

SRX_IPsec_topology

As you can see it is simple topology with two hosts two edge routers and one ISP router that is there just to make sure the tunnels actually traverse some network rather then being directly connected as that makes troubleshooting much easier.

The IP plan for this lab is as follows:

Router Interface IP/network
R1 ge-0/0/0.0 2.0.0.0/31
R1 ge-0/0/3.0 192.168.0.254/24
R1 st0.0 10.0.0.1/30
R2 ge-0/0/0.0 3.0.0.0/31
R2 ge-0/0/3.0 192.168.1.254/24
R2 st0.0 10.0.0.2/30
PC-A ge-0/0/0 192.168.0.1/24
PC-B ge-0/0/0 192.168.1.1/24
ISP ge-0/0/0.0 2.0.0.1/31
ISP ge-0/0/1.0 3.0.0.1/31

 The addressing is using 2.0.0.0/31 and 3.0.0.0/31 as public IP addresses the 10.0.0.0/30 are for the tunnel interfaces and the 192.168.0.0/24 and 192.168.1.0/24 are used for the LAN segments.

Now when all addressing is done we should start writing for phase 1 of IPsec which is the key exchange. The IKE configuration consists of 3 main parts and I will try to explain briefly what the configuration of each means in real terms.

Phase 1

In phase one the Internet Key Exchange protocol is used to securely figure out what is the key that will be used in further communication. As always phase 1 consists of 3 main components – proposal, policy and gateway. These three components could be roughly described as attributes,methods and peer’s details. See below for more details.

a) IKE proposal

The proposal is a list of attributes that IKE will use for the key exchange. It has multiple components but we’ll use the minimal set of three attributes which is enough to get our key exchange running.

  • Authentication method could be either password (pre-shared key) or digital signature RSA/DSA
  • DH group – determines algorithm for the secure key exchange over unsecured network (diffie hellman) and the number of keys it can use (in effect its strength) group 2 is 1024 bits
  • Authentication algorithm is a hashing method the DH will use

security {
    ike {
        proposal ike_prop {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
        }
}

b) IKE policy

The policy takes the attributes from the proposal and binds them with methods of your choosing. In this case the policy has just 2 more parts.

  • mode -aggressive/main – the aggressive mode is 4 packets long exchange and is sometimes considered more secure (less packets – less exposure) but there are known attacks on aggressive mode so using the main mode is generally a good thing – it also helps with the compatibility between vendors.
  • pre-shared-key/certificate – this is the secret that will be used for the Key exchange and must match on both ends of the tunnel.
security {
    ike {
        policy ike_pol {
            mode main;
            proposals ike_prop;
            pre-shared-key ascii-text "$9$jJiPQ/9pBRStu"; ## SECRET-DATA
        }
    }
}

 

c) IKE gateway

The IKE gateway defines identities of local and remote peers. It also refers to the IKE policy and binds the IKE chain/cascade together. There is couple additional identifiers used in this example (remote/local identity, local address) but they are optional – even though I would recommend using them or their alternatives.

  • address – is the remote peer’s public IP
  • external interface – is the local physical public interface
security {
    ike {
        gateway rt02 {
            ike-policy ike_pol;
            address 3.0.0.0;
            local-identity user-at-hostname "tnk@rt01";
            remote-identity user-at-hostname "tnk@rt02";
            external-interface ge-0/0/0;
            local-address 2.0.0.0;
        }
    }
}

Phase 2

Once the key exchange is finished phase 2 can begin. It is the IPSec itself and it also consists of 3 components. They are similar both in name and purpose.

a) IPsec Proposal

Again this is defining the methods the IPsec framework will actually use for encryption.

  • protocol ESP – this is the more secure of the two options (AH/ESP) and should be used all the time some recommendation ask for using AH+ESP but I am not sure that is possible in reasonable way
  • Authentication algorithm – select the algorithm for IPsec authentication
  • Encryption algorithm – select the strength of the cypher used for the packet encryption – be careful here as this setting heavily impacts performance. One should always avoid DES/3DES as they are weak cyphers. But also avoid a high-end AES as the impact might be rather severe. In general AES256 is considered strong enough while being reasonably easy to calculate.

security{
    ipsec {
        proposal ipsec_prop {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
        }
    }
}

b) IPsec Policy

In the policy the IPsec proposal is bound in and the PFS is defined. PFS is a security mechanism that does key-renegotiation after the key life-time expires. This is best practise and shouldn’t have major impact on packet processing.

security{
    ipsec {
        policy ipsec_pol {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipsec_prop;
        }
    }
}

c) IPsec VPN

This is the last piece of the tunnel puzzle where the IKE and IPsec are bound together into one “VPN”. It also binds in the secure tunnel interface into this whole lot. The one interesting parameters is the “establish tunnels immediately” which is very helpful for debugging as it will be sending the IKE/IPsec packets to peers even without valid traffic causing them to establish before the first packet destined fort he remote network will arrive.


security{
    ipsec {
        vpn vpn_rt02 {
            bind-interface st0.0;
            ike {
                gateway rt02;
                ipsec-policy ipsec_pol;
            }
            establish-tunnels immediately;
        }
    }
}

And because the SRX is in the flow mode a security zones and accompanying security policy must be defined for the tunnels to form. First I’ll define the zones themselves – for simplicity it will be only 2 zones. In the follow up examples this policy will be changed to reflect the use of the junos-host zone.

Zone name Description
z_trust trusted internal network
z_internet untrusted public network

We’ll allocate the correct interfaces in the right zones (note the st0.0 is in the z_trust) and permit the ike and icmp/ping to be accepted from the untrusted zone for processing by the Routing Engine.


security-zone z_trust {
    host-inbound-traffic {
        system-services {
            ping;
        }
    }
    interfaces {
        ge-0/0/3.0;
        st0.0;
    }
}
security-zone z_internet {
    interfaces {
        ge-0/0/0.0 {
            host-inbound-traffic {
                system-services {
                    ping;
                    ike;
                }
            }
        }
    }
}

All traffic is allowed inside the trusted zone. This needs to be done if you have any IP traffic between your hosts passing through the SRX – it is not strictly speaking necessary for the example but it is a good thing to have in mind.


from-zone z_trust to-zone z_trust {
    policy implicit_permit {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

This policy is a clean-up – deny all traffic from public zones to private.


from-zone z_internet to-zone z_trust {
    policy deny_all {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}

So here we have a simple set-up for RT01 from our topology. In coming articles I will modify this config to be more suitable for faster deployments (using groups and objects) and in the end there will be couple hints on how to troubleshoot IPsec on SRXes as that topic is severely under-described.

Leave a Reply

Your email address will not be published. Required fields are marked *