Front-door VRF. Another practical example
Hi habr! There are many articles on the Internet about configuring VPN with VRF on Cisco equipment. There is a good cheat sheet for setting up IPsec VPN in the form of crypto maps and VTI tunnels in conjunction with the VRF. In this article, an example of DMVPN with a VRF is given. VRF gives a great deal of flexibility when setting up a large number of equipment and options for using it. The main thing is not to forget that we have such a tool. In my note, I decided to consider another interesting problem from our practice, which also came in handy with using Front-door VRF to build IPsec tunnels. It will be about building parallel VPN tunnels through different Internet providers and distributing traffic across these tunnels.
Virtual Routing and Forwarding (VRF) technology allows you to split one physical router into several logical (virtual) ones. Thanks to this technology, it is possible to have several independent routing tables on one physical router. VRF technology is widely used in MPLS networks. However, VRF can be used without MPLS. In this case, in Cisco terminology, the technology is called VRF lite. To be more precise, VRF-lite is a technology that allows you to build two or more VPN tunnels on one VPN concentrator, in an environment that assumes intersecting address spaces. In this note, the intersection of address spaces will not be affected.
')
Very briefly consider what gives us the use of VPN in conjunction with the VRF. The protected network whose traffic is subject to encryption may not be located in the global VRF of the router. The protected network VRF is called IVRF - Inside VRF. However, by default, the router builds IPsec in the global VRF. Internet service providers can be connected to the interfaces of the router, which are also not located in the global VRF of the router. Such connection of Internet providers allows you to terminate and dispose of VPN tunnels from remote points simultaneously on all existing Internet connections of the router.
If internet providers are connected to one global VRF
In this case, there is a single default route on the router in the global VRF. A remote office can build parallel VPN tunnels up to the router in question through all available Internet channels. But the return traffic from the router in question will go in accordance with the default route through a single ISP. Therefore, only the ISP that the default route points to will be recycled by return traffic. Consider an example based on IPsec VTI tunnels:
R1 Tunnel Interface Settings:
R2 router tunnel interface settings:
For the presented configuration, the tunneled traffic will be distributed across the R1 Internet service providers as follows:
IPsec-packets Tunnel2 from R1 to R2 have the source IP address 2.2.2.1, but pass through the channel of the first ISP1 Internet service provider. Some Internet providers block traffic with source IP addresses belonging to "foreign" Internet providers. If the provider does this check, Tunnel2 will not install (therefore, part of the Tunnel2 line from R1 to R2 is shown in dotted lines).
R1 Tunnel Interface Settings:
interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 ! interface GigabitEthernet0/1 ip address 1.1.1.1 255.255.255.252 ! interface GigabitEthernet0/2 ip address 2.2.2.2 255.255.255.252 ! interface Tunnel1 ip unnumbered GigabitEthernet0/0 tunnel source 1.1.1.1 tunnel mode ipsec ipv4 tunnel destination 3.3.3.1 tunnel path-mtu-discovery tunnel protection ipsec profile ipsec-prof ! interface Tunnel2 ip unnumbered GigabitEthernet0/0 tunnel source 2.2.2.1 tunnel mode ipsec ipv4 tunnel destination 3.3.3.1 tunnel path-mtu-discovery tunnel protection ipsec profile ipsec-prof ! ip route 0.0.0.0 0.0.0.0 1.1.1.2 ip route 0.0.0.0 0.0.0.0 2.2.2.2 10 R2 router tunnel interface settings:
interface GigabitEthernet0/0 ip address 192.168.2.1 255.255.255.0 ! interface GigabitEthernet0/1 ip address 3.3.3.1 255.255.255.252 ! interface Tunnel1 ip unnumbered GigabitEthernet0/0 tunnel source 3.3.3.1 tunnel mode ipsec ipv4 tunnel destination 1.1.1.1 tunnel path-mtu-discovery tunnel protection ipsec profile ipsec-prof ! interface Tunnel2 ip unnumbered GigabitEthernet0/0 tunnel source 3.3.3.1 tunnel mode ipsec ipv4 tunnel destination 2.2.2.1 tunnel path-mtu-discovery tunnel protection ipsec profile ipsec-prof ! ip route 0.0.0.0 0.0.0.0 3.3.3.2 For the presented configuration, the tunneled traffic will be distributed across the R1 Internet service providers as follows:
IPsec-packets Tunnel2 from R1 to R2 have the source IP address 2.2.2.1, but pass through the channel of the first ISP1 Internet service provider. Some Internet providers block traffic with source IP addresses belonging to "foreign" Internet providers. If the provider does this check, Tunnel2 will not install (therefore, part of the Tunnel2 line from R1 to R2 is shown in dotted lines).
VRFs, to which Internet service providers connect channels and in which tunnelled (in particular, encrypted) traffic appears, are called FVRF - Front-door VRF. If IPsec is correctly configured with VRF, we get a connection between IVRF and FVRF using IPsec. In other words, the protected traffic enters the IVRF, and after encapsulation in the tunnel it automatically turns into FVRF, in which other routing rules are applied. And it is very convenient.
I turn to the description of my example. There is a distributed network. At the central office (hereinafter referred to as CO), there are two Internet providers, each of which is connected to its own Cisco router. The first ISP1 ISP is used for VPN to remote offices, the second ISP2 ISP is used to access the Internet. A redundancy protocol for the first HSRP transition is configured between the color routers. In remote offices there are two options for boundary equipment:
- Cisco router. VTI-tunnels are built to such offices.
- Cisco NPE router paired with Cisco ASA. GRE over IPsec tunnels are built up to such offices. GREs are terminated on routers and encrypted in IPsec on the Cisco ASA.
Network layout:
Routes are routed via EIGRP between the central office and remote offices. If ISP1 or R1 fails, all traffic goes to ISP2 and R2. In the event of ISP2 or R2 failure, Internet access is provided via ISP1 and, accordingly, R1. This scheme is implemented by EIGRP, HSRP and PBR. PBR is used to redirect traffic to the Internet through ISP2. PBR is configured using ISP2 health tracking (IP SLA PBR Object Tracking).
Task
In the CO, the third ISP3 ISP is connected to the router R1. It is necessary to distribute traffic across the tunnels through ISP1 and ISP3 of router R1. Also, it is necessary to comply with some of the requirements for fault tolerance by the Internet providers of the DH and the routers of the DH. I will not describe all the failure options, I will mention only the most important requirement: ISP1 provider, which runs normal traffic to remote offices (green tunnels in the diagram), should remain as unloaded as possible. That is, in case of ISP2 failure, Internet access should switch to ISP3, and in case of ISP3 failure, the traffic of the implemented service (red tunnels in the diagram) should switch to ISP2.
Network layout with regard to the new channel (ISP3):
Decision
Short description
Since R1 in normal network operation (when all Internet providers are working) must terminate VPN IPsec tunnels on both Internet providers simultaneously (ISP1 and ISP3), it was decided to make the connection to the new ISP3 Internet provider in a separate FVRF. At the same time, it was decided to leave the protected (local) networks and the connection to the first Internet provider in the global VRF.
After correct configuration of IPsec together with FVRF, we have parallel workable tunnels through IPS1 and IPS3. An example IPSec configuration with FVRF will be discussed in the next section. It now remains to distribute traffic flows through the existing tunnels. To solve this problem, we can distinguish the following approaches:
- Equal Cost Multi Path (ECMP). Tunnel balancing using routes with the same metric;
- To route different IP subnetworks of the DH and / or remote offices through different tunnels;
- Performance Routing (PfR);
- Policy Based Routing (PBR);
- Use Network Address Translation (NAT) to allocate specific IP addresses and configure routing for these specific IP addresses.
For my task, the last option was the most preferable - an approach using NAT. This option allows on the one hand to rigidly define the distribution of traffic across tunnels (as opposed to ECMP and PfR), on the other hand, to reduce the number of configuration lines (as opposed to PBR). Consider it in more detail.
On the Central Office Routers we configure the dynamic policy NAT network address translation rule. We use this rule to change the IP addresses of the CO computers to some “special” IP address when they access some previously known servers in remote offices. We use policy NAT to change the IP addresses of clients only when referring to known IP addresses of servers. Next, using the EIGRP setting, we distribute to the remote offices a “special” IP address with the best metric via ISP3 tunnels, and for tunnels through ISP1, which must be unloaded, on the contrary, we overestimate the metric for the “special” IP address.
Thus, the request from the clients of the CO arrives at the server in the remote office with the changed source IP address. In response, the server generates traffic to the changed IP address, and the router in the remote office routes this traffic flow to the required tunnel. At the same time, routers in remote offices do not require additional routing configuration: route management is performed via EIGRP from the console of the DH routers. Below is a request / response flow diagram. The real IP address of the client: 192.168.1.100. The “special” IP address to which the IP address of the client is converted: 10.10.10.10. Server IP address in remote office: 172.16.1.100.
Asymmetric routing
The diagram shows that we allow asymmetric routing: requests go through ISP1 tunnels, responses are returned through ISP3 tunnels. In normal operation, this scheme suits. But asymmetric routing is almost always ready to bring problems. Not without difficulties and with us.
Imagine a scheme when ISP1 fails. In this case, requests begin to go through router R2 and ISP2 tunnels, and the request / response flow diagram takes the following form:
The diagram shows that for request packets, the source IP address translation is performed on router R2. Response packets come through the ISP3 tunnels on router R1. However, in order to perform the UNNAT procedure and convert the recipient's IP address to the real client IP address, you have to send packets back to R2.
In order for the UNNAT procedure on R2 to be successful, the response packets must first go to the router interface that has the ip nat outside directive, and then to the interface that has the ip nat inside directive. The interface with the ip nat outside directive is the Loopback interface. The interface with the ip nat inside directive is the internal interface of the router connected to the core network switches. If you redirect traffic from router R1 to router R2 through the existing internal interfaces connected to the core network switches, the packets follow the following path: R2 internal interface with ip nat inside, R2 Loopback interface with ip nat outside and back to R2 internal interface c ip nat inside. From the point of view of NAT, the trajectory looks like: ip nat inside -> ip nat outside -> ip nat inside. UNNAT did not work. It was necessary to exclude the first ip nat inside, that is, the entry of packets subject to UNNAT through the existing internal interface of router R2. I had to configure an additional logical subinterface on R2 that does not have ip nat inside directives to receive traffic from R1 subject to UNNAT, and to configure the corresponding routing rules on R1.
Imagine a scheme when ISP1 fails. In this case, requests begin to go through router R2 and ISP2 tunnels, and the request / response flow diagram takes the following form:
The diagram shows that for request packets, the source IP address translation is performed on router R2. Response packets come through the ISP3 tunnels on router R1. However, in order to perform the UNNAT procedure and convert the recipient's IP address to the real client IP address, you have to send packets back to R2.
In order for the UNNAT procedure on R2 to be successful, the response packets must first go to the router interface that has the ip nat outside directive, and then to the interface that has the ip nat inside directive. The interface with the ip nat outside directive is the Loopback interface. The interface with the ip nat inside directive is the internal interface of the router connected to the core network switches. If you redirect traffic from router R1 to router R2 through the existing internal interfaces connected to the core network switches, the packets follow the following path: R2 internal interface with ip nat inside, R2 Loopback interface with ip nat outside and back to R2 internal interface c ip nat inside. From the point of view of NAT, the trajectory looks like: ip nat inside -> ip nat outside -> ip nat inside. UNNAT did not work. It was necessary to exclude the first ip nat inside, that is, the entry of packets subject to UNNAT through the existing internal interface of router R2. I had to configure an additional logical subinterface on R2 that does not have ip nat inside directives to receive traffic from R1 subject to UNNAT, and to configure the corresponding routing rules on R1.
Configuration description
DH IP Addressing:
| Internal network: | 192.168.1.0/24 |
| Connection to ISP1: | 1.1.1.1/30, Gateway 1.1.1.2 |
| Connection to ISP2: | 2.2.2.1/30 gateway 2.2.2.2 |
| Connection to ISP3: | 3.3.3.1/30 gateway 3.3.3.2 |
| Client IP Address: | 192.168.1.100 |
IP addressing of remote office type 1 (VTI-tunnels):
| Internal network: | 172.16.1.0/24 |
| Connection to ISP: | 4.4.4.1/30 gateway 4.4.4.2 |
| Server IP Address: | 172.16.1.100 |
IP addressing of a remote office type 2 (GRE over IPsec tunnels):
| Internal network: | 172.16.2.0/24 |
| Connection to ISP: | 5.5.5.1/30 Gateway 5.5.5.2 |
| Subnet between the router and Cisco ASA: | 6.6.6.2 - router 6.6.6.1 - Cisco ASA mask 255.255.255.252 |
| Server IP Address: | 172.16.2.100 |
Network layout:
Consider the configuration of router R1. First, I will give an example of setting up VPN tunnels to remote offices of type 1 (VTI-tunnels) and type 2 (GRE over IPsec tunnels). On the diagram and in the configuration I use the following notation of VPN tunnels:
- Tunnel 10 - VTI-tunnel through ISP1;
- Tunnel 11 - VTI-tunnel through ISP3 configured using VRF;
- Tunnel 20 - GRE over IPsec tunnel through ISP1;
- Tunnel 21 - GRE over IPsec tunnel through ISP3 configured using VRF.
Configure VRF and interfaces:
! VRF - ISP3 ip vrf ISP3-vrf ! ! - ISP3 interface GigabitEthernet0/2 description === ISP3 === ip address 3.3.3.1 255.255.255.252 ip vrf forwarding ISP3-vrf ! ! - ISP3 ip route vrf ISP3-vrf 0.0.0.0 0.0.0.0 3.3.3.2 ! ! HSRP interface GigabitEthernet0/0 description === LAN === ip address 192.168.1.2 255.255.255.0 standby 1 ip 192.168.1.1 standby 1 priority 105 standby 1 preempt ! ! - ISP1 interface GigabitEthernet0/1 description === ISP1 === ip address 1.1.1.1 255.255.255.252 ! ! - ISP1 ip route 0.0.0.0 0.0.0.0 1.1.1.2 Setting up a VTI tunnel through an ISP1 provider to communicate with remote type 1 offices.
! ISAKMP crypto isakmp policy 10 encr aes hash sha authentication pre-share group 2 ! ! Pre-shared key crypto isakmp key STRONGKEY address 4.4.4.1 no-xauth ! ! IPsec crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac mode tunnel ! ! IPsec crypto ipsec profile VTI set transform-set ESP-AES-SHA ! ! VTI interface Tunnel10 description === To office Type 1 over ISP1 === ip unnumbered GigabitEthernet0/0 tunnel source 1.1.1.1 tunnel mode ipsec ipv4 tunnel destination 4.4.4.1 tunnel path-mtu-discovery tunnel protection ipsec profile VTI Setting up a VTI tunnel through an ISP3 provider in the new VRF “ISP3-vrf” for communication with remote offices of type 1.
! Keyring crypto keyring office1-keyring vrf ISP3-vrf pre-shared-key address 4.4.4.1 key STRONGKEY ! ! ISAKMP crypto isakmp policy 10 encr aes hash sha authentication pre-share group 2 ! ! ISAKMP crypto isakmp profile office1-ike-prof keyring office1-keyring match identity address 4.4.4.1 255.255.255.255 ISP3-vrf isakmp authorization list default local-address GigabitEthernet0/2 ! ! IPsec crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac mode tunnel ! ! IPsec crypto ipsec profile office1-ipsec-prof set transform-set ESP-AES-SHA set isakmp-profile office1-ike-prof ! ! VTI. ISP3-vrf interface Tunnel11 description === To office Type 1 over ISP3 === ip unnumbered GigabitEthernet0/0 tunnel source 3.3.3.1 tunnel mode ipsec ipv4 tunnel destination 4.4.4.1 tunnel path-mtu-discovery tunnel vrf ISP3-vrf tunnel protection ipsec profile office1-ipsec-prof Setting up a GRE over IPsec tunnel through an ISP1 provider to communicate with remote type 2 offices.
! ISAKMP crypto isakmp policy 10 encr aes hash sha authentication pre-share group 2 ! ! Pre-shared key crypto isakmp key STRONGKEY address 5.5.5.1 no-xauth ! ! IPsec crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac mode tunnel ! ! - crypto map CMAP 10 ipsec-isakmp description === To office Type 2 over ISP1 === set peer 5.5.5.1 set transform-set ESP-AES-SHA match address cryptomap_10_acl ! ! GRE interface Tunnel520 description === To office Type 2 over ISP1 === ip unnumbered GigabitEthernet0/0 keepalive 10 3 tunnel source 1.1.1.1 tunnel destination 6.6.6.2 tunnel path-mtu-discovery ! ! -ACL ip access-list extended cryptomap_10_acl permit gre 1.1.1.1 host host 6.6.6.2 ! ! - ISP1 interface GigabitEthernet0/1 crypto map CMAP Setting up a GRE over IPsec tunnel through an ISP3 provider in the new “ISP3-vrf” VRF to communicate with remote type 2 offices.
crypto keyring office2-keyring vrf ISP3-vrf pre-shared-key address 5.5.5.1 key STRONGKEY ! ! ISAKMP crypto isakmp policy 10 encr aes hash sha authentication pre-share group 2 ! ! ISAKMP crypto isakmp profile office2-ike-prof vrf ISP3-vrf keyring office2-keyring match identity address 5.5.5.1 255.255.255.255 ISP3-vrf isakmp authorization list default ! ! IPsec crypto ipsec transform-set ESP-AES-SHA esp-aes 256 esp-sha-hmac mode tunnel ! ! - crypto map CMAP-vrf 10 ipsec-isakmp description === To office Type 2 over ISP3 === set peer 5.5.5.1 set transform-set ESP-AES-SHA set isakmp-profile office2-ike-prof match address cryptomap-vrf_10_acl ! interface Tunnel21 description === To office Type 2 over ISP3 === ip unnumbered GigabitEthernet0/0 keepalive 10 3 tunnel source 3.3.3.3 tunnel destination 6.6.6.2 tunnel path-mtu-discovery tunnel vrf ISP3-vrf ! ! -ACL ip access-list extended cryptomap-vrf_10_acl permit gre 3.3.3.3 host host 6.6.6.2 ! ! - ISP3 interface GigabitEthernet0/2 crypto map CMAP-vrf By the given examples, VPN-tunnels to all remote offices are configured. The VPN tunnel settings on router R2 in the central location and on routers and Cisco ASA in remote offices will not be considered because they are trivial.
Now that the VPN tunnels to all remote offices are ready, we can proceed to the consideration of routing settings. The network uses EIGRP. First, you need to configure the dynamic policy NAT rules to allocate clients for the system being implemented.
! Loopback NAT ! interface Loopback1 description ===For System-Servers routing=== ip address 10.10.10.10 255.255.255.255 ! ! IP- object-group network System-Servers description === System-Servers === host 172.16.1.100 host 172.16.2.100 ! ! NAT ip access-list extended NAT-System-Servers permit ip any object-group System-Servers ! ! NAT route-map RM-NAT-System-Servers permit 10 match ip address NAT-System-Servers ! ! dynamic policy NAT ip nat inside source route-map RM-NAT-System-Servers interface Loopback1 overload ! ! ip nat inside ip nat outside interface GigabitEthernet0/0 ip nat inside ! interface Tunnel10 ip nat outside ! interface Tunnel11 ip nat outside interface Tunnel20 ip nat outside interface Tunnel21 ip nat outside These NAT settings result in the conversion of client IP addresses to a “special” IP address on 10.10.10.10 when accessing servers at remote offices.
It remains to configure EIGRP on the router in the central office so that the network on 10.10.10.10/32 is announced to remote offices with the best metric through ISP3 provider tunnels. In our example, this is Tunnel 11 and Tunnel 21. To control the EIGRP metric, I decided to use the offset-list construct. Let me remind you that using the offset-list directive you can add the specified value to the advertised route metric. EIGRP Settings:
access-list 10 permit 10.10.10.10 ! router eigrp 1 network 192.168.1.0 0.0.0.255 offset-list 10 out 3000000 Tunnel10 offset-list 10 out 3000000 Tunnel20 passive-interface default no passive-interface Tunnel10 no passive-interface Tunnel11 no passive-interface Tunnel20 no passive-interface Tunnel21 no passive-interface GigabitEthernet0/0 The described configuration makes the procedure for adding new servers in remote offices, the traffic from which should be routed through the tunnels of the new ISP3 DH provider, is as simple as possible. When a new server appears, it is enough to add its IP address to the System-Servers object group:
! IP- object-group network System-Servers description === System-Servers === host 172.16.1.100 host 172.16.2.100 This concludes my consideration of the configurations of the R1 DH router. The configuration of R2 router in the central office and the configuration of network devices in remote offices are not of interest in this article.
Conclusion
Sometimes a simple and logical task is put before a network engineer, but solving a problem leads to the formation of relatively complex configurations. In my example, an elementary task was considered: to connect a new Internet service provider to the existing router and start using it the traffic of some services from remote offices. However, to solve this problem, it was necessary to split the router into a VRF, prescribe tricky rules for IP address translation, correct dynamic routing settings, correct the effects of asymmetric routing.
Using this task as an example, I considered using Front-door VRF to build IPsec tunnels. In addition, I showed the option of centralizing routing settings for the star topology using NAT rules. Front-door VRF for building IPsec is a convenient tool that allows you to build a bridge for transferring traffic between the router's VRF: the protected traffic can be in IVRF or global VRF, and the encapsulated (encrypted) traffic is in FVRF. FVRF has its own routing rules, which makes it possible to send FVRF traffic through additional communication channels, in particular, through an additional Internet service provider.
Source: https://habr.com/ru/post/302772/
All Articles