EdgeRouter: IPSEC site-to-site with Virtual Tunnel Interface

The following are the steps I used to perform to set up an IPSEC VPN with a vti (virtual tunnel interface). The advantage is that using a vti gives us a route-able interface so making it easy to work with the IPSEC tunnel.
The current setup looks like:

routers

Primary Site:

ER-8 (with load-balancing WAN1 and WAN 2):
– WAN 1: eth0 linked to the ISP 1 through a Hitron cable modem in bridge mode. Thus the ER-8 gets the IP from the ISP.
– WAN 2: eth1 not linked.
– LAN 7: eth7 to internal LAN 2
– LAN 11: eth2 internal LAN 11

D-Link DWR-921 LTE:
– WAN 1: LTE link to Mobile service ISP.

EdgeRouter POE:
– WAN1: etho, IP = 192.168.7.10 linked to EdgeRouter ER-8 eth7 with gateway 192.168.7.1
– WAN2: eth1, IP = 192.168.0.50 link to D-Link DWR-921 LTE eth4 with gateway 192.168.0.1
– LAN 2: switch0, all the internal LAN

Remote Site:

UPC Cable Modem:
– WAN 1: eth0 linked to the ISP 1

EdgeRouter Lite:
– WAN 1: eth0, link to UPC Cable Modem eth1 with gateway 192.168.0.1
– LAN 9: eth1, local service LAN
– LAN 10: eth2, local management LAN

The IPSEC tunnel will be done between primary site router ER-8 and remote site router ER-Lite. Note that this is not a trivial case of an IPSEC due to the complications introduced by vti and the fact that one of the routers is behind NAT. The simple IPSEC site-to-site cane be done directly from EdgeRouter GUI.

STEP 1: Allow IPSEC traffic

On both routers that will be the end point on the IPSEC add to the WAN_local the following accept rules. Note we are allowing also icmp traffic so we will be able to use ping to test the connections.

firewall {
...
name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        rule 1 {
            action accept
            description "Allow established/related"
            state {
                established enable
                related enable
            }
        }
        rule 2 {
            action accept
            description "Allow IPSEC IKE"
            destination {
                port 500
            }
            log disable
            protocol tcp_udp
        }
        rule 3 {
            action accept
            description "Allow IPSEC NAT-T"
            destination {
                port 4500
            }
            log disable
            protocol udp
        }
        rule 4 {
            action accept
            description "Allow IPSEC ESP"
            log disable
            protocol esp
        }
        rule 5 {
            action accept
            description "Allow icmp"
            log disable
            protocol icmp
        }
        rule 6 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
...

STEP 2: Define the vti Interface

We define on both routers a virtual interface vti0 that will be linked to the IPSEC VPN tunnel.

configure
show interfaces vti
....
vti0 {
        address 40.0.0.1/30
        mtu 1436
    }

STEP 3: Define the IPSEC end points

On router 1 : ER-8 EdgeRouter

configure
show vpn
...
    ipsec {
        auto-firewall-nat-exclude enable
        esp-group FOO0 {
            compression disable
            lifetime 3600
            mode tunnel
            pfs enable
            proposal 1 {
                encryption aes256
                hash sha1
            }
        }
        ike-group FOO0 {
            ikev2-reauth no
            key-exchange ikev1
            lifetime 28800
            proposal 1 {
                dh-group 14
                encryption aes256
                hash sha1
            }
        }
        ipsec-interfaces {
            interface eth0
        }
        nat-networks {
            allowed-network 0.0.0.0/0 {
            }
        }
        nat-traversal enable
        site-to-site {
            peer yy.yy.yy.yy {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret password
                    remote-id 192.168.0.15
                }
                connection-type initiate
                description "Voinageo IPSEC site-to-site"
                ike-group FOO0
                ikev2-reauth inherit
                local-address xx.xx.xx.xx
                vti {
                    bind vti0
                    esp-group FOO0
                }
            }
        }

On router 2 : ER-Lite

ipsec {
        auto-firewall-nat-exclude enable
        esp-group FOO0 {
            compression disable
            lifetime 3600
            mode tunnel
            pfs enable
            proposal 1 {
                encryption aes256
                hash sha1
            }
        }
        ike-group FOO0 {
            ikev2-reauth no
            key-exchange ikev1
            lifetime 28800
            proposal 1 {
                dh-group 14
                encryption aes256
                hash sha1
            }
        }
        ipsec-interfaces {
            interface eth0
        }
        nat-networks {
            allowed-network 0.0.0.0/0 {
            }
        }
        nat-traversal enable
        site-to-site {
            peer xx.xx.xx.xx {
                authentication {
                    mode pre-shared-secret
                    pre-shared-secret password
                }
                connection-type initiate
                description "Voinageo IPSEC site-to-site"
                ike-group FOO0
                ikev2-reauth inherit
                local-address 192.168.0.15
                vti {
                    bind vti0
                    esp-group FOO0
                }
            }
        }

Note the following :

1. primary site IP is xx.xx.xx.xx and remote site IP is yy.yy.yy.yy

2. The peer definition “peer xx.xx.xx.xx” must contain an IP. In case of normal IPSEC one could use a DNS name. Using a DNS name will allow us to have a IPSEC between servers that have a dynamic IP. Sadly this is not possible if we want to use vti, using vti mandates that we use IPs. I do not have static IPs from my ISPs but they tend not to change the IPs if there is not some incident that forces some hard reshuffle of their infrastructure.

3. On primary site:

– peer yy.yy.yy.yy = this is the real WAN IP on the remote site. This IP is not the WAN IP of the EdgeRouter but the WAN IP of the cable router that is in front of it. As an extra step remember to forward the IPSEC ports from the cable router to the EdgeRouter Lite.

– remote-id 192.168.0.15 = this is the WAN IP of the EdgeRouter Lite. It is very important to add this parameter for the IPSEC tunnel’s endpoint that NATed. If is not added the IPSEC connection negotiation will fail because the primary site will not agree to receive a challenge from someone named “192.168.0.15” when he expects “yy.yy.yy.yy”

– local-address xx.xx.xx.xx = this is the WAN IP of the primary site.

4. On remote site:

– peer xx.xx.xx.xx = this is the real WAN IP on the primary site.

– no need to specify a remote-id as the router from primary site is not NATed.

– local-address 192.168.0.15 = this is the WAN IP of the EdgeRouter Lite the IPSEC endpoint. Note that is not the remote WAN IP because this router is NATed.

5. Note that we no longer define a tunnel configuration but we simply declare a bind to the vti0 we created earlier.

STEP 4: Offload IPSEC traffic

To get hardware acceleration we must activate packets offload for ipsec.
Execute on both routers:

configure
set system offload ipsec enable
commit
save

STEP 5: Start the tunnel

To start the IPSEC tunnel issue on both routers CLI:

restart vpn

To see the status of the VPN

show vpn ipsec sa
show vpn log

STEP 6: Define a route through the vti

If we see that the VPN was establish now it is time to add a route through it. This is the advantage of vti, we can treat it as any other interface.

On primary site router:

configure
set protocols static interface-route 192.168.10.0/24 next-hop-interface vti0
commit
save

On remote site router:

configure
set protocols static interface-route 192.168.7.0/24 next-hop-interface vti0
commit
save

STEP 7: Exclude IPSEC trafic from NAT

We have to exclude the IPSEC trafic from NAT by adding for each destination network a rule in the NAT rules.

For ex: on remote site (note is the same as the existing one for OpenVPN):

nat {
        rule 5000 {
            description "Exclude OpenVPN traffic from eth0"
            destination {
                address 192.168.2.0/24
            }
            exclude
            log enable
            outbound-interface eth0
            protocol all
            source {
                address 192.168.9.0/24
            }
            type masquerade
        }
        rule 5001 {
            description "Exclude IPSEC traffic from eth0"
            destination {
                address 192.168.7.0/24
            }
            exclude
            log disable
            outbound-interface eth0
            protocol all
            source {
                address 192.168.10.0/24
            }
            type masquerade
        }
....

The same type of NAT exclude rule we have also on primary site

      rule 5003 {
            description "Exclude IPSEC traffic from eth0"
            destination {
                address 192.168.9.0/24
            }
            exclude
            log disable
            outbound-interface eth0
            source {
                address 192.168.7.0/24
            }
            type masquerade
        }

STEP 8: Test connection
Test the connection by ping-ing from one site to the other.

STEP 9: Change the peer IP

Sadly as I mention above the peer cannot be specified as a name, must be an IP. From time to time one of the peer IPs is changed by the ISP. In that case the following edit can be done:

At Edge Router CLI:

configure
edit vpn ipsec site-to-site
rename peer old_ip to peer new_ip
commit
save
exit
restart vpn
show vpn ipsec sa
Advertisements

3 thoughts on “EdgeRouter: IPSEC site-to-site with Virtual Tunnel Interface

  1. Pingback: Linux: How to remote desktop a Fedora 23 from a Windows 10 | blog.voina.org

  2. Pingback: EdgeRouter: Routing through OpenVPN and IPSEC with OSPF | blog.voina.org