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 later 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.
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 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.
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.