OpenVPN internet connection sharing works inconsistently on Windows

OpenVPN tutorials ranging from configuration to hacks to compilation will be posted here.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Post Reply
User avatar
UltraFine
OpenVpn Newbie
Posts: 16
Joined: Mon Sep 13, 2021 8:32 pm

OpenVPN internet connection sharing works inconsistently on Windows

Post by UltraFine » Sat Nov 06, 2021 8:59 am

Here is an weird problem that I just cannot get my head around:


Client1 connected to a server with OpenVNC installed and Internet Connection Sharing (ICS) on LAN-Adapter enabled is not able to access the internet, when server just booted. After disabling/re-enabling of ICS accessing the internet starts working. Thus every server reboot needs manual re-setup of ICS to work.



Problem in detail:
When I freshly power on my server (WinServer2022 virtual maniche) which has OpenVNC server setup and running, I can ALWAYS connect to OpenVNC-server just fine (I use config-auto to start OpenVPN-Server). Ping 10.8.0.1 from my connected client works, but I cannot access the internet through the OpenVPN server. From my connected client1 I ping 8.8.8.8 and the ping does NOT work. Browsing internet on the client does not work. I expect a freshly booted box, which has "internet sharing" enabled to just work, but it does not.


But it starts working if I disable and re-enable the Internet Sharing on my server LAN-Adapter and OpenVPN TAP-Windows6 Adapter with regular steps:

On the server, if I go to "Adapter Settings", chose my LAN-Interface (ip: 192.168.2.141, router of this box in connected to the internet), disable the already enabled internet sharing setting: "Share Internet Connection with other PCs (Connection: OpenVPN TAP-Windows6)". Then immediatly enable internet sharing again, then disable the "OpenVPN TAP-Windows6"-Interface and immediatly enable it again.

Now, after connecting my Client1 to the OpenVPN-Server I can use the internet on my client. This problem basically means that every time I restart the OpenVPN-Server manichine, I have to remote desctop into it, resetup the Internet Sharing, disable+enable "OpenVPN TAP-Windows6" and restart OpenVPN-Server. This is alot of trouble.

Does anyone have a clue why this is happening and how to make internet connection sharing work wihout doing a resetup of the LAN settings every time I reboot the box? My aim is to fully redirect my traffic from Client1 to OpenVPN-Server.


My SETUP:
  • Windows Server 2022 fresh install as virtual machine
  • Server Port 7777 forwarded to OpenVPN-Server
  • Server network: Gateway: 192.168.2.1 (router connected to internet) --- 192.168.2.141 (OpenVPN Server, LAN-Adapter has Internet Sharing enabled)
  • Client network: Gateway: 192.168.1.1 (router connected to internet) --- 192.168.1.46 (Client1, IPRouterEnabeld=true)
  • Server has "Internet Connection Sharing" setup on LAN-Interface to OpenVPN TAP-Windows6
  • Server: IPRouterEnabled = True
  • Server: Routing Service = Start automaticaly + it is started
  • ../config/ccd/DEFAULT -> "iroute 192.168.1.0 255.255.255.0" (I do not really understand what this does, but it seems to work)

Client config

Code: Select all

client
dev tun
proto tcp4
remote 80.125.246.118 7777
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
redirect-gateway def1 # this seems to force my client to use the internet of the VPN-Server
Server config

Code: Select all

port 7777
proto tcp4
dev tun
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\server.key"
dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
topology subnet  # the log tells me to use this topology
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir "C:\\Program Files\\OpenVPN\\config\\ccd"
keepalive 10 120
tls-auth ta.key 0 
cipher AES-256-CBC # This cipher seems to be outdated
persist-key
persist-tun
status openvpn-status.log
verb 5
explicit-exit-notify 0
keepalive 10 60


In the server log I these lines. Not sure if those [undef] and [AF_UNSPEC] are healthy.

Code: Select all

Sat Nov  6 08:36:28 2021 Socket Buffers: R=[131072->131072] S=[131072->131072]
Sat Nov  6 08:36:28 2021 Listening for incoming TCP connection on [AF_INET][undef]:7777
Sat Nov  6 08:36:28 2021 TCPv4_SERVER link local (bound): [AF_INET][undef]:7777
Sat Nov  6 08:36:28 2021 TCPv4_SERVER link remote: [AF_UNSPEC]
Sat Nov  6 08:36:28 2021 MULTI: multi_init called, r=256 v=256

Info: When the internet connection sharing works and I browse the internet, I see sometimes following log entries in the server log:
  • MULTI: Outgoing TUN queue full, dropped packet len=67
  • MULTI: packet dropped due to output saturation (multi_process_incoming_tun)

Code: Select all

Sat Nov  6 08:39:23 2021 Client1/79.111.20.3:55823 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
Sat Nov  6 08:39:23 2021 Client1/79.111.20.3:55823 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
Sat Nov  6 08:39:23 2021 Client1/79.111.20.3:55823 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)
Sat Nov  6 08:39:51 2021 Client1/79.111.20.3:55823 MULTI: Learn: 192.168.1.46 -> Client1/79.111.50.3:55823
Sat Nov  6 08:40:48 2021 Client1/79.111.20.3:55823 MULTI: Outgoing TUN queue full, dropped packet len=40
Sat Nov  6 08:40:48 2021 Client1/79.111.20.3:55823 MULTI: Outgoing TUN queue full, dropped packet len=40
Sat Nov  6 08:40:48 2021 Client1/79.111.20.3:55823 MULTI: Outgoing TUN queue full, dropped packet len=67
Sat Nov  6 08:40:48 2021 Client1/79.111.20.3:55823 MULTI: Outgoing TUN queue full, dropped packet len=52


TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: OpenVPN internet connection sharing works inconsistently on Windows

Post by TinCanTech » Sat Nov 06, 2021 11:39 pm

Thanks for the solution!

How about that, security through obscurity .. and they told us that was a bad idea .. :lol:

Post Reply