Passing off VRF's to an MX

[nickydd9]

Hey all,

Hopefully this question hasn't already been asked but looking for some insight / advice on the following. I am being tasked with installing a pair of Meraki firewalls in high availability at a client site, and we are going to be using the clients switching infrastructure for our hosts on the network, and the firewalls themselves will live at the campus edge. 

The client uses almost no Layer 2 and are running almost solely with VRF's to segment traffic. They mentioned that they wish to create as many VRF's as necessary to mirror our VLAN scheme we presently use in other sites (CORP, IOT, Surveillance). 

I have little to no understanding as to how I should be configuring the firewalls to support this passoff of VRF's to the Meraki MX. On the MX I see I can create virtual interfaces tied to VLAN IDs so am I still to configure that in this scenario? Then do I just ensure that the client connects an Ethernet handoff configured for the CORP VRF they create  to an access port on the MX configured for the CORP VLAN? When I create a VLAN virtual interface it automatically adds that route to that configured subnet to the route table so I don't think I need to do any static routing either to get this to work I wouldnt think. 

Also side note, if my thinking above is correct, does this also mean I could technically use a single ethernet handoff to a port on the MX I configure as a trunk to carry all the VLANs? Or will this not work because with VRF's traffic will not have a VLAN tag when it enters the trunk from the clients Layer 3? 

Any tips or recommendations are greatly appreciated. 

[PhilipDAth]

Interesting choice of VRFs for the scenario mentioned.  I'm going to have to make lots of assumptions as to why VRFs were used.

Is there any inter-vrf routing happening?

Assuming no inter-vrf routing, and that VRFs are being used for complete segration, you are going to need a pair of MXs per VRF.

[nickydd9]

Hi Philip,

Thanks for replying! The choice to use VRF is not mine, it is the client's. They are not willing to allow me to put my own switches in their physical space and thus I must run on their Layer 3 switching environment. 

There should be no inter-vrf routing as the whole point of the topology is to keep traffic segmented. I should have mentioned that there is also a point-of-sale VRF in addition to the ones I mentioned prior, so in the interest of PCI compliancy we need to keep traffic from the cardholder data environment segmented. 

Let's take out the high-availability component for the sake of simplicity in this discussion. It then becomes a single MX per VRF? 

Can you elaborate any further on why an MX can't handle the pass off of multiple segmented VRF's?

[CptnCrnch]

Perhaps I‘m missing something but from my point of view this should be rather trivial:

Each VRF needs to have its own transfer net to a specific VLAN interface on your MX pair and point its default route to the MX. Everything inside the specific VRF will stay inside its own routing table, inter-VRF traffic and everything going to the „outside world“ will then be routed via your MX pair.

Of course, you‘ll have to set up routing on the MX side accordingly. Overlapping IP spaces are an obvious no-go in this scenario 

[nickydd9]

Hello!

So what you are saying is that I should still setup my VLAN interfaces on the MX and make at least one access port for each of these VLANs. The client then needs to provide an ethernet handoff that passes that specific VRF across to the MX and ensure it is patched to the proper access port configured to be for the matching VLAN on the MX? 

Yes and then from their the MX can handle routing, I can make my own L3 firewall rules to deny inter-VLAN routing as I see fit and filter specific traffic to the outside world. 

Yes there will be no overlapping subnets in place here, all unique subnetting per-each VRF. 

If I am mistaking anything please let me know. Is there a way to condense multiple handoffs down to a single link? Perhaps the client can configure their interface closest to the MX as a trunk and somehow tag the VRFs with a VLAN ID to carry those VLANs across to a trunk port on my side? Forgive me if this is entirely incorrect, I have next to no experience with VRFs in practice. 

[PhilipDAth]

>Can you elaborate any further on why an MX can't handle the pass off of multiple segmented VRF's?

MX has no support for VRFs.  Sure it supports VLANs, but VRFs are not the same thing as VLANs.

If you want to maintain layer 3 segmentation and want to maintain the spirit of VRFs you will need an MX per VRF.  You may well talk to the MX using tagged frames, but that in itself is just an access to a VRF - not a VRF in itself.

[nickydd9]

@PhilipDAth, I see.

That is really all I am trying to accomplish. I don't wish to incorporate the VRF's into my MX, I just wish for the traffic to remain segmented as the VRF's are doing downstream and have the traffic pass across to the MX and be tagged for the appropriate VLAN. So correct, access to each VRF is what I seek.

[PhilipDAth]

Do you plan for the MX to operate transparently (like a bridge/switch), or be a layer 3 device with a subnet behind it?

[nickydd9]

I plan for this MX to be able to do it's own routing and serve as the DHCP server for various subnets (one for each downstream VRF)

[PhilipDAth]

In that case create a simple untagged layer 3 interface on your device, and place it in the appropriate VRF.  Plug the MX WAN port into this.

You can then plug the MX LAN interfaces into any internal switching using any internal VLAN you want.

Note that the MX will NAT will internal VLANs to the IP address on its WAN interface.  There is a no-nat feature in beta if this is no desirable.

Also it will be critical that the WAN interface of the MX can reach the Meraki cloud.

[nickydd9]

But the VRF's (and the client switching environment) is downstream of my MX so they need to connect to the MX LAN ports. The MX WAN port is already connected to the client's ASA who is acting as a service provider for our internet at this site. 

Diagram for clarity:

[PhilipDAth]

Without the Meraki, how is the ASA plumbed in?  A VLAN per VRF, or a single interface attach to the global VRF (or some other VRF)?

What is the Meraki going to be used for?  Just monitoring and some security and content filtering, or do you also want to run AutoVPNs to it?

[nickydd9]

I am unsure about the ASA configuration, it is the clients. They provide us a 1:1 NAT for our WAN connection at this site. Public IP NAT'ed to the shared virtual IP for high availability MXes.

The MX pair is going to be used for monitoring, security & content filtering, normal firewall stuff. There will be no AutoVPN's save for one that we would use for our Syslog VLAN to export logs to Splunk in our datacenter. 

[PhilipDAth]

I would say whatever configuration you have on your side facing towards the ASA - it will the same as facing towards the MX.

[YaroslavS]

So this thread is old thread and likely not actively monitored any more. I did want to add to the converstaion that the "ASA" in the topology that is pictured, was likely running "Multi-context" mode which would allow for the "VRF like" functionality since each context is using it's own routing table.

In essence, the each VRF that was defined in the traditional Cisco switch, would have an ASA context as it's L3 neighbor.

Example:

ASA-PCI 192.168.0.1/24

ASA-Prod 10.0.0.1/24

Core-VSS PCI VRF 192.168.0.2/24

Core-VSS Prod VRF 10.0.0.2/24

In the above example, the Core-VSS switch likely did not allow for communication between the VRFs by the lack of routes between them.

The effect of all of the above is that even though there is shared physical infrastructure in place, there is FULL logical separation of the environments.

[Uberseehandel]

As far as I am aware VRF uses 802.1Q trunks. Is there a danger we are over thinking this issue?