Default Gateway drops after few seconds on the interface

[Eldi]

Hi,

When i connect through ovpn connect client everything sets up just fine except that default gateway on the interface itself is dropping after few secs. (It's Windows 11)

right after connection:


after about 3 secs:


OVPN Connect logs:

Code: Select all

[Oct 20, 2022, 11:30:59] OpenVPN core 3.git::d3f8b18b win x86_64 64-bit built on Mar 17 2022 11:42:02
⏎[Oct 20, 2022, 11:30:59] Frame=512/2048/512 mssfix-ctrl=1250
⏎[Oct 20, 2022, 11:30:59] UNUSED OPTIONS
1 [tls-client]
6 [nobind]
⏎[Oct 20, 2022, 11:30:59] EVENT: RESOLVE ⏎[Oct 20, 2022, 11:30:59] Contacting ....:4536 via UDP
⏎[Oct 20, 2022, 11:30:59] EVENT: WAIT ⏎[Oct 20, 2022, 11:30:59] WinCommandAgent: transmitting bypass route to ....
{
	"host" : "....",
	"ipv6" : false
}

⏎[Oct 20, 2022, 11:30:59] Connecting to [....]:4536 (....) via UDPv4
⏎[Oct 20, 2022, 11:30:59] EVENT: CONNECTING ⏎[Oct 20, 2022, 11:30:59] Tunnel Options:V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
⏎[Oct 20, 2022, 11:30:59] Creds: UsernameEmpty/PasswordEmpty
⏎[Oct 20, 2022, 11:30:59] Peer Info:
IV_VER=3.git::d3f8b18b
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.3.6-2752
IV_SSO=webauth,openurl,crtext
IV_BS64DL=1

⏎[Oct 20, 2022, 11:30:59] SSL Handshake: peer certificate: CN=server, 2048 bit RSA, cipher: TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD

⏎[Oct 20, 2022, 11:30:59] Session is ACTIVE
⏎[Oct 20, 2022, 11:30:59] EVENT: GET_CONFIG ⏎[Oct 20, 2022, 11:30:59] Sending PUSH_REQUEST to server...
⏎[Oct 20, 2022, 11:31:00] OPTIONS:
0 [route] [192.168.134.0] [255.255.255.0]
1 [route-gateway] [10.8.1.1]
2 [topology] [subnet]
3 [ping] [10]
4 [ping-restart] [60]
5 [ifconfig] [10.8.1.200] [255.255.255.0]
6 [peer-id] [0]
7 [cipher] [AES-256-GCM]

⏎[Oct 20, 2022, 11:31:00] PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  key-derivation: OpenVPN PRF
  compress: NONE
  peer ID: 0
  control channel: tls-auth enabled
⏎[Oct 20, 2022, 11:31:00] EVENT: ASSIGN_IP ⏎[Oct 20, 2022, 11:31:00] CAPTURED OPTIONS:
Session Name: ....
Layer: OSI_LAYER_3
Remote Address: ....
Tunnel Addresses:
  10.8.1.200/24 -> 10.8.1.1
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv6: no
Add Routes:
  192.168.134.0/24
Exclude Routes:
DNS Servers:
Search Domains:

⏎[Oct 20, 2022, 11:31:00] SetupClient: transmitting tun setup list to \\.\pipe\agent_ovpnconnect
{
	"allow_local_dns_resolvers" : false,
	"confirm_event" : "cc06000000000000",
	"destroy_event" : "840f000000000000",
	"tun" : 
	{
		"adapter_domain_suffix" : "",
		"add_routes" : 
		[
			{
				"address" : "192.168.134.0",
				"gateway" : "",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			}
		],
		"block_ipv6" : false,
		"layer" : 3,
		"mtu" : 0,
		"remote_address" : 
		{
			"address" : "....",
			"ipv6" : false
		},
		"reroute_gw" : 
		{
			"flags" : 256,
			"ipv4" : false,
			"ipv6" : false
		},
		"route_metric_default" : -1,
		"session_name" : "....",
		"tunnel_address_index_ipv4" : 0,
		"tunnel_address_index_ipv6" : -1,
		"tunnel_addresses" : 
		[
			{
				"address" : "10.8.1.200",
				"gateway" : "10.8.1.1",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			}
		]
	},
	"wintun" : false
}
POST np://[\\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid='{DD64577F-28E2-4F7F-83B4-C92973F385C5}' index=18 name='Połączenie lokalne 2'
Open TAP device "Połączenie lokalne 2" PATH="\\.\Global\{DD64577F-28E2-4F7F-83B4-C92973F385C5}.tap" SUCCEEDED
TAP-Windows Driver Version 9.24
ActionDeleteAllRoutesOnInterface iface_index=18
netsh interface ip set interface 18 metric=1
Ok.
netsh interface ip set address 18 static 10.8.1.200 255.255.255.0 gateway=10.8.1.1 store=active
IPHelper: add route 192.168.134.0/24 18 10.8.1.1 metric=-1
ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
TAP: ARP flush succeeded
TAP handle: e00d000000000000
⏎[Oct 20, 2022, 11:31:00] Connected via TUN_WIN
⏎[Oct 20, 2022, 11:31:00] EVENT: CONNECTED ....:4536 (....) via /UDPv4 on TUN_WIN/10.8.1.200/ gw=[10.8.1.1/]⏎

client config:

Code: Select all

client
tls-client
dev tun
proto udp
port 4536
remote ....
nobind

key-direction 1
remote-cert-tls server

...certs...

server config:

Code: Select all

tls-server
proto udp
port 4536
dev tun0
server 10.8.1.0 255.255.255.0

ca              ....
cert            ....
key             ....
dh              ....
tls-auth        .... 0

client-config-dir /etc/openvpn/tun/ccd

persist-key
persist-tun
keepalive 10 60
ping-timer-rem

ifconfig 10.8.1.1 255.255.255.0
push "route 192.168.134.0 255.255.255.0"

topology subnet

user nobody
group nogroup

status /etc/openvpn/logfiles/tun.status
log-append /etc/openvpn/logfiles/tun.log

client-config-dir:

Code: Select all

ifconfig-push 10.8.1.200 255.255.255.0

I really have no idea if it's windows 11 doing some shady things in the background, or is it something with ovpn connect.
netsh command from ovpn connect logs looks perfect:

Code: Select all

netsh interface ip set address 18 static 10.8.1.200 255.255.255.0 gateway=10.8.1.1 store=active

Do You have any ideas?

[openvpn_inc]

Hello Eldi,

To me this seems like correct behavior. The default gateway should remain on only your real network interface that goes to the Internet, and not on your VPN TAP adapter.

I seem to recall this thing where Windows firewall NEEDS a default gateway to be present on a network interface before it will correctly trigger a profile setting (domain, private, public) for the Windows Firewall. But that that then needs to be removed from the VPN TAP adapter or else the routing table will be confused where to send Internet traffic.

If you want Internet traffic to be redirected through the OpenVPN server you should use the redirect-gateway function in OpenVPN. Using push "redirect-gateway def1" for example would be an appropriate thing to try, I believe. It should add routes 0.0.0.0/1 and 128.0.0.0/1 that lead the Internet traffic from the VPN client to the VPN server, which should then take care of routing/NATting it further. Those 2 routes are smaller than the 0.0.0.0/0 default gateway rule, and because they're smaller they are more specific, and more specific rules win. In this way there's no conflict like there would be with 2 default gateways.

Are you experiencing any problems with how this works? Or is there something you cannot do because of how this works?

Kind regards,
Johan

[Eldi]

Thank You very much for response so quickly!

I don't want all traffic to go through VPN. I have access to external IP in my server's network. My client PC is behind double NAT that i can't configure or do anything at all. To put it simply - i just want my PC to be accessible from external IP. i configured router (port forwards and static routing) and in wireshark at least i see that all packets are arriving at my PC, however they don't get any response from my PC. If i fill my default gateway on my TAP interface it's working like a charm.

Here is a screenshot from wireshark of SSH [SYN] packets beeing without response:


And again, if i fill default gateway myself everything is working.
Just a note, I disabled windows firewall completly for all domains and it did not make a difference.

Am i doing something wrong? Or maybe whole concept here is wrong? And if so, is there anything i can do to achive my goal?

Also if that is desired behaviour, it's pretty strange that there is info about setting interface ip address with gateway but nothing about clearing default gateway a while later in logs.

[openvpn_inc]

Hello Eldi,

Alright, the use case is clear now. You want to have traffic that comes in on a port on the public IP address of your OpenVPN server to go through the VPN tunnel to your VPN client. You're doing this because your VPN client doesn't have a public IP, and you want to make it reachable from the Internet, on the external public IP of your OpenVPN server.

I want to make it clear that while setting the default gateway will make it work for you, it is not the proper way of doing things. I will mention it in this ticket to make it clear to you what is happening and what is breaking. But for anyone reading this, don't use default gateway on the VPN TAP adapter - if you need to redirect traffic use routes. With that said, let's look at your case.

I believe that the problem you are facing is that traffic will come in on the OpenVPN server's public IP, then go through the VPN tunnel to the VPN client, but traffic responses will not return over the VPN tunnel. But it will if you set the default gateway on the VPN tunnel. Here's how I think things currently work in the two situations you encounter - with and without default gateway set;

Non-working setup without the default gateway added:
- Some external system with a public IP will send a packet to a port on the public IP of your router.
- Your router will forward this through the OpenVPN tunnel to the IP address of the VPN client.
- Your VPN client will receive this packet through the VPN tunnel. You can see this in WireShark.
- Your VPN client will now respond directly to the external PC on the Internet, without going through the VPN tunnel. That's because the routing - table says that to reach the Internet, where this external system is, it has to go through your normal network adapter, not the VPN TAP adapter.
- The external system is now receiving a packet from whatever public IP your VPN client has.
- Since this is coming from an unexpected source, not the router it originally contacted, it will drop it. It is expecting the response to come from the public IP of your router that it originally contacted.

Working setup with the default gateway added:
- Some external system with a public IP will send a packet to a port on the public IP of your router.
- Your router will forward this through the OpenVPN tunnel to the IP address of the VPN client.
- Your VPN client will receive this packet through the VPN tunnel. You can see this in WireShark.
- Your VPN client will now respond through the VPN tunnel. That's because the routing table now contains a default gateway route that, while conflicting with the real network adapter's default gateway, appears to have won, and therefore to reach the external system, it will use the VPN tunnel to reach it.
- Your router will then forward the response back to the external system.
- Since the response is coming from the same system that it contacted earlier, the response is accepted and it all works.

I can think of four solutions off the top of my head;

1.) Add 0.0.0.0/1 and 128.0.0.0/1 to the VPN client's routing table so that it can reach the external system through the VPN tunnel. This is similar to the default gateway solution but avoids possible conflicts between a default gateway rule being present on both the real network adapter and the VPN adapter.
2.) You #yolo it and just go with adding the default gateway anyway. Apparently it seems to work for you, but yeah. Not so ideal.

Those 2 solutions both have a problem - it means normal Internet traffic for the VPN client will all go through the VPN tunnel. You might not want that.

3.) Besides doing destination NAT, also do source NAT on the packets coming through the router from the external system. Make it so that the source IP is not the original IP of the external system, but that of an IP on the router or the OpenVPN server itself. So it will be a private IP that you can have a route for in OpenVPN, so that when the VPN client receives the packet, it just responds over the VPN tunnel. Then when the VPN client responds over the VPN tunnel, the router NATs that back to the original public IP of the external system and it all works without altering the VPN client's Internet access.
4.) You install OpenVPN Access Server and run that as your OpenVPN solution. It does number 3 solution already built-in, with the DMZ gateway function. With it you can pick an IP and port on the Access Server that it should forward to a VPN client, and all the necessary routing and NATting is taken care of for you. See also: https://openvpn.net/vpn-server-resource ... ss-server/

Those 2 solutions don't have the problem with default gateway issues, or VPN client Internet traffic all going through the VPN server.

Kind regards,
Johan

[Eldi]

Thank You, that seems to clarify pretty much everything.

I will probably try to set up variant 3, it seems that it's just what i am looking for.

I've also thought that that might be what is happening here but i couldn't capture in wireshark those ACK packets on my normal internet interface. Packets were probably sent as You mentioned, but i just couldn't locate them.

Thank You once again for help!