VMware NSX: The Good, the Bad and the Ugly

After four live sessions we finished the VMware NSX Technical Deep Dive webinar yesterday. Still have to edit the materials, but right now the whole thing is already over 6 hours long, and there are two more guest speaker sessions to come.

Anyways, in the previous sessions we covered all the good parts of NSX and a few of the bad ones. Everything that was left for yesterday were the ugly parts.

It started with various VPN solutions:

Remote access SSL VPN (called SSL VPN-Plus) requires VMware client on remote systems. It uses TCP transport and thus hits all the usual TCP-over-TCP snags unless you turn on TCP optimization in which case you lose the source IP address of the client (everything seems to be coming from the ESG VM terminating the VPN tunnels).

The most interesting part: you can configure whether you want the traffic to go through the tunnel (I would assume that means encrypt it) or whether it “bypasses the tunnel.”

I tried to find out what means, and all I could find was dozens of blog posts parroting NSX documentation and enhancing it with screenshots, and everyone uses “send traffic over tunnel” setting. No wonder people don’t read blogs…

Anyway, here’s the gem from the documentation that I couldn’t unravel:

Specify whether you want to send private network and internet traffic over the SSL VPN-Plus enabled NSX Edge or directly to the private server by bypassing the NSX Edge.

So I have a remote user, and I have a server on a private network behind NSX edge, and the two would communicate without involving NSX edge. WTF?

If anyone can enlighten me, please write a comment.

IPsec VPN is a bit better (at least it uses standard protocols) but the forwarding model got stuck at the level of crypto maps. They finally implemented an equivalent of Virtual Tunnel Interfaces (VTI) in release 6.4.2, but it cannot be configured through UI – you have to use API. Not exactly the worst thing they could have done, but definitely annoying if you’re a traditional VMware user that tries to stay away from programmability, API or automation as much as possible.

I won’t even comment on L2VPN stretching a VLAN or VXLAN segment across a VPN. It can use SSL VPN (because transporting Ethernet over TCP makes perfect sense), or IPsec VPN (yet again, configurable only through API).

The final part we covered: cross-vCenter and cross-site NSX – another kludge that should never have been released. More about that one in another blog post.

6 comments:

  1. Regarding ssl VPN, maybe they meant something like split tunneling? Or if you had a vpn server living in a VM to bypass the edge services gw? Yeah.. vague documentation.

    Replies
    1. They do split tunneling, but that's another option...

      Thank you!
  2. Does the series cover NSX-V or NSX-T (or both)? From my (somewhat limited) experience there is huge difference...
    Replies
    1. Fair question - at the moment it covers mostly NSX-V (apart from product overview). NSX-T part is planned for early 2019. Fixed webinar description and webinar contents to reflect that.
  3. In your header you forgot: "the price"
  4. Regarding the "send through the tunnel" vs "bypass" - I use this to create exceptions to the networks I allow to simplify my private networks list. For example, If I wanted to provide access over the SSL VPN to all the networks from 172.16.0.0 through 172.16.255.0 EXCEPT 172.16.100.0 I could just add 172.16.0.0/16 as a private network to send over the tunnel but then add 172.16.100.0/24 as a network to bypass the tunnel. Some folks don't like the grouping mechanism because it doesn't easily allow for changes down the road, however.
Add comment
Sidebar