@rschmied wrote:
Introduction
When using a VPN client to connect back to a corporate environment that enforces a strict 'no split tunneling' policy, even communication that does not leave the local machine is suppressed / dropped.
It is not possible to use a client / server application where the client runs on the machine that is 'protected' by the VPN client and the server runs within a VM on that machine. This is exactly the case with VIRL where the backend is the VM and VM Maestro should be used on the local machine. Impossible when the VPN client enforces its policy! Impossible? Well, not quite... Here's how you can actually get it to work, at least to some extent.
Assumptions
This post describes the procedure and techniques using VMware Fusion on a Mac and therefor shows paths and tools that are Mac specific. However, the approach to make this work is working on other platforms as well, paths and tools might differ. I'll try to point out differences and recommend alternative tools on other platforms where appropriate.
How this works
Since the VPN client prevents all routing / forwarding and routing table manipulation (except for packets destined to the tunnel) we have to convince it that the VIRL backend is actually a local application. We leverage the VMware NAT process to configure a local port forwarding into the VM. While this could be done for all the required ports it would be quite tedious to do so. VIRL uses A LOT of ports. Therefore we're multiplexing the connections via a single port -- SSH. We're using the SSH client on the Mac / Linux (or Putty on Windows) and enable the SOCKS feature. VM Maestro conveniently provides SOCKS capability as well. Problem solved.
What does work
- VM Maestro, STD, ANK, ...
- Built-in console / serial lines / SSH via LXC
- UWM and VNC connections in browser configured for SOCKS
Drawbacks
There are, of course, things that don't work. Most notably, external terminals don't work since they are outside of the control of VM Maestro. A potential solution is the use of tsocks (available via Homebrew or MacPorts) or Proxifier on Windows (30 days demo, then pay-ware). Also, Web Sockets did not work for me (they should, in my opinion. No clue why they don't). Also, tsocks does not like the SOCKS host on the same machine. Some weird logic expects it to be outside -- well, there are situations where the SOCKS proxy IS on the local machine!
Configuration Steps
Here's a high level overview of the configuration steps that are required to make this work. Additional details for the those steps are explained in the following subsections.
- Configure the DHCP server for the VMware NAT network (typically vmnet8) to allow for a static IP assignment to the VIRL host. Alternatively, re-configure the VIRL host for a static IP
- Configure port forwarding for the VMware NAT process to the IP of the VIRL host
- Restart Fusion (alternatively, restart the Fusion network services)
- Open a SSH session into the VIRL host using the port forwarding as configured in the second step. Configure SSH for SOCKS using -D. On Putty for Windows this is called 'Dynamic Tunneling'
- Configure VM Maestro to use SOCKS via Preferences -> General -> Network Connections, setting it to manual
- Configure Browser to use SOCKS in Preferences
The steps for 1. and 2. are specific to VMware Fusion 6 on a Mac. However, VMware Workstation on Linux and Windows (and even VMware Player) work in a similar way. In particular, the
dhcp.confandnat.confconfiguration files exist there as well -- just in a different location (please send those locations if you can and I will add them to this document). The network restart command is probably also the same, again just a different path.DHCP
Identify the MAC address in use by the VIRL host. Either by looking at the output of ifconfig eth0 from within the VIRL host or by looking at the VM configuration in Fusion as shown here:
Edit the DHCP server configuration file for vmnet8 (the NATed network). On a Mac with Fusion 6, this is located here
/Library/Preferences/VMware Fusion/vmnet8/dhcpd.confAdd a section with the MAC address of the eth0 interface your VIRL VM (as shown above) to assign it a static IP as shown here (at bottom of file):
... lines omitted ... subnet 192.168.27.0 netmask 255.255.255.0 { range 192.168.27.128 192.168.27.254; option broadcast-address 192.168.27.255; option domain-name-servers 192.168.27.2; option domain-name localdomain; default-lease-time 1800; # default is 30 minutes max-lease-time 7200; # default is 2 hours option netbios-name-servers 192.168.27.2; option routers 192.168.27.2; } host vmnet8 { hardware ethernet 00:50:56:C0:00:08; fixed-address 192.168.27.1; option domain-name-servers 0.0.0.0; option domain-name ""; option routers 0.0.0.0; } ####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" ####### host virl { hardware ethernet 00:0C:29:E5:3A:53; fixed-address 192.168.27.10; }Make sure to assign an IP from the configured subnet (here: 192.168.27.0/24) and outside of the dynamic range (here: 128-254). The example uses the .10.
Alternatively, configure VIRL to use a static IP address and run vinstall rehost inside of VIRL.NAT
Edit the NAT configuration file for vmnet8. It is in the same directory:
/Library/Preferences/VMware Fusion/vmnet8/nat.confAdd a line towards the end of the document in section [incomingtcp] to forward a local port (here: 2222) to port 22 on the VIRL host IP as configured in the previous step:
... lines omitted ... # Number of retries for each NBNS query. nbnsRetries = 3 # Timeout for NBDS queries. nbdsTimeout = 3 [incomingtcp] # Use these with care - anyone can enter into your VM through these... # The format and example are as follows: #<external port number> = <VM's IP address>:<VM's port number> #8080 = 172.16.3.128:80 2222 = 192.168.27.10:22 [incomingudp] # UDP port forwarding exampleRestart Services
Either close Fusion and start it again. Alternatively, you can also restart the VMware network services using these commands:
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --startStart your VIRL host and make sure that eth0 on the VIRL host is configured with the IP address from DHCP. This must be the same IP that is referenced in the nat.conf file (here: 192.168.27.10).
SSH
Start a SSH process on your Mac in a terminal like here:
ssh -D 1080 -p 2222 virl@localhostIdeally, this goes in combination with private / public key authentication and a
~/.ssh/configfile that contains most of the configuration. However, this is completely optional, username and password with the given command line will work just fine. This now runs in the background inside a terminal and can be put aside... We now do have a SOCKS proxy running on our Mac that proxies TCP connections into our VIRL host.On Windows with Putty, the relevant configuration pieces are shown here:
![]()
![]()
VM Maestro
VM Maestro now has to be configured to use the SOCKS proxy. Also make sure to select the internal terminal view. The following two screen shots illustrate the settings.
Browser
The SOCKS proxy can also be configured in the Web browser. In theory, the SOCKS proxy should be configurable globally on a Mac via the System Preferences as shown here:
However, this was not reliably working. Also, some applications simply do not honor these settings (mostly command line tools like telnet or ssh, hence the need for tsocks. Which did not work, see above). Firefox, on the other hand, has its own proxy / network configuration and that worked without a problem for UWM and VNC sessions. Here's where it is configured via Preferences -> Advanced -> Network:
Verification
Verify the configuration via the following steps.
- In VM Maestro, check that your Web services are showing as 'green'
- Verify that you can use ANK and start / stop a simulation
- Roster service should show the running simulation(s)
- Opening a (internal) terminal via roster should work using 'SSH via LXC...' and
'Telnet...'. 'Telnet over Web Socket...' did not work- Opening a VNC session to a server (in the browser) should work
- Opening UWM in the browser should work
Conclusion
The combination of TCP port forwarding and SSH with SOCKS / dynamic tunneling provides a method to access VIRL services running in a VM on the user's machine even when a VPN client is running and denying 'split tunneling'.
Posts: 1
Participants: 1