OpenVPN UT11 site-to-site network export

[johndball]

1:On my UT 11 OpenVPN server box, under OpenVPN --> Server --> Exported Networks (tab), do I need to list all of the networks that belong at remote sites in addition to the networks at the server site?
IOW: If my remote site networks are 192.168.2.0 and 192.168.3.0, do I need to put them in the exported network list?

2: Do I need to export the network that OpenVPN is using for its address space?

3: Do I need to use IP address for site-to-site instead of hostnames?


I ask all of this because I have a vCenter server that is running at the host site and is controlling multiple ESXi boxes at the remote site. When I try to do vMotion between two ESXi boxes at the remote site, I error out stating that vCenter couldn't connect to the servers.
This was working all good and well in Untangle 9, but I'm missing something in Untangle 11.

[jcoffin]

Remote networks need to be listed on the client configuration. OpenVPN -> Settings -> Remote Clients -> <name of client> -> Remote Networks

[dmorris]

1) no they are automatically added as configured as jcoffin says
2) no

not sure about #3 off the top of my head. I would use IPs.

[jcoffin]

#3 hostnames will work but IPs will be more reliable.

[sky-knight]

Untangle v11 performs NAT on the OpenVPN connections. I've had bad luck with vCenter over NAT, that being said it "should" work. NAT usually slows it down, not stop it. Get ICMP working first, I suspect you've got something else going on. There are some huge changes in the way OpenVPN in v10 and v11 work, and huge changes in the GUI. There are a few places in there where if you don't forget what v9 did, and you try to emulate v9 bad things will happen.

You need to export any and all IP ranges you want VPN users to be able to reach.
I would stick to using IP addresses until things are stable with them, then worry about getting your DNS fixed so hostnames work.

[johndball]

I nuked my internal DNS settings for the gateways so that everything resolved externally and it made no difference.

Here is something odd: when I added the ESXi hosts to vCenter via IP address:
ESXi hosts on the same subnet (behind the main UT gateway) added to vCenter without any problems and kept their IP.
Gateway: 192.168.12.1
Host: 192.168.12.3

ESXi hosts on the remote site would add to the IP but as soon as vMotion started the ESXi host's IP would change to the primary gateway IP and disconnect.
Remote site gateway: 192.168.8.1
Host: 192.168.8.3 --> changes to 192.168.12.1 when vMotion starts and disconnects from vCenter.

[sky-knight]

http://kb.vmware.com/selfservice/mic...rnalId=1010652

Using NAT between the vCenter Server system and ESXi/ESX hosts is an unsupported configuration. For more information on network requirements, see the Network Prerequisites section under the Prerequisites for Installing vCenter Single Sign-On, Inventory Service, and vCenter Server section in the vSphere Installation and Setup guide.

So, count your configuration one of the many victims of Untangle's decision to force NAT on OpenVPN users. Your only choice is to switch to IPSec, or find a different VPN solution.

There is a workaround that might work, but it's "unsupported" also in the article. As is hacking OpenVPN on current Untangle to not NAT.

For my part over NAT I've been able to manage VMs, but I've never tried vMotion or anything advanced, just power on and settings changes.

[johndball]

I tried the workaround in VMware's KB about setting a persistent server in the vpxa.cfg file to no avail.
Since my UT boxes are VMs, I'm going to deploy two UT 9 boxes and move over to those to see if I can regain vMotion. If I can, I'll just leave the UT9's for site-to-site connectivity. I'm using UT11's for regular traffic (non-management network) anyway.

[johndball]

I spent the last 25 hours (literally, no sleep) deploying Untangle 10 and Untangle 11 boxes at both my main and remote sites setting up site-to-site connectivity.

I won't post ALL of my findings here because it will take another day to do that alone and I'm a week behind schedule on a project BUT both Untangle 10 and Untangle 11 kill vMotion for some reason. Using bare bones UT deployments with just the OpenVPN and reporting application installed, I connected via site-to-site. No matter how much tweaking I did on the UT10 and UT11 boxes whether it was network exports, static route tables, UDP 1194 bypassing, vMotion ALWAYS died and my ESXi hosts ALWAYS changed their IP's to the IP of the main gateway then disconnected from vCenter at the start of vMotion.

I just finished backing out to Untangle 9 for my site-to-site connections. vMotion and vCenter play nice with UT 9 and OpenVPN on UT 9 for some reason.

Took me a few hours today, and a lot of static routing, but I pretty much have all site-to-site done via UT 9 and UT 11 boxes handling all network traffic in and out of the gateways. It isn't an ideal setup, and it sure as s**t aint pretty, but with a few 11x17 Visio pages it makes sense.

This has been a roller coaster I don't want to go down again.

[sky-knight]

I tried to tell you, v10 and v11 perform NAT on OpenVPN connections. This BREAKS THINGS. It breaks vMotion, it breaks DFS replication, it breaks all sorts of stuff.