NSX Firewall forwarding to 3rd generation physical FW

[andres_prieto_a]

Hi

We want to implement NSX for distributed firewall for layer 3-4 to perform microsegmentation, but we would like to forward L6-L7 to a 3rd generation FW for few VMs, not all of them.

Is it possible to redirect those to a physical FW or it's a must to have the NGFW appliance on the host for doing it?

We assume that going to the external FW it will have performance impact and delay.

Regards

[showard1]

Hi Andres

In theory it is totally possible for a 3rd party vendor (i.e. Palo Alto Networks, Checkpoint, etc) to produce a service insertion module that redirects DFW traffic from a dvfilter slot to a physical firewall.  However, as far as I know, no 3rd party vendor has actually done this.  All of the customers I have worked with that are using 3rd party solutions for L7 inspection use the "NGFW appliance VM per host" model and redirect to that local VM.  Partly because of latency issues with leaving the host, and partly because the distributed model makes so much sense - if each host has an NGFW appliance that does 5Gb/s IDS/L7 inspection (which I have seen the McAfee appliance do), and you have 20 hosts... that's effectively a 100Gb/s IDS/L7... if you have 50 hosts, its a 250Gb/s and so on.  The numbers reach a point where through sheer volume hardware NGFWs are less appealing.

Hopefully that helps.  If you have a particular NGFW vendor in mind, I would suggest reaching out to your rep with them and asking about their plans to support the redirection you want.  Its up to them to build that (for the most part) - we just provide the platform to do so.

Thanks

Sean 

[MiKaVienna]

Hi Sean,

I like to muse about problems which I don't have.

What you write sounds quite interesting but I don't quite understand your sentence:

In theory it is totally possible for a 3rd party vendor (i.e. Palo Alto Networks, Checkpoint, etc) to produce a service insertion module that redirects DFW traffic from a dvfilter slot to a physical firewall.  However, as far as I know, no 3rd party vendor has actually done this.

Service insertion e.g. network inspection rules for NSX registered services is quite clear because the third-party-VM handling the traffic has all the information to process packets statefully in an "inline-fashoin" and feed any packet surviving the third-party-service to the next service in the chain. This might become a little bit of a challenge when traffic is redirected to an external firewall, the traffic being forwarded to an external physical firewall lacks all the -let's call it- meta information of the NSX-world, like the originating or terminating VM, ESXi-host, Logical Switch, DLR LIF, next service in chain and how to reach it, etc...

Another challenge for an external physical firewall would be to solve local routing or some deterministic forwarding path. At least for anything close to a traditional firewall it would be impossible to receive and send out traffic on the same interface. Anything in the forwarding path would require an ingress and egress interface, be it layer 3 (which wouldn't be possible for a network introspection rule because you would introduce a layer three device between the VM and its next hop) or a layer 2 in which case an external firewall in transparent mode would at least need to distinguish between two distinctive broadcast domains which don't exist.

Sounds interesting to me.

Best regards,

MiKa

[showard1]

the traffic being forwarded to an external physical firewall lacks all the -let's call it- meta information of the NSX-world, like the originating or terminating VM, ESXi-host, Logical Switch, DLR LIF, next service in chain and how to reach it, etc...

Sure.  But this is also a problem for 3rd party services that use VMs on each host to process the flows to a certain extent.  Generally the approach is to use that vendor's version of a "vCenter" (i.e. Panorama for Palo Alto Networks) and have it synchronize metadata type stuff via vCenter/NSX APIs.  Its totally up to that vendor how they want to go about that, and I've seen several very different approaches.

A bigger challenge IMO is the fact that you'd essentially need to block further processing of packets until each one (or bundle of them) is returned by the hardware appliance - or risk them getting out of order.  If a VM local to the host slows way down, for congestion or whatever, it only affects that host.  If some central device chokes, now all VMs on all hosts add 5ms latency or whatever - no bueno.  It also breaks the distributed model wrt scaling/maintenance windows/etc - which IMO is one of the biggest value adds of the "all virtual" approach.

Anything in the forwarding path would require an ingress and egress interface, be it layer 3 (which wouldn't be possible for a network introspection rule because you would introduce a layer three device between the VM and its next hop) or a layer 2 in which case an external firewall in transparent mode would at least need to distinguish between two distinctive broadcast domains which don't exist.

Definitely would be a headache.  They'd probably come up with some kind of encapsulation to include "real" source/dest and all the stuff related to just getting the flow back where it came from.

I've had a number of large customers say they'd really like this capability.  Usually the big reason is because they already own a bunch of physical firewalls that they use for East/West traffic and they don't want to feel like they're being wasted.  Once I break down how even if your vendor of choice implemented it, there'd be all these downsides they tend to change their minds.  There's lots of possible uses for existing FW hardware aside from this, and we're by no means saying throw that stuff out.

I'd still like to see Palo Alto or Cisco or someone implement it, though, just because it would be cool to see how they solved all the problems:)