VRF Series Article 5 – Stateful Inter-Vrf connectivity

This is the fifth and final article in a series that focused on Segmenting Layer 3 Networks with VRFs. In the third article, we discussed creating a shared services VRF and using it within the otherwise segmented network. In that article I alluded to the fact that we would asav-1later cover a way to securely allow traffic to flow between security zones. That is the intent of this article.

In this article, I am going to attach two sub interfaces between asav-1 and Main. One will attach into data and the other into pci. We will apply a simple policy that denies all traffic from data to pci, but allows telnet from pci to data (bad security example, but easy to demonstrate).

Before we jump into the configuration, I want to share the entire topology and give a summary of the current configuration status.

VRF_No_Int_Index

Current Configuration

In the above topology, anything that starts with “data” is in the data VRF. Likewise, anything that starts with “pci” is in the pci VRF. Everything within a given VRF can communicate with everything else in that same VRF. Both pci and data can communicate with the shared VRF (test IP address is 10.199.199.1). The pci and data VRFs cannot communicate with one another.

The first step in allowing pci and data to statefully communicate is to connect the firewall (asav-1) to Main.

Main — configuration to connect to asav-1

//configure the interfaces
interface GigabitEthernet4
 description to asav-1
 no ip address
 no shut
interface GigabitEthernet4.100
 description to asav-1 data
 encapsulation dot1Q 100
 vrf forwarding data
 ip address 10.100.134.2 255.255.255.0
interface GigabitEthernet4.200
 description to asav-1 pci
 encapsulation dot1Q 200
 vrf forwarding pci
 ip address 10.200.134.2 255.255.255.0

//add the new interfaces to the EIGRP processes  
router eigrp NAMEDMODE
!
 address-family ipv4 unicast vrf data autonomous-system 1
  network 10.100.134.0 0.0.0.255
 exit-address-family
 !
 address-family ipv4 unicast vrf pci autonomous-system 1
  network 10.200.134.0 0.0.0.255
 exit-address-family

asav-1 — configuration

interface GigabitEthernet0/0
 description to Main
 no nameif 
 no ip address
interface GigabitEthernet0/0.100
 vlan 100
 description to Main data
 nameif data 
 ip address 10.100.134.1 255.255.255.0
 security-level 50
interface GigabitEthernet0/0.200
 vlan 200
 description to Main pci
 nameif pci
 ip address 10.200.134.1 255.255.255.0
 security-level 50

//make sure same into levels can communicate
same-security-traffic permit inter-interface

//configure the routing process (note this will merge eigrp
//pci and data and double the table on the other devices
router eigrp 1
 network 10.100.134.0 255.255.255.0
 network 10.200.134.0 255.255.255.0

//configure and apply the acls
access-list pci_interface_in permit tcp any 10.100.0.0 255.255.0.0
access-list data_interface_in deny ip any any

access-group pci_interface_in in interface pci
access-group data_interface_in in interface data

pci-3 testing telnet to data-1 (should succeed)

pci-3#telnet 10.100.129.11
Trying 10.100.129.11 ... Open

User Access Verification

Username: cisco
Password:


data-1#

data-1 testing telnet to pci-3 (should fail)

data-1#telnet 10.200.132.11
Trying 10.200.132.11 ...
% Connection timed out; remote host not responding

data-1#

Observing Routes in BrWan

BrWan#show ip route vrf pci | beg Gateway
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 20 subnets, 3 masks
D        10.100.100.0/24
           [90/21120] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.128.0/30
           [90/25600] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.129.0/24
           [90/30720] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.130.0/24
           [90/30720] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.131.0/24
           [90/25600] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.132.0/24
           [90/76825600] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.133.0/24
           [90/76820480] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D        10.100.134.0/24
           [90/20480] via 10.200.128.1, 00:19:28, GigabitEthernet2.200
D EX     10.199.199.0/24
           [170/61440] via 10.200.128.1, 12:56:03, GigabitEthernet2.200
D        10.200.100.0/24
           [90/10880] via 10.200.128.1, 22:46:07, GigabitEthernet2.200
C        10.200.128.0/30 is directly connected, GigabitEthernet2.200
L        10.200.128.2/32 is directly connected, GigabitEthernet2.200
C        10.200.129.0/24 is directly connected, GigabitEthernet3.201
L        10.200.129.1/32 is directly connected, GigabitEthernet3.201
C        10.200.130.0/24 is directly connected, GigabitEthernet3.202
L        10.200.130.1/32 is directly connected, GigabitEthernet3.202
D        10.200.131.0/24
           [90/15360] via 10.200.128.1, 02:20:25, GigabitEthernet2.200
D        10.200.132.0/24
           [90/76815360] via 10.200.128.1, 01:34:34, GigabitEthernet2.200
D        10.200.133.0/24
           [90/76810240] via 10.200.128.1, 01:49:57, GigabitEthernet2.200
D        10.200.134.0/24
           [90/15360] via 10.200.128.1, 00:25:59, GigabitEthernet2.200

As can be seen above, all the routes exist for pci. The same is true for data, I just didn’t want to post that much redundant information. So the route tables are twice as large when we advertise the routes across the FW into the opposing VRF.

For one final test, let’s go back and test the other original isolation requirements.

data-1

//data to data
data-1#ping 10.100.130.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.130.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/23 ms

//data to shared
data-1#ping 10.199.199.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.199.199.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/10/14 ms

//data to pci
data-1#ping 10.200.129.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.129.11, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Those paying very close attention may notice the difference in the last result now. In previous cases the failure displayed U.U.U. The difference now is that the next hop router is no longer producing an unreachable. Now their is a valid route and traffic is flowing all the way to the Firewall (asav-1) and being silently dropped.

The configuration and VIRL files for this exercise can be found at the URL below.

Conclusion

This article demonstrates the ability to connect a firewall between two VRFs to provide stateful inter-VRF connectivity. This is a method of allowing different security zones to communicate while applying policy to the traffic. As with any solution, these methods should be leveraged, as appropriate, to meet a given organizations business and technology requirements.

This article also wraps up our five part series on Segmenting Layer 3 Networks with VRFs. If you have enjoyed this series, please share the content as you deem beneficial to others.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

2 Responses to VRF Series Article 5 – Stateful Inter-Vrf connectivity

  1. Pingback: Segmenting Layer 3 Networks with VRFs - PacketU

  2. Pingback: VRF Series Article 3 - Creating a Shared Services VRF - PacketU

Comments are closed.