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.