Score:0

How to access virtual machines via openvpn

cn flag

Ahoj, any advice would be appreciated, this is what I have and what I need to accomplish:

  1. Strong server (Debian) is running 10.5.234.23 and I installed Virtualbox there so I can setup 5 virtual machines on separate 192.168.56.x network. Each machine will have static machine assigned. (192.168.56.10, 192.168.56.11, 192.168.56.12, 192.168.56.13, 192.168.56.14) This strong server has openvpn installed (via openvpn-install.sh), on interface tun0

  2. I want to access thoose 192.168.56.10, 11, 12, 13, 14 machines via openvpn (listening on 10.5.234.23, 1194, udp) from outside.

And here comes my problems, how to setup virtualbox and openvpn so machines will be accessible for me.

a) which networking option should I use? Host only NAT network or bridged? b) how to "route/access" virtual machines from my pc via openvpn?

So far I am able to connect from mypc to strong server and my IP is 192.168.56.2 on iface tun0, but I am unable to ping/scan machines 192.168.56.10, 192.168.56.11, 192.168.56.12, 192.168.56.13, 192.168.56.14

I am missing some lines in openvpn server configuration or I should add some routing between "virtualbox and openvpn" or both?

Thank you for your advice's.

OpenVPN server.conf

port 1194
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 192.168.56.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_4ND1IGilsOsqFOrd.crt
key server_4ND1IGilsOsqFOrd.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

log from openvpn test client

openvpn test1.ovpn 
2023-03-27 09:37:07 Unrecognized option or missing or extra parameter(s) in test1.ovpn:19: block-outside-dns (2.5.7)
2023-03-27 09:37:07 OpenVPN 2.5.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul  5 2022
2023-03-27 09:37:07 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2023-03-27 09:37:07 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2023-03-27 09:37:07 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-03-27 09:37:07 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2023-03-27 09:37:07 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-03-27 09:37:07 TCP/UDP: Preserving recently used remote address: [AF_INET]10.5.234.23:1194
2023-03-27 09:37:07 Socket Buffers: R=[212992->212992] S=[212992->212992]
2023-03-27 09:37:07 UDP link local: (not bound)
2023-03-27 09:37:07 UDP link remote: [AF_INET]10.5.234.23:1194
2023-03-27 09:37:07 TLS: Initial packet from [AF_INET]10.5.234.23:1194, sid=15fae1aa 4e9d9f26
2023-03-27 09:37:07 VERIFY OK: depth=1, CN=cn_WHLqtsupL3nvjt9t
2023-03-27 09:37:07 VERIFY KU OK
2023-03-27 09:37:07 Validating certificate extended key usage
2023-03-27 09:37:07 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2023-03-27 09:37:07 VERIFY EKU OK
2023-03-27 09:37:07 VERIFY X509NAME OK: CN=server_4ND1IGilsOsqFOrd
2023-03-27 09:37:07 VERIFY OK: depth=0, CN=server_4ND1IGilsOsqFOrd
2023-03-27 09:37:07 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, peer certificate: 256 bit EC, curve prime256v1, signature: ecdsa-with-SHA256
2023-03-27 09:37:07 [server_4ND1IGilsOsqFOrd] Peer Connection Initiated with [AF_INET]10.5.234.23:1194
2023-03-27 09:37:09 SENT CONTROL [server_4ND1IGilsOsqFOrd]: 'PUSH_REQUEST' (status=1)
2023-03-27 09:37:09 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,redirect-gateway def1 bypass-dhcp,route-gateway 192.168.56.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.56.2 255.255.255.0,peer-id 0,cipher AES-128-GCM'
2023-03-27 09:37:09 OPTIONS IMPORT: timers and/or timeouts modified
2023-03-27 09:37:09 OPTIONS IMPORT: --ifconfig/up options modified
2023-03-27 09:37:09 OPTIONS IMPORT: route options modified
2023-03-27 09:37:09 OPTIONS IMPORT: route-related options modified
2023-03-27 09:37:09 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2023-03-27 09:37:09 OPTIONS IMPORT: peer-id set
2023-03-27 09:37:09 OPTIONS IMPORT: adjusting link_mtu to 1624
2023-03-27 09:37:09 OPTIONS IMPORT: data channel crypto options modified
2023-03-27 09:37:09 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2023-03-27 09:37:09 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
2023-03-27 09:37:09 net_route_v4_best_gw query: dst 0.0.0.0
2023-03-27 09:37:09 net_route_v4_best_gw result: via 192.168.216.2 dev eth0
2023-03-27 09:37:09 ROUTE_GATEWAY 192.168.216.2/255.255.255.0 IFACE=eth0 HWADDR=00:0c:29:8e:38:4d
2023-03-27 09:37:09 TUN/TAP device tun0 opened
2023-03-27 09:37:09 net_iface_mtu_set: mtu 1500 for tun0
2023-03-27 09:37:09 net_iface_up: set tun0 up
2023-03-27 09:37:09 net_addr_v4_add: 192.168.56.2/24 dev tun0
2023-03-27 09:37:09 net_route_v4_add: 10.5.234.23/32 via 192.168.216.2 dev [NULL] table 0 metric -1
2023-03-27 09:37:09 net_route_v4_add: 0.0.0.0/1 via 192.168.56.1 dev [NULL] table 0 metric -1
2023-03-27 09:37:09 net_route_v4_add: 128.0.0.0/1 via 192.168.56.1 dev [NULL] table 0 metric -1
2023-03-27 09:37:09 Initialization Sequence Completed
^C2023-03-27 09:40:06 event_wait : Interrupted system call (code=4)
2023-03-27 09:40:06 SIGTERM received, sending exit notification to peer
2023-03-27 09:40:07 net_route_v4_del: 10.5.234.23/32 via 192.168.216.2 dev [NULL] table 0 metric -1
2023-03-27 09:40:07 net_route_v4_del: 0.0.0.0/1 via 192.168.56.1 dev [NULL] table 0 metric -1
2023-03-27 09:40:07 net_route_v4_del: 128.0.0.0/1 via 192.168.56.1 dev [NULL] table 0 metric -1
2023-03-27 09:40:07 Closing TUN/TAP interface
2023-03-27 09:40:07 net_addr_v4_del: 192.168.56.2 dev tun0

enter image description here

#edit after pushing route and adjusting openvpn settings: enter image description here

Score:0
cn flag

Ok, thank you I have finally solved the puzzle. Issue was that I had identical IP setting for openvpn interface and vboxnet0 interface. My bad. Host only config is working but do not forget to add default gw so you can bridge tun0 and vboxnet0

Score:0
kz flag

Let's look at your options one by one.
a) what type of network adapter for your VMs:
This depends on your requirements / what you have to accomplish with your VMs.

  • a bridged network would give all your VMs direct access to your companys network (meaning it will get an IP just like your "strong server"!), which is probably not what you want.
  • a NAT network would create a separate network which is NOT directly reachable from your server - somewhat comparable to your private network behind your home router. You do have the option to create port forwardings to reach a VM, though. This is the "default" adapter to give your VMs internet access.
  • a host only network is a virtual network setup, which makes the VMs accessible - but as the name says, just from the host the VM runs on. Per default, no routing / internet access is enabled over such an adapter, but both is possible with some customizations.

b) how to route/access your VMs:
Again, you have multiple options here. I will "draw" an outline of the network and the steps required to accomplish this.

  1. install an openvpn client within each VM: With this method, each VM connects to the openvpn server running on your "strong server", leaving the routing part completely to openvpn.

  2. real routing approach:

    • configure the network for openvpn as a different subnet to your host only adapter - in your config above, you used the same subnet for openvpn and your host only network.
    • publish the route to your host only network to your openvpn clients (inside your openvpn server config): push "route 192.168.56.0 255.255.255.0" (and you should probably undo the redirect gateway directive in your VPN config)
    • enable routing echo 1 > /proc/sys/net/ipv4/ip_forward
    • install firewall rules, so that your VPN can be used only to access what you want, and nothing else.
  3. Bridged tap-VPN approach: with this aproach, you would create a network bridge on your strong server between your openvpn server and your server's host-only adapter. Your VPN client would be assigned an IP from the dhcp server running on the host-only network - and since everyone is on the same network, no routing required. Check here if you do not know the difference between bridging and routing.

user1821820 avatar
cn flag
Ahoj Martin, thank you for your time and hints. Perhaps I didn't described whole situation well, so trying to add more information.
user1821820 avatar
cn flag
Whatever network adapter will work it is fine for me. VM's does not need to have internet connection, it will be sufficient if they can be reachable from "MyPC" over openvpn. I tried to enable routing and push the route to 192.168.56.0 and my testing vm network settings is set to host only adapter, but no luck. Testing VM IP is 192.168.56.101, my tun0 IP is 192.168.56.3 but I cant ping the machine. I am missing gateway setting where should I look at? Please see screenshot above I have added. Thank you?
Martin avatar
kz flag
Sorry, but did you read my answer? you have to resolve the network overlap! The openvpn network MUST be different than your host-only VM network - otherwise, it cannot work...
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.