VLAN Stitching and VRF Sandwiches¶
Estimated time to read: 10 minutes
- Originally Written: June, 2024
When I first started looking at network diagrams with firewalls I often saw a subnet "stitched" together with multiple VLANs or multiple subnets "sandwiched" between VRFs. The documentation typically showed how it was implemented but not why it was implemented.
Finally someone explained to me that it was to restrict what devices can "see" and thereby force traffic in a desired direction. To expand on that, try looking at forwarding from the perspective of a device holding a packet. If I'm delivering this packet, what information/visibility do I have (e.g. routing table) and how can I get it where it needs to go?
VRF sandwiches with routed firewalls¶
Imagine the following topology with a couple of hosts, a router, and a firewall. The hosts are in different subnets. For configuration simplicity I've removed the switch from my lab deployment
When using a single default VRF on the router both subnets show as locally connected and therefore traffic will be routed by the router and never be sent to the firewall.
How can we force the traffic between the two endpoints through the firewall?¶
This can be achieved by "sandwiching" the firewall between two VRFs on the router. In the new design we've separated the routes into two different VRFs, pink and blue, with each being a separate routing and forwarding instance. When a packet arrives at the router on G2 (pink VRF) destined for the 192.168.20.0 subnet, the only option the router has in the pink routing table is to use GigabitEthernet1 which has been learnt from the ASA. This is the same for the blue VRF.
Essentially we have "restricted" which subnets/routes the router knows about and are forcing traffic to take our desired path through the firewall.
Validating the configuration¶
Default VRF - No traffic sent to the firewall¶
Separate VRFs - Traffic sent to the firewall¶
Example configurations¶
Note
The following configs are used as examples only and not suitable for production. In the ASA config I have set the same security level and same-security-traffic permit inter-interface to allow access as part of the demo
Router
!
version 17.3
!
hostname router
!
vrf definition blue
!
address-family ipv4
exit-address-family
!
vrf definition pink
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet1
vrf forwarding pink
ip address 172.16.10.1 255.255.255.0
!
interface GigabitEthernet2
vrf forwarding pink
ip address 192.168.10.254 255.255.255.0
!
interface GigabitEthernet3
vrf forwarding blue
ip address 192.168.20.254 255.255.255.0
!
interface GigabitEthernet4
vrf forwarding blue
ip address 172.16.20.1 255.255.255.0
!
router ospf 1 vrf pink
network 172.16.10.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
!
router ospf 2 vrf blue
network 172.16.20.0 0.0.0.255 area 0
network 192.168.20.0 0.0.0.255 area 0
!
ip forward-protocol nd
!
end
ASA
!
ASA Version 9.16(2)
!
hostname ciscoasa
!
interface GigabitEthernet0/0
nameif outside
security-level 100
ip address 172.16.10.2 255.255.255.0
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 172.16.20.2 255.255.255.0
!
same-security-traffic permit inter-interface
router ospf 1
network 172.16.10.0 255.255.255.0 area 0
network 172.16.20.0 255.255.255.0 area 0
log-adj-changes
!
: end
VLAN stitching with transparent firewalls¶
You might have see a similar topology to this one where a transparent firewall is placed between two routers. In this example there's only one path and so all traffics flows through the firewall.
However imagine the following topology where a firewall is connected to a switch along with some hosts. The hosts are in the same subnet and VLAN.
192.168.10.1(00:50:56:b6:32:fb) first sends an ARP request for the MAC address of192.168.10.2- This is broadcast (
ff:ff:ff:ff:ff:ff) throughout the VLAN 192.168.10.2responds with its MAC address,00:50:56:b6:0a:cc- The switch learns the interfaces to which the endpoints belong and the endpoints can now communicate with each other.
Note: This example is for illustrative purposes only and may not be a real world use case in traditional switching, although see the Intra-ESG firewall inspection post for how intra-subnet inspection could be implemented in ACI using Policy Based Redirect.
How could we force the traffic between the two endpoints through the firewall?¶
Similar to what we saw with the VRF sandwich, if we could restrict and direct where a broadcast is sent then we could direct traffic through a certain point. In our example this could be achieved with two separate VLANs. As you can see in the following topology I have configured VLAN 10 on one side of the switch while VLAN 20 is on the second side of the switch. Both endpoints are in the same subnet, 192.168.10.0.
There are two interfaces on the firewall connected to the switch. One interface is in VLAN 10 with the first endpoint and the second interface is in VLAN 20 with the second endpoint on the right hand side of the diagram. There is a Bridge Virtual Interface (BVI) configured on the firewall which contains both interfaces as well as an IP address in the same subnet (192.168.10.0/24).
A Bridge Virtual Interface is a software bridge between various interfaces, in this case G0/0 and G0/1 on the ASA. When the BVI is created, the ASA performs bridging (i.e. software based switching) of frames between all member ports in the bridge group. This essentially forms a single broadcast domain.
BVI IP Address
As per the following document, "Each bridge group includes a Bridge Virtual Interface (BVI). The FTD device uses the BVI IP address as the source address for packets originating from the bridge group. The BVI IP address must be on the same subnet as the bridge group member interfaces. "
If you don't configure an IP address on the BVI you may see no traffic passing and the following error.
Since the network is now segmented using two VLANs, when 192.168.10.1 ARPs for the MAC of 192.168.10.2, the broadcast will only reach the vFTD. It has lost "visibility" to the second endpoint and traffic is now forced through the interface of the firewall in VLAN 10.
The vFTD has both interfaces in the same BVI and therefore in the same broadcast domain. It will send the frame to the second interface which is connected to 192.168.10.2 and endpoint 2 will respond to the ARP request. Traffic can then flow between both endpoints but always through the ASA.
Why doesn't traffic flow directly back to Endpoint 1?¶
Although the endpoints have been learnt on multiple interfaces of the switch, the VLAN in which it was learnt is also stored in the MAC address table. The switch uses this information to determine out of which interface the frame should be sent.
Remember that traffic received by a switch which arrives on one VLAN will be forwarded only to ports in the same VLAN unless IP routing is enabled (in this case it's just an L2 switch).
For example, think about an ICMP reply sent from Endpoint 2 to the G0/1 interface and destined for Endpoint 1(52:54:00:17:1f:2a). The frame arrives on a port within VLAN 10. That means the switch will lookup the VLAN 10 MAC address table and see that Endpoint 1 can be reached through interface G0/3 which is connected to the firewall.
Validating the configuration¶
Single VLAN - No traffic sent to the firewall¶
Separate VLANs - Traffic sent to the firewall¶
Example configurations¶
Note
The following configs are used as examples only and not suitable for production. In the ASA config I have set the same security level and same-security-traffic permit inter-interface to allow access as part of the demo
Switch
version 15.2
!
hostname switch
!
interface GigabitEthernet0/0
switchport access vlan 10
switchport mode access
negotiation auto
!
interface GigabitEthernet0/1
switchport access vlan 20
switchport mode access
negotiation auto
!
interface GigabitEthernet0/2
switchport access vlan 10
switchport mode access
negotiation auto
!
interface GigabitEthernet0/3
switchport access vlan 20
switchport mode access
negotiation auto
!
end
ASA
ASA Version 9.16(2)
!
firewall transparent
hostname ciscoasa
!
interface GigabitEthernet0/0
bridge-group 10
nameif outside
security-level 100
!
interface GigabitEthernet0/1
bridge-group 10
nameif inside
security-level 100
!
interface BVI10
ip address 192.168.10.3 255.255.255.0
!
same-security-traffic permit inter-interface
access-list icmp-traffic extended permit icmp any any
access-group icmp-traffic global
: end