ENGYAK.co Logo
ENGYAK.co

Securing Dual-Stack (IPv4,IPv6) Endpoints with NSX-T

I have mentioned in a previous blog post that I’m not using any ACLs on my tunnel broker VM

This is usually pretty bad, but again, we can get those protections outside of the VM - I’m using this to prove out how NSX-T can provide utility in this situation.

Solution Overview

VyOS is a fantastic platform, with a ton of rich, extensive features that can empower any network engineer to achieve greater outcomes. There’s a lot of good stuff - here I’m using it as a tunnel broker, but we also have these other features:

Manageability

Functionality

It’d be fair to say that VyOS is a fantastically capable router, which like Cisco ISR or any other traditional router, does have some downsides.

What’s Missing - or What Could Be Easier

Just as a caveat, I do think we’ll see this a lot with virtualized routing and switching.

VyOS has always had a bit of a problem with firewalling. I’ve been using it since it was simply Vyatta, prior to Brocade’s acquisition, and the primary focus of the platform has always been high-quality routing and switching. Functions like NAT and firewalling are disabled by default and have an extremely obtuse, Layer-4 centric interface for creating new rules. This gets messy pretty quickly, as the rules themselves consume significant configuration space and have to be carefully stacked to apply correctly. This interface is manageable but becomes difficult at scale.

Of course, if it was my entire job to manage firewall policies, I’d automate baseline generation and change modifications, the platform is pretty friendly for that. This may not necessarily be maintainable if it’s not placed in an area easily discoverable by other engineers, and definitely doesn’t resemble the “single pane of glass” I’d rather have when running a network.

What I’d like to see is a way to intuitively and centrally implement a set of firewall security policies against this device, in a way that can be centrally audited, managed, and maintained. Keep in mind - the auditing aspect is critically important, as any security control that isn’t periodically reviewed may not necessarily be effective.

Fortunately, VMWare’s NSX (or as it was previously known, vShield) has been doing this for quite some time. There are some advantages to this:

Securing Workloads

First - we need to ensure that the IPv6 tunnel endpoint VM is on a machine that is eligible for Distributed Firewalling. From the NSX-T homepage, click on the VM Inventory:

NSX Inventory

Then we select the IPv6 tunnel VM:

NSX VM List

From here, let’s verify those tags, as we’ll be using that in our security policies:

NSX VM Tags

We also need to add some IP Sets - this is the NSX-T construct that handles non-VM or non-Container addressing for external entities. Technically, East-West Firewalling shouldn’t always be used for this, but IPv6 tunnel brokering is an edge case: (IP Sets guide here)

IP Sets

From here, you want to add the IP Sets to a group via tag membership - a topic I will cover later as it’s vitally important to get right with NSX-T:

NSGroups

We also want to do the same with our virtual machines:

Membership Criteria

Set Applied to

View Members

We’re all set to start applying policies to it! Navigate over to Security -> East-West Firewalling -> Distributed Firewall:

Distributed Firewall

Add these policies. I have obfuscated my actual addresses under groups for privacy reasons.

Add members to rule

Rulebase

That’s about it! If you want to add more tunnel nodes, you’d simply apply the tag to any relevant VM with NSX Manager, and all policies are automatically inherited.

Some Recommendations