1

I believe that my problem is similar to this question on accessing VirtualBox guest via VPN, but not quite. I am trying to go the other way: I am trying to reach a destination that is accessible to the host via OpenVPN, from the guest.

My VirtualBox guest has a Host-Only Network (vboxnet0) where the guest is 192.168.56.101 and the host is 192.168.56.1. The host is a client on an OpenVPN network leading to 10.44.55.55 via its virtual tun1 gateway at 10.9.0.1. OpenVPN connectivity from the client to the remote is known-good.

On the guest, I defined a route: route add -host 10.44.55.55 gw 192.168.56.1 dev enp0s8

... so that the routing table looks like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 enp0s3
10.44.55.55     192.168.56.1    255.255.255.255 UGH   0      0        0 enp0s8

This, as you see, is the IP-address of the host side of the Host-Only Network and the virtual network adapter leading to it.

On the guest, I now tried ping 10.44.55.55. There was no response, and here is how I have tried to systematically diagnose the problem:

tcpdump -nn icmp on the host shows that packets are being issued by the client address bound for the target: 192.168.56.101 > 10.44.55.55. Trouble is, they don't actually get there. Although the host knows a route to 10.44.55.55 and can ping it, and although packets can be seen by tcpdump on the host, they do not then pass through the tunnel to the destination, as do packets issued by the same command on the host.

tcpdump -nn icmp executed on the remote side shows that ping packets are not arriving, if the traffic originates from the virtual machine. (Of course, if the host issues ping 10.44.55.55, the packets do arrive.)

The host is Mac OS/X (El Capitan) and it occurred to me that "maybe this is a packet forwarding problem on the host." Referring now to this thread on packet forwarding in OS X, I found the proper sysctl command and enabled packet forwarding as described there, but no joy.

Here is how I know that port-forwarding was turned on, on the OS/X host, although it didn't do any good:

$ sysctl -a | grep forw
net.inet.ip.forwarding: 1

I am confident that I am quite close to a solution here, but I just can't quite find the proper network mojo. Thanks in advance ...

Further Note: Still tinkering with this, I tried to define a route to 10.9.0.1 (the OpenVPN portal in question) with similar negative results.

  • I assume 10.44.55.55's firewall allows connections from 192.168.56.101? Have you considered an ssh port-forwarding tunnel from 192.168.56.101 through 192.168.56.1? That way, the packets would appear to come from 192.168.56.1, not from 192.168.56.101 – barrycarter Jan 19 '17 at 16:10
  • There is no firewall on the target machine, since it can only be reached through the OpenVPN network. The machine that hosts the VM is directly connected to the OpenVPN so it will talk using 10.8.0.x .... hmmm .... – Mike Robinson Jan 19 '17 at 16:49
  • Could this possibly be an 'iroute' type issue? Well, I looked in syslog and I don't see anything that tells me that it has a packet it doesn't know how to route. So I guess that can't be it. After all, the packet does not -arrive- at the destination. (If it did and it couldn't get back then I'd know what to do right away.) But, still I wonder ... groping in the dark here ... because "this sure stinks like a routing issue." – Mike Robinson Jan 19 '17 at 16:56
  • Is your host NAT'ing? If not, the packet is coming from 192.168.whatever and not 10.8.whatever. – barrycarter Jan 19 '17 at 16:59
  • I've tried both a NAT (VirtualBox) interface and Host-Only. When I tried to route (no gateway) through the NAT interface, after a few seconds I got "Host Network Unreachable." (Which was interesting ...) When I routed as described in my post, I got nothing. In the OP you see though that the packet (as seen by tcpdump on the host) do come from "192.168.56.101," the IP-address of the VM on the Host-Only Network. And yes, the successful pings direct from the host come from "10.9.0.3" as expected. – Mike Robinson Jan 19 '17 at 17:04
0

SOLVED!

Strangely enough, when I changed the host-adapter type from Bridged Network (which accesses the host's adapter directly) to NAT, I found that I could see the IP-addresses of remotes that were accessible to the host.

I am now rather baffled by my own comment (#5) of January 19th. (I must have been "too confused," at the time.)

Now, this is specifically an answer for "reaching the host's VPN connection from the client." It does not apply to traffic going the other way. (Even the host cannot ping a "NAT" virtual interface.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.