IKE Configuration Overview¶

Enabling IKE
VPN templates
IKE policy templates
IPsec policy templates
Creating a VPN
IKE state
Route-based VPNs through SVTI interfaces
Route-based VPNs through GRE interfaces
- Static GRE interfaces
- Dynamic GRE interfaces

Enabling IKE ¶

IKE is enabled per VRF as follows:

vsr running config# vrf main
vsr running vrf main# ike
vsr running ike#

Next, a VPN must be defined to specify the security parameters and policies to apply to the traffic, as well as authentication credentials for the IKE negotiation. To simplify the configuration of VPNs, VPN templates are proposed.

VPN templates ¶

The number of parameters for IKE is very high and it would be painful to repeat all of them for each VPN configuration. Therefore a template system is available to ease the configuration:

several VPNs can share the same settings by referring to the same template,
each parameter present in a template can be overridden by the VPN.

The IKE protocol consists of two phases:

The first phase performs mutual authentication of two IKE peers and establishes an IKE Security Association (IKE SA), i.e. a secure communication channel between the two parties.
The second phase enables to create or update pairs of ESP or AH SAs. Each pair of ESP or AH SAs is called a CHILD SA.

IKE policy templates ¶

IKE policy templates enable to define a model of IKE SA parameters. VPNs inherit their IKE SA parameters from such template, then can override each of them.

Create an IKE policy template:

vsr running ike# ike-policy-template iketemp1
vsr running ike-policy-template iketemp1#

The IKE policy template is initialized with various default values:

vsr running ike-policy-template iketemp1# show config
ike-policy-template iketemp1
    local-auth-method pre-shared-key
    remote-auth-method pre-shared-key
    keying-tries 1
    unique-sa no
    reauth-time 0s
    rekey-time 4h
    dpd-delay 0s
    aggressive false
    udp-encap false
    ..

One or more IKE cryptographic algorithm proposals may then be defined in the ike-policy-template, or directly in the VPN ike-policy:

Each IKE proposal must contain either:

a list of encryption algorithms (enc-alg).
a list of authentication algorithms (auth-alg).
a list of diffie hellman groups (dh-group) for key exchanges.
optionally a list of pseudo-random function algorithms (prf-alg). If no prf-alg is provided, then the authentication algorithms will be used for generating random numbers.

Or:

a list of combined mode algorithms (aead-alg), which provide both encryption and authentication.
a list of diffie hellman groups (dh-group) for key exchanges.
a list of pseudo-random function algorithms (prf-alg) for generating random numbers.

vsr running ike-policy-template iketemp1# ike-proposal 1
vsr running ike-proposal 1#! enc-alg aes128-cbc
vsr running ike-proposal 1#! auth-alg hmac-sha512
vsr running ike-proposal 1#! dh-group modp2048
vsr running ike-proposal 1# ..
vsr running ike-policy-template iketemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ike-policy-template iketemp1
        ike-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha512
            dh-group modp2048
            ..
        ..
    ..

As supported by the IKE protocol, the IKE daemon may submit several IKE proposals in a negotiation, and (for IKEv2 only), each proposal may contain several algorithms of the same type (for example several encryption algorithms).

All other parameters of an ike-policy-template have a default value. Each parameter (including ike-proposal) may be overridden by the VPN, for example the authentication method.

IPsec policy templates ¶

IPsec policy templates enable to define a model of CHILD SA parameters. VPNs inherit their IPsec SA parameters from such template, then can override each of them.

Create an IPsec policy template:

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1#

The IPsec policy template is initialized with various default values:

vsr running ipsec-policy-template ipsectemp1# show config
ipsec-policy-template ipsectemp1
    start-action trap
    close-action trap
    dpd-action restart
    replay-window 32
    rekey-time 1h
    rekey-bytes 0
    rekey-packets 0
    encap-copy-dscp true
    decap-copy-dscp false
    encap-copy-df true
    ..

One or more ESP and AH cryptographic algorithm proposals may then be defined in the ipsec-policy-template, or directly in the VPN ipsec-policy.

Each ESP proposal must contain either:

a list of encryption algorithms (enc-alg).
a list of authentication algorithms (auth-alg).

Or:

a list of combined mode algorithms (aead-alg), which provide both encryption and authentication.

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1#! enc-alg aes128-cbc
vsr running esp-proposal 1#! auth-alg hmac-sha256
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            ..
        ..
    ..

Each AH proposal must contain:

a list of authentication algorithms (auth-alg).

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# ah-proposal 1
vsr running ah-proposal 1#! auth-alg hmac-sha512
vsr running ah-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        (...)
        ah-proposal 1
            auth-alg hmac-sha512
            ..
        ..
    ..

Each ESP and AH proposal may optionally activate Perfect Forward Secrecy (PFS) by specifying a list of diffie hellman groups. This will trigger an additional diffie hellman exchange to exchange CHILD SA keys. If no dh-group is specified, CHILD SA keys will be derived from former keys.

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1# dh-group modp2048
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        (...)
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            dh-group modp2048
            ..
        ..
    ..

A proposal may also optionally enable Extended Sequence Numbers (ESN) (see Extended Sequence Number (ESN)).

As supported by the IKE protocol, the IKE daemon may submit several ESP or AH proposals in a negotiation, and (for IKEv2 only), each proposal may contain several algorithms of the same type (for example several encryption algorithms).

All other parameters of an ipsec-policy-template have a default value. Each parameter (including esp-proposal and ah-proposal) may be overridden by the VPN, for example the replay window size.

An important parameter is start-action that defaults to trap, meaning that the tunnel will be triggered as soon as outgoing matching traffic is detected.

See also

The command reference for details about template parameters.

To display the configuration, from the ike context, type:

vsr running ike# show config
ike
    (...)
    ike-policy-template iketemp1
        local-auth-method pre-shared-key
        remote-auth-method pre-shared-key
        keying-tries 1
        reauth-time 0s
        rekey-time 4h
        dpd-delay 0s
        aggressive false
        udp-encap false
        ike-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            dh-group modp2048
            auth-alg hmac-sha512
            ..
        ..
    ipsec-policy-template ipsectemp1
        start-action trap
        close-action trap
        dpd-action restart
        replay-window 32
        rekey-time 1h
        rekey-bytes 0
        rekey-packets 0
        encap-copy-dscp true
        decap-copy-dscp false
        encap-copy-df true
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            ..
        ah-proposal 1
            auth-alg hmac-sha512
            ..
        ..

After VPN templates have been created, you may use them in one or several VPNs.

Creating a VPN ¶

A VPN defines the security parameters between the local host and a remote IKE peer (or a group of IKE peers), and the IPsec security policies to apply to the IP traffic that transits through these peers.

Creating a VPN basically consists in:

specifying which IKE and IPsec template to apply,
optionally overriding some parameters of these templates,
define identities of the peers and their credentials,
specify the IPsec security policies to apply.

Create the VPN vpn-hq, use the ike-policy-template iketemp1 and override parameter keying-tries, use the ipsec-policy-template ipsectemp1.

vsr running vpn vpn-hq#! ike-policy
vsr running ike-policy#! template iketemp1
vsr running ike-policy#! keying-tries 10
vsr running ike-policy#! ..
vsr running vpn vpn-hq#! ipsec-policy
vsr running ipsec-policy#! template ipsectemp1
vsr running ipsec-policy#! ..
vsr running vpn vpn-hq#! local-address 192.0.2.1
vsr running vpn vpn-hq#! remote-address 198.51.100.1
vsr running vpn vpn-hq#! local-id user1.roadw.6wind.net
vsr running vpn vpn-hq#! remote-id secgw.6wind.net

Then define an IPsec security-policy trunk between subnets 192.168.0.0/24 and 192.168.99.0/24, with the default action (do ESP in tunnel mode).

vsr running vpn vpn-hq#! security-policy trunk
vsr running security-policy trunk#! local-ts subnet 192.168.0.0/24
vsr running security-policy trunk#! remote-ts subnet 192.168.99.0/24
vsr running security-policy trunk#! ..
vsr running vpn vpn-hq#! ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ike-policy-template iketemp1
        ike-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha512
            dh-group modp2048
            ..
        ..
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            ..
        ..
    vpn vpn-hq
        ike-policy
            template iketemp1
            keying-tries 10
            ..
        ipsec-policy
            template ipsectemp1
            ..
        local-address 192.0.2.1
        remote-address 198.51.100.1
        local-id user1.roadw.6wind.net
        remote-id secgw.6wind.net
        security-policy trunk
            local-ts subnet 192.168.0.0/24
            remote-ts subnet 192.168.99.0/24
            ..
        ..
    ..

It’s also possible to configure multiple local/remote traffic-selectors with the traffic-selectors local-ts/remote-ts options:

vsr running vpn vpn-hq# security-policy trunk
vsr running security-policy trunk# traffic-selectors local-ts 1 subnet 192.168.0.0/24
vsr running security-policy trunk# traffic-selectors local-ts 2 subnet 192.168.10.0/24
vsr running security-policy trunk# traffic-selectors remote-ts 1 subnet 192.168.99.0/24
vsr running security-policy trunk# traffic-selectors remote-ts 2 subnet 192.168.100.0/24
vsr running security-policy trunk# ..
vsr running vpn vpn-hq#! ..
vsr running ike#

Note

local-ts/remote-ts and traffic-selectors local-ts/remote-ts cannot be configured together.

Finally, define a pre-shared key hq-secgw for mutual authentication with the remote peer:

vsr running ike# pre-shared-key hq-secgw
vsr running pre-shared-key hq-secgw#! id 198.51.100.1
vsr running pre-shared-key hq-secgw#! secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
vsr running pre-shared-key hq-secgw# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    pre-shared-key hq-secgw
        id 198.51.100.1
        secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
        ..
    global-options
        dos-protection
            ..
        sp-hash-ipv4
        sp-hash-ipv6
        ..
    ike-policy-template iketemp1
        ike-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha512
            dh-group modp2048
            ..
        ..
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            ..
        ..
    vpn vpn-hq
        ike-policy
            template iketemp1
            keying-tries 10
            ..
        ipsec-policy
            template ipsectemp1
            ..
        local-address 192.0.2.1
        remote-address 198.51.100.1
        local-id user1.roadw.6wind.net
        remote-id secgw.6wind.net
        security-policy trunk
            local-ts subnet 192.168.0.0/24
            remote-ts subnet 192.168.99.0/24
            ..
        ..
    ..

IKE state ¶

Show the IKE state:

vsr running config# vrf main
vsr running vrf main# ike
vsr running ike# show state
ike
    enabled true
    pre-shared-key psk-hq
        id 10.125.0.2
        id 10.125.0.1
        secret "This is a strong password"
        ..
    logging
        daemon
            default 0
            ..
        authpriv
            default disable
            ..
        ..
    global-options
        dos-protection
            cookie-threshold 10
            block-threshold 5
            init-limit-half-open 0
            init-limit-job-load 0
            ike-sa-limit 0
            ..
        threads 16
        acquire-timeout 30
        half-open-timeout 30
        sa-table-size 1
        sa-table-segments 1
        sp-hash-ipv4 local 32 remote 32
        sp-hash-ipv6 local 128 remote 128
        install-routes false
        routing-table 220
        routing-table-prio 220
        retransmit-tries 5
        retransmit-timeout 4.0
        retransmit-base 1.8
        delete-rekeyed false
        delete-rekeyed-delay 5
        make-before-break false
        snmp false
        mobike-prefer-best-path false
        ..
    ha
        enabled false
        ..
    vpn vpn-hq
        version 2
        local-address 10.125.0.1
        remote-address 10.125.0.2
        security-policy site2site
            local-ts subnet 10.100.0.0/24
            remote-ts subnet 10.200.0.0/24
            traffic-selectors
                local-ts 1 subnet 10.100.0.0/24
                remote-ts 1 subnet 10.200.0.0/24
                ..
            action esp
            mode tunnel
            priority 0
            ..
        ike-policy
            ike-proposal 1
                enc-alg aes128-cbc
                auth-alg hmac-sha1
                dh-group modp2048
                ..
            local-auth-method pre-shared-key
            remote-auth-method pre-shared-key
            keying-tries 1
            unique-sa no
            reauth-time 0
            rekey-time 14400
            dpd-delay 0s
            aggressive false
            udp-encap false
            mobike false
            ..
        ipsec-policy
            esp-proposal 1
                enc-alg aes128-cbc
                auth-alg hmac-sha1
                dh-group modp2048
                ..
            start-action trap
            close-action trap
            dpd-action restart
            replay-window 32
            rekey-time 3600
            rekey-bytes 0
            rekey-packets 0
            encap-copy-dscp true
            decap-copy-dscp false
            encap-copy-df true
            ..
        ..
    ike-sas
        total 1
        half-open 0
        ..
    task-processing
        worker-threads
            total 16
            idle 11
            critical 4
            high 0
            medium 1
            low 0
            ..
        task-queues
            critical 0
            high 0
            medium 0
            low 0
            scheduled 3
            ..
        ..
    counters
        ike-rekey-init 0
        ike-rekey-resp 0
        child-rekey 0
        invalid 0
        invalid-spi 0
        ike-init-in-req 0
        ike-init-in-resp 1
        ike-init-out-req 1
        ike-init-out-resp 0
        ike-auth-in-req 0
        ike-auth-in-resp 1
        ike-auth-out-req 1
        ike-auth-out-resp 0
        create-child-in-req 0
        create-child-in-resp 0
        create-child-out-req 0
        create-child-out-resp 0
        info-in-req 0
        info-in-resp 0
        info-out-req 0
        info-out-resp 0
        ..
    vpn-counters name vpn-hq
        ike-rekey-init 0
        ike-rekey-resp 0
        child-rekey 0
        invalid 0
        invalid-spi 0
        ike-init-in-req 0
        ike-init-in-resp 1
        ike-init-out-req 1
        ike-init-out-resp 0
        ike-auth-in-req 0
        ike-auth-in-resp 1
        ike-auth-out-req 1
        ike-auth-out-resp 0
        create-child-in-req 0
        create-child-in-resp 0
        create-child-out-req 0
        create-child-out-resp 0
        info-in-req 0
        info-in-resp 0
        info-out-req 0
        info-out-resp 0
        ..
    ike-sa unique-id 1
        name vpn-hq
        version 2
        state established
        local-address 10.125.0.1
        remote-address 10.125.0.2
        local-port 500
        remote-port 500
        initiator-spi 6e6228d1c13daaf1
        responder-spi b2f0a5217f09662a
        enc-alg aes128-cbc
        auth-alg hmac-sha1
        prf-alg hmac-sha1
        dh-group modp2048
        established-time 24
        rekey-time 14170
        reauth-time 45567
        udp-encap false
        mobike false
        child-sa unique-id 2
            name site2site
            state installed
            reqid 1
            protocol esp
            udp-encap false
            mobike false
            spi-in c704d981
            spi-out c3dd14b9
            enc-alg aes128-cbc
            auth-alg hmac-sha1
            esn false
            bytes-in 304
            packets-in 2
            bytes-out 168
            packets-out 2
            installed-time 24
            rekey-time 3425
            life-time 3936
            local-ts subnet 10.100.0.0/24
            remote-ts subnet 10.200.0.0/24
            traffic-selectors
                local-ts 1 subnet 10.100.0.0/24
                remote-ts 1 subnet 10.200.0.0/24
                ..
            ..
        remote-port 500
        initiator-spi 6e6228d1c13daaf1
        responder-spi b2f0a5217f09662a
        enc-alg aes128-cbc
        auth-alg hmac-sha1
        prf-alg hmac-sha1
        dh-group modp2048
        established-time 24
        rekey-time 14170
        reauth-time 45567
        udp-encap false
        mobike false
        child-sa unique-id 2
            name site2site
            state installed
            reqid 1
            protocol esp
            udp-encap false
            mobike false
            spi-in c704d981
            spi-out c3dd14b9
            enc-alg aes128-cbc
            auth-alg hmac-sha1
            esn false
            bytes-in 304
            packets-in 2
            bytes-out 168
            packets-out 2
            installed-time 24
            rekey-time 3425
            life-time 3936
            local-ts subnet 10.100.0.0/24
            remote-ts subnet 10.200.0.0/24
            traffic-selectors
                local-ts 1 subnet 10.100.0.0/24
                remote-ts 1 subnet 10.200.0.0/24
                ..
            ..
        ..
    ..

The state dumps:

the applied configuration,
the number of negotiated IKE SAs (ike-sas),
information about the IKE daemon internal tasks (task-processing),
global IKEv2 message counters (counters),
per VPN IKEv2 message counters (vpn-counters). Note that when the host is responder, some counters remain null because the IKE daemon cannot determine the involved VPN before the authentication is completed (invalid, invalid-spi, ike-init-in-req, ike-init-out-resp…),
the negotiated IKE SAs and their child SAs (ike-sa).

Note

Child SAs traffic selector proposed by the remote peer can include unsupported stuff (like port range). In this case, the flag unsupported is set:

local-ts: subnet 10.100.0.0/24 protocol 17 port 50000-54000 unsupported

Route-based VPNs through SVTI interfaces ¶

Security policies can be bound to SVTI interfaces to configure route-based VPNs.

SVTI interfaces handle their own SPD and SAD.

Outgoing traffic routed through an SVTI interface is submitted to a security policy lookup against the SVTI interface’s own SPD and, when a matching SP is found, encrypted using an SA from its own SAD matching the SP, or dropped if no match was found.

Incoming IPsec-encrypted traffic is first decrypted with the right SA. If the SA is bound to an SVTI interface (via an svti-id), it is then submitted to a security policy check against the SVTI interface’s own SPD. If the packet is granted access, the decrypted traffic is received via the SVTI interface.

Static SVTI interfaces ¶

To bind a security policy to an SVTI interface, set the security policy svti-id-in and svti-id-out fields to the interface svti-id:

Create SVTI interface svti100:

vsr running config# vrf main interface svti svti100
vsr running svti svti100#! svti-id 100
vsr running svti svti100# /
vsr running config#

Create IKE VPN my_vpn, with a security policy bound to svti100:

vsr running config# vrf main ike vpn my_vpn
vsr running vpn my_vpn#!
(...)
vsr running vpn my_vpn# security-policy mytunnel
vsr running security-policy mytunnel# svti-id-in 100
vsr running security-policy mytunnel# svti-id-out 100

The security policy is bound to the SVTI interface with svti-id 100 and link-VRF main, namely svti100.

Note

The decision to bind to an SVTI interface is done per security-policy and per direction. The configuration may differ between two security-policies and between two directions of the same security-policy. For example:

vsr running vpn my_vpn# security-policy mytunnel1 svti-id-in 100 svti-id-out 200
vsr running vpn my_vpn# security-policy mytunnel2 svti-id-out 150
vsr running vpn my_vpn# security-policy mytunnel3

See SVTI for details about creating SVTI interfaces.

Dynamic SVTI interfaces ¶

SVTI interfaces may be dynamically created and attached to IKE SAs as they are established.

To proceed, first create an SVTI template:

vsr running config# / vrf main
vsr running vrf main# interface svti-template svtitemp100
vsr running svti-template svtitemp100# mtu 1300
vsr running svti-template svtitemp100# /
vsr running config#

Then create a VPN bound to this SVTI template:

vsr running config# / vrf main ike vpn my_vpn
vsr running vpn my_vpn#!
(...)
vsr running vpn my_vpn# dynamic-svti
vsr running dynamic-svti# svti-template svtitemp100
vsr running dynamic-svti# ..
vsr running vpn my_vpn#

Note

A separate SVTI interface is created for each established IKE SA spawned from this VPN definition. All its child SAs are bound to the SVTI, for both the inbound and outbound traffic.

Routes are automatically added or deleted via the dynamically created SVTI interface as child SAs are established or torn down. Which routes should be added is configurable in the SVTI template with the install-routes-to command.

Add routes to the IKE SA remote host VIPs, if any, else to the child SA remote traffic selector. This is the default behavior:

vsr running config# / vrf main
vsr running vrf main# interface svti-template svtitemp100
vsr running svti-template svtitemp100#
vsr running svti-template svtitemp100# install-routes-to vip-or-remote-ts

Add routes to the child SA remote traffic selector:

vsr running svti-template svtitemp100# install-routes-to remote-ts

Add routes to the IKE SA remote host VIPs, if any:

vsr running svti-template svtitemp100# install-routes-to vip

Do not add any route:

vsr running svti-template svtitemp100# install-routes-to none

See Dynamic SVTI for details about creating SVTI interface templates.

Cross-VRF with static SVTI interfaces ¶

Like other tunnel interfaces, SVTI interfaces enable to perform cross-VRF encapsulation: encapsulated packets are not in the same VRF as the original packets.

../../../../_images/ike-route-based-xvrf.svg

To proceed, configure the SVTI interface in the VRF of original packets, specify a link-VRF equal to the VRF of encapsulated packets.

vsr running config# vrf private interface svti svti100
vsr running svti svti100#! svti-id 100
vsr running svti svti100# link-vrf wan
vsr running svti svti100# /
vsr running config#

Then configure IKE in the link-VRF.

vsr running config# vrf wan ike vpn my_vpn
vsr running vpn my_vpn#!
(...)
vsr running vpn my_vpn# security-policy mytunnel
vsr running security-policy mytunnel# svti-id-in 100
vsr running security-policy mytunnel# svti-id-out 100
vsr running security-policy mytunnel# /
vsr running config#

The SVTI interface is uniquely identified by its (svti-id, link-vrf) pair.

To show the configuration:

vsr running config# show config nodefault
vrf private
   interface
        svti svti100
            link-vrf wan
            ..
        ..
    (...)
vrf wan
    ike
        vpn my_vpn
            (...)
            security-policy mytunnel
                svti-id-in 100
                svti-id-out 100
    (...)

Cross-VRF with dynamic SVTI interfaces ¶

Dynamic SVTI interfaces also enable to perform cross-VRF encapsulation. The cross-VRF of a dynamic interface is the VRF of the VPN that triggered its creation.

To proceed, configure the SVTI template in the VRF of original packets.

vsr running |vrf| private# interface svti-template svtitemp100
vsr running svti-template svtitemp100# mtu 1300
vsr running svti-template svtitemp100# /
vsr running config#

Then create a VPN in the link-VRF and bind it to the SVTI template, by specifying its name and VRF.

vsr running config# vrf wan ike vpn my_vpn
vsr running vpn my_vpn#!
(...)
vsr running vpn my_vpn# dynamic-svti
vsr running dynamic-svti# svti-template svtitemp100
vsr running dynamic-svti# vrf private
vsr running dynamic-svti# /
vsr running config#

To show the configuration:

vsr running config# show config nodefault
vrf private
   interface
        svti-template svtitemp100
            mtu 1300
            ..
        ..
   (...)
vrf wan
    ike
        vpn my_vpn
            dynamic-svti
                svti-template svtitemp100
                vrf private
                ..
            (...)
    (...)

Note

If a VPN in VRF wan specifies an SVTI template, then no static SVTI must be configured with its link VRF in wan.

Route-based VPNs through GRE interfaces ¶

Security policies can be configured to select the traffic encapsulated by a GRE tunnel, by matching the IP addresses and protocol (47) of the GRE tunnel. The IPsec encapsulation is typically performed in transport mode.

Traffic routed through these GRE tunnels is GRE-encapsulated and the GRE packet is itself IPsec-encrypted.

It is therefore possible to perform route-based VPNs by creating GRE interfaces and configure IKE so that it protects the GRE-encapsulated traffic. Plain text packets routed to or received from such a GRE interface are protected without the need for individual security policies, and routing protocols may be run on these interfaces.

Static GRE interfaces ¶

To encrypt a GRE tunnel via IPsec, create a VPN between the GRE tunnel endpoint addresses and specify protocol GRE (47) in the security-policy traffic selectors:

Create GRE interface gre100:

vsr running config# / vrf main interface gre gre100
vsr running gre gre100#! local 10.125.0.1
vsr running gre gre100# remote 10.175.0.2

Create IKE VPN my_vpn, with a security policy that matches the gre100 tunnel addresses and protocol:

vsr running config# / vrf main ike vpn my_vpn
vsr running vpn my_vpn#!
(...)
vsr running vpn my_vpn# local-address 10.125.0.1
vsr running vpn my_vpn# remote-address 10.175.0.2
(...)
vsr running vpn my_vpn# security-policy gretunnel
vsr running security-policy gretunnel# mode transport
vsr running security-policy gretunnel# local-ts protocol 47

The protocol may be specified in the local-ts and/or the remote-ts.

Note

Since the security policy addresses are those of the IKE peers, the subnet argument of local-ts and remote-ts may be ommitted. However it is possible to explicitly specify them:

vsr running vpn my_vpn# security-policy gretunnel
vsr running security-policy gretunnel# mode transport
vsr running security-policy gretunnel# local-ts subnet 10.125.0.1 protocol 47
vsr running security-policy gretunnel# remote-ts subnet 10.175.0.2

All traffic routed through the GRE interface will be GRE-encapsulated then IPsec-encrypted:

vsr running config# / vrf main routing
vsr running routing# static
vsr running static # ipv4-route 10.200.0.0/24 next-hop gre100

Dynamic GRE interfaces ¶

GRE interfaces may be dynamically created and protected by the IKE SAs as they are established.

This feature relies on gre-templates and remote peer PSK authentication via RADIUS.

First configure remote peer PSK authentication via RADIUS as described in Remote peer authentication by PSK via RADIUS.

Then create a GRE interface template in the same VRF as IKE:

vsr running config# / vrf main
vsr running vrf main# interface gre-template gretemp1
vsr running gre-template gretemp1# mtu 1300
vsr running gre-template gretemp1# install-routes-to none

Then bind a vpn to the gre-template by specifying its name under dynamic-gre:

vsr running config# / vrf main
vsr running vrf main# vpn my_vpn
vsr running vrf my_vpn# dynamic-gre
vsr running dynamic-gre#! template gretemp1
vsr running dynamic-gre# ..

The GRE tunnel encapsulation addresses are those of the negotiated IKE SA.

The VPN security policy should match the GRE-encapsulated traffic, so that the GRE encapsulation traffic is IPsec-encrypted:

vsr running vpn my_vpn# security-policy gretunnel
vsr running security-policy gretunnel# mode transport
vsr running security-policy gretunnel# local-ts protocol 47
vsr running security-policy gretunnel# ..

These GRE tunnels can also perform cross-VRF encapsulation. The VRF of the GRE interface (i.e. the VRF of packets before encapsulation or after decapsulation) is the VRF under which the gre-template is configured. The link-VRF of the GRE interface (i.e. the VRF of encapsulated packets) is the VRF under which GRE tunneling is configured (the VRF from which the GRE template is referenced).

To proceed, configure the GRE template in the VRF of plaintext packets:

vsr running config# / vrf private
vsr running vrf private# interface gre-template gretemp2
vsr running gre-template gretemp2# mtu 1300
vsr running gre-template gretemp2# install-routes-to none
vsr running gre-template gretemp2# ..

Then bind a vpn in the link-VRF to the gre-template, by specifying its VRF and name under dynamic-gre:

vsr running gre-template gretemp2# / vrf public
vsr running vrf public# vpn my_vpn dynamic-gre
vsr running dynamic-gre#! vrf private
vsr running dynamic-gre#! template gretemp2

The names of the GRE interfaces created through this functionality are composed of a dgreike prefix followed by random ASCII characters. If all such names are taken the creation of the tunnel will fail.

Additional supported RADIUS attributes¶

Additional behavior can be specified via RADIUS attributes:

Framed-Route and Framed-IPv6-Route can be used to specify IPv4 and IPv6 routes to direct through the GRE interface.
l3vrf can be used to specify an L3VRF to which the GRE interface should be attached.
ip-address can be used to assign IP addresses to the GRE interface.
ike:internal-ip-subnet can be used to specify IP addresses that should be communicated via the INTERNAL_IP_SUBNET and INTERNAL_IP6_SUBNET IKE attributes.

See also

RADIUS attribute support

Configuring QoS on dynamic GRE interfaces¶

The gre-template may define a list of QoS templates to apply to dynamically created GRE interfaces. The QoS template to apply to a given interface is specified by the qos:egress-template 6WIND vendor RADIUS attribute. A default QoS template may also be specified in the configuration. It will be applied to the interface if the RADIUS attribute is not set or if the requested QoS template is not found.

Each QoS template references QoS objects (shapers, schedulers) defined in the / qos context, in a similar way as QoS is configured on a manually configured interface.

vsr running gre-template gretemp2# qos
vsr running gre-template qos# egress

vsr running egress# template GOLD-1G
vsr running template GOLD-1G# scheduler sched-HTB
vsr running template GOLD-1G# ..

vsr running egress# template SILVER-1000K
vsr running template SILVER-1000K# rate-limit shaper shaper-1000K
vsr running template SILVER-1000K# scheduler sched-PQ
vsr running template SILVER-1000K# ..

vsr running egress# template SILVER-256K
vsr running template SILVER-256K# rate-limit shaper shaper-256K
vsr running template SILVER-256K# scheduler sched-PQ
vsr running template SILVER-256K# ..

vsr running egress# template BRONZE-256K
vsr running template BRONZE-256K# rate-limit shaper shaper-256K
vsr running template BRONZE-256K# scheduler sched-DWRR
vsr running template BRONZE-256K# ..

vsr running egress# template SHAPE-256K
vsr running template SHAPE-256K# rate-limit shaper shaper-256K
vsr running template SHAPE-256K# ..

vsr running egress# template NO_QOS
vsr running template NO_QOS# ..

vsr running egress# default-template SHAPE-256K

Let us assume a GRE interface is dynamically created from the gre-template gretemp2. Depending on the value of the qos:egress-template 6WIND-AVPair attribute in the RADIUS response during the authentication phase, the following QoS template will be applied:

no qos:egress-template attribute: the default QoS template SHAPE-256K will be applied,
qos:egress-template=SILVER-1000K: the requested QoS template SILVER-1000K will be applied,
qos:egress-template=TITANIUM-2G: the default QoS template SHAPE-256K will be applied, because the requested template does not exist,
qos:egress-template=NO_QOS: the requested QoS template NO_QOS will be applied, which implies that no QoS will be applied.

A FreeRADIUS configuration example¶

Using PSK RADIUS authentication requires that the RADIUS server be configured to send 6WIND vendor attributes. How this can be done will depend on the RADIUS implementation, but an example using the FreeRADIUS implementation is provided here.

A dictionary will be necessary for FreeRADIUS to recognize and use 6WIND vendor attributes. Here is the complete 6WIND vendor dictionary for FreeRADIUS:

VENDOR 6WIND 7336
BEGIN-VENDOR 6WIND
ATTRIBUTE 6WIND-AVPair 1 string
END-VENDOR 6WIND

You may then create users and configure the attributes for each. Here is how a user making use of PSK authentication via RADIUS might be configured for FreeRADIUS:

user1@example.com   Cleartext-Password := "GlobalUserPassword"
   Framed-IP-Address = 10.0.0.1,
   6WIND-AVPair = "ike:psk-remote=user1psk",
   # Attributes for the GRE extension
   Framed-Route = "10.0.0.0/24",
   6WIND-AVPair = "l3vrf=user1_l3vrf",
   6WIND-AVPair = "ip-address=10.0.0.43",
   6WIND-AVPair = "ike:internal-ip-subnet=10.0.0.43/32",
   6WIND-AVPair = "qos:egress-template=SILVER-1000K"

See also

RADIUS attribute support

See also

The command reference.