# Doodle #3: How Service Providers connect Non-MPLS Customer Site to their MPLS fabric?

## Introduction

You know now what is Multi-Protocol Label Switching (MPLS), and how you can utilize its concept to form a MPLS L3 VPN connection with your customers.

That’s very good because your customers are segmented using virtual routing instances thru Virtual Routing an Forwarding (VRF) and are passing traffic to their far-away sites. **However, we have a problem:** There may be situations where a *MPLS service is not available within a specific area*. Apart from this, your customers might *need a less expensive redundant connection* in case of Wide Area Network (WAN) outages. So what might be our option? ***IPSec-VPN Tunnel***.

This doodle entry focuses on the step-by-step guide to solve the problem situation stated previously. What are we waiting for? Let’s start!

## Main Tasks

This doodle entry has three (3) main tasks, broken down below:

1. Configuring IPSec-VPN Tunnel from the Service Provider’s Provider Edge (PE) router
    
2. Configuring IPSec-VPN Tunnel from the Customer Edge (CE) router
    
3. Establish Border Gateway Protocol (BGP) session between PE and CE
    

## Topology

You can see in our diagram that **A-CUSTOMER** is currently using the Service Provider’s MPLS service enabling private WAN service to connect with different sites around the world.

**A-CUSTOMER-SITE-1** Customer Edge (CE) router currently have a *BGP session established with PE1* and is advertising Local Area Network (LAN) routes to the *Virtual Routing and Forwarding (VRF)* instance in the Service Provider’s portion.

You can observe that PE2 and A-CUSTOMER-SITE-2 are connected to the Internet. That is where we’ll pass traffic as we configure IPSec-VPN Tunnel.

This setup, a way of bridging the gap in delivering enterprise traffic between Private and Public connection without compromising privacy in between is called ***MPLS-aware IPSec*** \[1\].

You can find useful articles in the ***References*** section of this doodle entry.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729071412691/bf1bab4c-8e19-493c-a8cd-aacb00d670e0.png align="center")

### But before that…

To start our job here, the primary requirement we need in both ***PE2*** and ***A-CUSTOMER-SITE-2*** is *internet connection.* Below are the full requirements for each of them:

**PE2:** Customer VRF instance, Frontdoor VRF (FVRF), and Internet connection

**A-CUSTOMER-SITE-2:** Internet connection

## Configuration

First-things first, we need an existing Service Provider MPLS domain providing private WAN service to where CE connects to, and an Internet connection.

\[NOTE\] To have some information on how we can enable MPLS service, you might want to check doodle entries [Configuring MPLS L3 VPN on Cisco using GNS3](https://nekwokdoodle.com/configuring-mpls-l3-vpn-on-cisco-ios-using-gns3) \[2\] and [The Customer's Way of Connecting Branch Sites with MPLS L3 VPN and Site-to-Site IPsec VPN](https://nekwokdoodle.com/the-customers-way-of-connecting-branch-sites-using-mpls-l3-vpn-and-site-to-site-ipsec-vpn-pt1) \[3\].

To manage our expectation, here’s what we want to do:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729085607258/5f76b7bf-cbfb-4601-af22-df25c67c9242.png align="center")

A *logical interface* (a VPN) with applied cryptography to connect our Customer Edge (CE) router to the Provided Edge (PE) as if it were a MPLS L3 VPN service setup.

### Main Task 1: Configuring IPSec-VPN Tunnel from the Service Provider’s Provider Edge (PE) router

In this part of the configuration, we created a Frontdoor VRF (FVRF) to place the Public IP Address facing the internet. Default route to the internet is also configured.

```plaintext
--PE2--
PE2#conf t
PE2(config)#ip vrf FVRF
PE2(config-vrf)#exit
PE2(config)#interface g0/7
PE2(config-if)#no shutdown
PE2(config-if)#ip vrf forwarding FVRF
PE2(config-if)#ip address 61.0.0.2 255.255.255.252
PE2(config-if)#exit
PE2(config)#ip route vrf FVRF 0.0.0.0 0.0.0.0 g0/7 61.0.0.1
PE2(config)#do ping vrf FVRF 49.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 49.0.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 22/38/60 ms
```

Above PING shows that ***PE2*** can reach ***A-CUSTOMER-SITE-2***’s *Public IP Address*. This is a good sign!

```plaintext
--PE2--
--KEYRING--
PE2(config)#crypto keyring KEYRING-records vrf FVRF
PE2(conf-keyring)#local-address 61.0.0.2 FVRF
PE2(conf-keyring)#pre-shared-key address 49.0.0.2 key A-PASSWD
PE2(conf-keyring)#exit
--ISAKMP PROFILE--
PE2(config)#crypto isakmp profile A-CUST-ISAKMP-PFILE
% A profile is deemed incomplete until it has match identity statements
PE2(conf-isa-prof)#keyring KEYRING-records
PE2(conf-isa-prof)#match identity address 49.0.0.2 FVRF
PE2(conf-isa-prof)#local-address 61.0.0.2 FVRF
PE2(conf-isa-prof)#exit
--ISAKMP POLICY--
PE2(config)#crypto isakmp policy 101
PE2(config-isakmp)#hash sha
PE2(config-isakmp)#authentication pre-share
PE2(config-isakmp)#group 5
PE2(config-isakmp)#encryption aes
PE2(config-isakmp)#exit
--IPSEC TRANSFORM-SET--
PE2(config)#crypto ipsec transform-set A-CUSTOMER-TSET esp-sha-hmac esp-aes
PE2(cfg-crypto-trans)#mode tunnel
PE2(cfg-crypto-trans)#exit
--IPSEC PROFILE--
PE2(config)#crypto ipsec profile A-CUSTOMER-IPSEC-PFILE
PE2(ipsec-profile)#set transform-set A-CUSTOMER-TSET
PE2(ipsec-profile)#exit
```

Keyring is a record that contains the key (password) and its public IP Address pair of the Remote Peer that is reachable over the Internet. ISAKMP Profile of A-CUSTOMER then use the Keyring to map the defined IP Address and find its key in establishing secured association with the Remote Peer, in our case, 49.0.0.2.

ISAKMP Policy, IPSec Transform Set and Profile is then configured.

```plaintext
--PE2--
--TUNNEL INTERFACE--
PE2(config)#interface Tunnel101
PE2(config-if)#ip vrf forwarding A-CUSTOMER
PE2(config-if)#ip address 10.0.0.1 255.255.255.252
PE2(config-if)#tunnel source 61.0.0.2
PE2(config-if)#tunnel destination 49.0.0.2
PE2(config-if)#tunnel protection ipsec profile A-CUSTOMER-IPSEC-PFILE
PE2(config-if)#tunnel mode ipsec ipv4
PE2(config-if)#tunnel vrf FVRF
*Oct 16 08:54:51.851: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
*Oct 16 08:54:51.856: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Oct 16 08:54:52.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel101, changed state to up
```

Above configuration applies the crypto configuration parameters to the tunnel interface (Tunnel101). We put the interface to the customer’s VRF (A-CUSTOMER). It is obvious that there is another VRF in the last line of the configuration (tunnel vrf FVRF). Its purpose is for the tunnel interface to do route lookup to that VRF that can reach the outside network, hence reaching 49.0.0.2.

We noticed that ISAKMP is ON. The fact that ***Tunnel101 is UP*** means that our configuration works.

## Verification

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729082908987/f8d5a3a9-b791-4950-ade3-ece00eca6875.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729082794504/2f9efe22-35f5-4e8b-9f43-897b4f7da3c5.png align="center")

We can see here that both the tunnel interface (***Tunnel101***) of routers ***PE2*** and ***A-CUSTOMER-SITE-2*** are *UP*.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729082926950/47c7146a-2db5-4e8d-8d3f-15853b83b18b.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729082941026/ac70881f-0074-4dca-9057-959ce7056500.png align="center")

***ISAKMP*** session is also in effect.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729083097351/e21f0516-6c7a-4480-9aac-8dd820134c48.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729083131246/d42330bc-ddb9-4782-87b0-440b8fb583f8.png align="center")

PING is tried over the tunnel interface and it is working! This means we can now proceed to our next task.

### Main Task 2: Configuring IPSec-VPN Tunnel from the Customer Edge (CE) router

```plaintext
--A-CUSTOEMR-SITE-2--
--ISAKMP POLICY--
A-CUSTOMER-SITE-2#conf t
A-CUSTOMER-SITE-2(config)#crypto isakmp policy 101
A-CUSTOMER-SITE-2(config-isakmp)#hash sha
A-CUSTOMER-SITE-2(config-isakmp)#authentication pre-share
A-CUSTOMER-SITE-2(config-isakmp)#group 5
A-CUSTOMER-SITE-2(config-isakmp)#encryption aes
A-CUSTOMER-SITE-2(config-isakmp)#exit
--ISAKMP KEY--
A-CUSTOMER-SITE-2(config)#crypto isakmp key A-PASSWD address 61.0.0.2
--IPSEC TRANSFORM-SET--
A-CUSTOMER-SITE-2(config)#$crypto ipsec transform-set TSET esp-sha-hmac esp-aes
A-CUSTOMER-SITE-2(cfg-crypto-trans)#mode tunnel
A-CUSTOMER-SITE-2(cfg-crypto-trans)#exit
--IPSEC PROFILE--
A-CUSTOMER-SITE-2(config)#crypto ipsec profile PFILE
A-CUSTOMER-SITE-2(ipsec-profile)#set transform-set TSET
A-CUSTOMER-SITE-2(ipsec-profile)#exit
--TUNNEL INTERFACE--
A-CUSTOMER-SITE-2(config)#interface Tunnel101
A-CUSTOMER-SITE-2(config-if)#ip address 10.0.0.2 255.255.255.252
A-CUSTOMER-SITE-2(config-if)#tunnel source 49.0.0.2
A-CUSTOMER-SITE-2(config-if)#tunnel destination 61.0.0.2
A-CUSTOMER-SITE-2(config-if)#tunnel protection ipsec profile PFILE
A-CUSTOMER-SITE-2(config-if)#tunnel mode ipsec ipv4
A-CUSTOMER-SITE-2(config-if)#exit
*Oct 16 08:55:03.106: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel101, changed state to up
```

We did the typical customer configuration of IPSec-VPN tunnel here. Like in the PE2, the fact that ***Tunnel101 is UP*** means that our configuration works.

### Main Task 3: Establish Border Gateway Protocol (BGP) session between PE and CE

The purpose of this task is already known to you. Like in the previous doodle entries in MPLS L3 VPN, CE to PE Border Gateway Protocol (BGP) session should be established and advertise local networks in order for sites in different location could reach internal IP Addresses.

*There is no difference here except for using IPSec-VPN* tunnel interface to establish a session. This way, it mimics that setup in private WAN setup using the MPLS domain of the Service Provider as the terminating point. At this time, the traffic is going through the secured tunnel we’ve configured.

**PE2 Configuration**

```plaintext
--PE2--
PE2(config)#router bgp 888
PE2(config-router)#address-family ipv4 vrf A-CUSTOMER
PE2(config-router-af)#neighbor 10.0.0.2 remote-as 65002
PE2(config-router-af)#neighbor 10.0.0.2 soft-reconfiguration inbound
Oct 16 12:56:21.834: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 vpn vrf A-CUSTOMER Up
```

**A-CUSTOMER-SITE-2 Configuration**

```plaintext
--A-CUSTOMER-SITE-2--
A-CUSTOMER-SITE-2(config)#router bgp 65002
A-CUSTOMER-SITE-2(config-router)#neighbor 10.0.0.1 remote-as 888
A-CUSTOMER-SITE-2(config-router)#$.0.0.1 soft-reconfiguration inbound
*Oct 16 12:56:21.166: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Up

--ADVERTISING LAN NETWORK---
A-CUSTOMER-SITE-2(config-router)#network 192.168.41.0 mask 255.255.255.0
```

We are now *advertising* A-CUSTOMER-SITE-2 LAN network.

### Verification

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729083940228/965bdd98-469c-4728-8c47-f11ccdc4d01e.png align="center")

We can see that ***A-CUSTOMER-SITE-2*** is now advertising its LAN network (192.168.41.0/24)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729083778132/8cb5cb2e-4dd3-44a9-a0ff-7980d657718d.png align="center")

As an effect, ***PE2*** receives it.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729084036032/51516b93-8dcb-4c79-bc03-4e72d2ce35f9.png align="center")

***A-CUSTOMER-SITE-1*** also receives ***A-CUSTOMER-SITE-2***’s LAN network.

The **Question** now is, **CAN *A-CUSTOMER-SITE-2* and *A-CUSTOMER-SITE-1* LOCAL AREA NETWORK (LAN) REACH EACH OTHER**? Let’s give it a try!

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729084493342/68cc11b2-1119-4dca-8d96-979cec907bd7.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729084508344/2d83cd0c-ecca-449a-b649-a893c3e9b564.png align="center")

Here’s ***PC1*** (at ***A-CUSTOMER-SITE-1***) and PC2 (at ***A-CUSTOMER-SITE-2***) successfully PINGING each other!

## Conclusion

In this doodle entry, a solution to the two (2) scenario problems we have: 1.) *no MPLS coverage in the area*; 2.) *a least expensive redundancy that does not compromise privacy in transporting traffic in different customer locations*.

Using VRF-aware IPSec-VPN tunnel approach, the gap is bridged in keeping a privacy between Private and Public domain where customers transport their enterprise traffic from one site to another.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1729085537285/98fb3e97-4c14-456b-b78c-bc7e1730248c.png align="center")

## References

\[1\] [https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec\_conn\_ikevpn/configuration/xe-3s/VRF-Aware\_IPsec.html](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ikevpn/configuration/xe-3s/VRF-Aware_IPsec.html)

\[2\] [https://nekwokdoodle.com/configuring-mpls-l3-vpn-on-cisco-ios-using-gns3](https://nekwokdoodle.com/configuring-mpls-l3-vpn-on-cisco-ios-using-gns3)

\[3\] [https://nekwokdoodle.com/configuring-mpls-l3-vpn-on-cisco-ios-using-gns3](https://nekwokdoodle.com/configuring-mpls-l3-vpn-on-cisco-ios-using-gns3)

[Globe](https://icons8.com/icon/XsvEZR0h6fav/globe) icon by [Icons8](https://icons8.com)

[Router Symbol](https://icons8.com/icon/VhPb49mQlUt5/router-symbol) icon by [Icons8](https://icons8.com)

[Switch](https://icons8.com/icon/vZHvfEqLyLTN/switch) icon by [Icons8](https://icons8.com)

[Cloud](https://icons8.com/icon/yBcThHe2o6j6/cloud) icon by [Icons8](https://icons8.com)

[Computer](https://icons8.com/icon/20420/imac) icon by [Icons8](https://icons8.com)

### **Any questions or suggestions? Comment it and I would be very happy to discuss that!**