Possible routing issue when setting up a new Windows 10 OpenVPN server

CraftyClown

Hi folks,

I've just moved my OpenVPN server from an ageing router to a Windows 10 box and I'm having a few problems getting the final final stages set up.

I can connect to the server from any of my clients without issue however I cannot access any other machines on the network. I believe my issue is probably a routing one, but I am a little confused at this stage and am unsure of how to progress further or troubleshoot.

Any assistance would be greatly appreciated.

SERVER SCRIPT

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"
#push "redirect-gateway"
client-to-client
keepalive 10 120
tls-auth ta.key
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

CLIENT SCRIPT

client
dev tun
proto udp
remote ********* 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Godzilla10.crt
key Godzilla10.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3

TinCanTech

See your log for this message:

NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

So change them for a start.

And I would have hoped to see an old timer like yourself to be one step ahead of this crap by now ..

CraftyClown

TinCanTech wrote See your log for this message:
NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
So change them for a start.

And I would have hoped to see an old timer like yourself to be one step ahead of this crap by now ..

Ha, fair play, I was also swapping out the router and left it on the default subnet whilst setting up the new OpenVPN server, hence the common address, however that shouldn't be any kind of issue due to my client subnets being different.

Just for arguments sake I have changed it but the problem persists. My confusion is with the routing. As I mentioned the connection works and I can access the server and even remote desktop in, but I can't access shares or any other devices on the subnet.

CraftyClown

This is the bit from the 'How to' where I'm getting confused

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Make sure that you've enabled IP and TUN/TAP forwarding on the OpenVPN server machine.

CraftyClown

Having read some of the community wiki on routing I have tried adding the following to the routing table on my router;

Destination LAN NET 10.8.0.0
Subnet Mask 255.255.255.0
Gateway 192.168.10.4 (This is the IP address of my server running OpenVPN)

and the following to my router

# Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o eth0 \
-s 10.8.0.0/24 -d 192.168.10.0/24 \
-m conntrack --ctstate NEW -j ACCEPT

# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT

Is this a step in the right direction? Or am I making more of a mess?

TinCanTech

CraftyClown wrote This is the bit from the 'How to' where I'm getting confused

Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Make sure that you've enabled IP and TUN/TAP forwarding on the OpenVPN server machine.

It is difficult to make this any simpler.

CraftyClown wrote Having read some of the community wiki on routing I have tried adding the following to the routing table on my router;

Destination LAN NET 10.8.0.0
Subnet Mask 255.255.255.0
Gateway 192.168.10.4 (This is the IP address of my server running OpenVPN)

That looks to be correct.

CraftyClown wroteand the following to my router

# Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o eth0 \
-s 10.8.0.0/24 -d 192.168.10.0/24 \
-m conntrack --ctstate NEW -j ACCEPT

# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT

Is this a step in the right direction? Or am I making more of a mess?

If I were you, I would simply enable forwarding until you get it working. If it does not work then the firewalling is pointless.

300000

CraftyClown wrote Having read some of the community wiki on routing I have tried adding the following to the routing table on my router;

Destination LAN NET 10.8.0.0
Subnet Mask 255.255.255.0
Gateway 192.168.10.4 (This is the IP address of my server running OpenVPN)
and the following to my router

# Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o eth0 \
-s 10.8.0.0/24 -d 192.168.10.0/24 \
-m conntrack --ctstate NEW -j ACCEPT

# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT

Is this a step in the right direction? Or am I making more of a mess?

wrong or right? why do you think you need to do something with your router to make openvpn work on routing? there are nothing to do with your router like iptable to make it work any way and it will never works for you , simple it is wrong way to do thing.

if your openvpn server run on router all you did on router is right , but you instaled openvpn on windows so why do you think doing that way makie it routing enable ?all you do is making widows routing enable through NAT betweent network card that is correct way. .

all command you did on your router do is making routing table beweent real card and openvpn virtual card routing throught. basic it is NAT so it work for you when you run openvpn on your router.

if you want to make it work on windows going through my post https://forums.openvpn.net/viewforum.php?f=6

TinCanTech

300000 wrote why do you think you need to do something with your router to make openvpn work on routing?

Because:

CraftyClown wrote I've just moved my OpenVPN server from an ageing router to a Windows 10 box

300000 wrote if you want to make it work on windows going through my post https://forums.openvpn.net/viewforum.php?f=6

You may like to narrow that down a little ...

CraftyClown

Thanks TinCan,

I think I'm 90% of the way there.

I can access other machines behind the VPN now via RDP.

The only thing I can't do is access any of the shares whether by name or IP. It seems to be the final peice of the puzzle eluding me.

Is there anything else I should be doing at the Openvpn side to help access the shares? They all work fine locally.

Cheers

CraftyClown

300000 wrote
CraftyClown wrote Having read some of the community wiki on routing I have tried adding the following to the routing table on my router;

Destination LAN NET 10.8.0.0
Subnet Mask 255.255.255.0
Gateway 192.168.10.4 (This is the IP address of my server running OpenVPN)
and the following to my router

# Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o eth0 \
-s 10.8.0.0/24 -d 192.168.10.0/24 \
-m conntrack --ctstate NEW -j ACCEPT

# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT

Is this a step in the right direction? Or am I making more of a mess?

wrong or right? why do you think you need to do something with your router to make openvpn work on routing? there are nothing to do with your router like iptable to make it work any way and it will never works for you , simple it is wrong way to do thing.

if your openvpn server run on router all you did on router is right , but you instaled openvpn on windows so why do you think doing that way makie it routing enable ?all you do is making widows routing enable through NAT betweent network card that is correct way. .

all command you did on your router do is making routing table beweent real card and openvpn virtual card routing throught. basic it is NAT so it work for you when you run openvpn on your router.

if you want to make it work on windows going through my post https://forums.openvpn.net/viewforum.php?f=6

Sorry I'm not quite getting you. You are saying I shouldn't do the routing via the router? It has allowed me to access the other machines on the network via RDP which I couldn't do before. Where do you suggest I do the routing instead?

Id be happy to read your guide but it only links to the forum 😉

300000

you can connect to the server from any of your clients without issue that ok now and your client computer get its ip 10.8.0.2 or something like that, when you want client go somewhere it will go througt to openvpn server 10.8.0.1 and that is why you need routing enable at windows so client can go .

1 rename the internet netword card and openvpn netword card so it makes thing simple

click search type ncpa.cpl and press enter , click the the internet netword card and chose properties/chosing share tab, tick allow other netword user connect through this computer internet connection.
choose openvpn netword card if it is pressen and click ok.

right click openvpn netword card and chosse properties chose ip4 and set its ip as 10.8.0.1 subnet mask 255.255.255.0

open your openvpn config add this line ip-win32 manual

open regedit anfd find

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
charge IPEnableRouter =1

this will make windows will lan routing all network card

go service and choose Internet Connection Sharing and choose automatic
go to service and find routingand remote access and choose automatic

after that restart computer and check every sevice have been start so your openvpn run at windows wil routing all over netword card and client can go

300000

It has allowed me to access the other machines on the network via RDP ?? because your windows you install openvpn server can connect everywhere so when you RDP IS you using your windows openvpn server not client.it mean your client openvpn can connect to 10.8.0.1 and control that openvpn server so when you run RDP IT IS RUN ON OPENVPN SERVER YOUR CLIENT IS A MONITOR only.

you can try this command tracert 8.8.8.8 and you only see 1 2 ms 3 ms 1 ms 10.8.0.1 that is all about and the rest is time out

so that is your client stay at 10.8.0.1 only .

CraftyClown

300000 wrote you can connect to the server from any of your clients without issue that ok now and your client computer get its ip 10.8.0.2 or something like that, when you want client go somewhere it will go througt to openvpn server 10.8.0.1 and that is why you need routing enable at windows so client can go .

1 rename the internet netword card and openvpn netword card so it makes thing simple

click search type ncpa.cpl and press enter , click the the internet netword card and chose properties/chosing share tab, tick allow other netword user connect through this computer internet connection.
choose openvpn netword card if it is pressen and click ok.

right click openvpn netword card and chosse properties chose ip4 and set its ip as 10.8.0.1 subnet mask 255.255.255.0

open your openvpn config add this line ip-win32 manual

open regedit anfd find

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
charge IPEnableRouter =1

this will make windows will lan routing all network card

go service and choose Internet Connection Sharing and choose automatic
go to service and find routingand remote access and choose automatic

after that restart computer and check every sevice have been start so your openvpn run at windows wil routing all over netword card and client can go

Hello mate, maybe I'm missing something but this seems to have made things worse.

I can no longer to connect to any machines on the network, including the server itself.

I've double checked I followed your instructions and both services are running however I'm unable to connect to anything.

OpenVPN tells me my client is connected and assigns it an IP but nothing works.

I noticed something weird in the log

Wed Oct 16 19:44:18 2019 MANAGEMENT: >STATE:1571251458,ASSIGN_IP,,10.8.0.6,,,,
Wed Oct 16 19:44:23 2019 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Oct 16 19:44:23 2019 MANAGEMENT: >STATE:1571251463,ADD_ROUTES,,,,,,
Wed Oct 16 19:44:23 2019 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 10.8.0.5
Wed Oct 16 19:44:23 2019 Route addition via service succeeded
Wed Oct 16 19:44:23 2019 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Wed Oct 16 19:44:23 2019 Route addition via service succeeded

Is there a reason the OpenVPN mask is 255.255.255.255 instead of 255.255.255.0?

300000

Do you restart window open on server? What log is client or server . ?

Do you check. Internet Connection Sharing and routing and remote access start or stop?

TinCanTech

CraftyClown wrote Is there a reason the OpenVPN mask is 255.255.255.255 instead of 255.255.255.0?

This is why log snippets are not enough, you must have changed your server config.

I suggest you read this:
https://forums.openvpn.net/viewtopic.php?f=7&t=7806

For your edification:
There are two approaches to making this work:

Routing, by setting up routing correctly.
NAT, which is the solution 300000 is trying to explain.

CraftyClown

300000 wrote Do you restart window open on server? What log is client or server . ?

Do you check. Internet Connection Sharing and routing and remote access start or stop?

Yes I restarted the OpenVPN server and both Internet Connection Sharing and routing and remote access are set to automatic and running

Client log:

Wed Oct 16 19:44:16 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Wed Oct 16 19:44:16 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Oct 16 19:44:16 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Enter Management Password:
Wed Oct 16 19:44:16 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Oct 16 19:44:16 2019 Need hold release from management interface, waiting...
Wed Oct 16 19:44:16 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'state on'
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'log all on'
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'echo all on'
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'hold off'
Wed Oct 16 19:44:16 2019 MANAGEMENT: CMD 'hold release'
Wed Oct 16 19:44:16 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 19:44:16 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 19:44:16 2019 MANAGEMENT: >STATE:1571251456,RESOLVE,,,,,,
Wed Oct 16 19:44:16 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]1194
Wed Oct 16 19:44:16 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Oct 16 19:44:16 2019 UDP link local: (not bound)
Wed Oct 16 19:44:16 2019 UDP link remote: [AF_INET]:1194
Wed Oct 16 19:44:16 2019 MANAGEMENT: >STATE:1571251456,WAIT,,,,,,
Wed Oct 16 19:44:16 2019 MANAGEMENT: >STATE:1571251456,AUTH,,,,,,
Wed Oct 16 19:44:16 2019 TLS: Initial packet from [AF_INET]:1194, sid=6ea13fc2 44a2f577
Wed Oct 16 19:44:16 2019 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=, OU=changeme, CN=Indigo, name=changeme, emailAddress=
Wed Oct 16 19:44:16 2019 VERIFY KU OK
Wed Oct 16 19:44:16 2019 Validating certificate extended key usage
Wed Oct 16 19:44:16 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Oct 16 19:44:16 2019 VERIFY EKU OK
Wed Oct 16 19:44:16 2019 VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=, OU=changeme, CN=server, name=changeme, emailAddress=
Wed Oct 16 19:44:16 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Oct 16 19:44:16 2019 [server] Peer Connection Initiated with [AF_INET]185.247.200.174:1194
Wed Oct 16 19:44:18 2019 MANAGEMENT: >STATE:1571251458,GET_CONFIG,,,,,,
Wed Oct 16 19:44:18 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Oct 16 19:44:18 2019 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: timers and/or timeouts modified
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: --ifconfig/up options modified
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: route options modified
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: peer-id set
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Wed Oct 16 19:44:18 2019 OPTIONS IMPORT: data channel crypto options modified
Wed Oct 16 19:44:18 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Oct 16 19:44:18 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 19:44:18 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 19:44:18 2019 interactive service msg_channel=680
Wed Oct 16 19:44:18 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=15 HWADDR=64:5d:86:de:ba:0c
Wed Oct 16 19:44:18 2019 open_tun
Wed Oct 16 19:44:18 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{A57A613B-71AD-4B08-B3ED-B21498CA0243}.tap
Wed Oct 16 19:44:18 2019 TAP-Windows Driver Version 9.21 
Wed Oct 16 19:44:18 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {A57A613B-71AD-4B08-B3ED-B21498CA0243} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Wed Oct 16 19:44:18 2019 Successful ARP Flush on interface [13] {A57A613B-71AD-4B08-B3ED-B21498CA0243}
Wed Oct 16 19:44:18 2019 MANAGEMENT: >STATE:1571251458,ASSIGN_IP,,10.8.0.6,,,,
Wed Oct 16 19:44:23 2019 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Oct 16 19:44:23 2019 MANAGEMENT: >STATE:1571251463,ADD_ROUTES,,,,,,
Wed Oct 16 19:44:23 2019 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 10.8.0.5
Wed Oct 16 19:44:23 2019 Route addition via service succeeded
Wed Oct 16 19:44:23 2019 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Wed Oct 16 19:44:23 2019 Route addition via service succeeded
Wed Oct 16 19:44:23 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Oct 16 19:44:23 2019 Initialization Sequence Completed
Wed Oct 16 19:44:23 2019 MANAGEMENT: >STATE:1571251463,CONNECTED,SUCCESS,10.8.0.6,,1194,,
Wed Oct 16 19:52:10 2019 TUN/TAP I/O operation aborted, restarting
Wed Oct 16 19:52:10 2019 C:\WINDOWS\system32\route.exe DELETE 192.168.10.0 MASK 255.255.255.0 10.8.0.5
Wed Oct 16 19:52:10 2019 Warning: route gateway is not reachable on any active network adapters: 10.8.0.5
Wed Oct 16 19:52:10 2019 Route deletion via service failed
Wed Oct 16 19:52:10 2019 C:\WINDOWS\system32\route.exe DELETE 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Wed Oct 16 19:52:10 2019 Warning: route gateway is not reachable on any active network adapters: 10.8.0.5
Wed Oct 16 19:52:10 2019 Route deletion via service failed
Wed Oct 16 19:52:10 2019 Closing TUN/TAP interface
Wed Oct 16 19:52:10 2019 SIGHUP[soft,tun-abort] received, process restarting
Wed Oct 16 19:52:10 2019 MANAGEMENT: >STATE:1571251930,RECONNECTING,tun-abort,,,,,
Wed Oct 16 19:52:10 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Wed Oct 16 19:52:10 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Oct 16 19:52:10 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Wed Oct 16 19:52:10 2019 Restart pause, 10 second(s)
Wed Oct 16 20:35:59 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 20:35:59 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 20:35:59 2019 MANAGEMENT: >STATE:1571254559,RESOLVE,,,,,,
Wed Oct 16 20:36:00 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]:1194
Wed Oct 16 20:36:00 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Oct 16 20:36:00 2019 UDP link local: (not bound)
Wed Oct 16 20:36:00 2019 UDP link remote: [AF_INET]:1194
Wed Oct 16 20:36:00 2019 MANAGEMENT: >STATE:1571254560,WAIT,,,,,,
Wed Oct 16 20:36:00 2019 MANAGEMENT: >STATE:1571254560,AUTH,,,,,,
Wed Oct 16 20:36:00 2019 TLS: Initial packet from [AF_INET]:1194, sid=03a1f0ed d75b7d3c
Wed Oct 16 20:36:00 2019 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=IndigoRebel, OU=changeme, CN=Indigo, name=changeme, emailAddress=
Wed Oct 16 20:36:00 2019 VERIFY KU OK
Wed Oct 16 20:36:00 2019 Validating certificate extended key usage
Wed Oct 16 20:36:00 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Oct 16 20:36:00 2019 VERIFY EKU OK
Wed Oct 16 20:36:00 2019 VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=, OU=changeme, CN=server, name=changeme, emailAddress=r
Wed Oct 16 20:36:00 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Oct 16 20:36:00 2019 [server] Peer Connection Initiated with [AF_INET]:1194
Wed Oct 16 20:36:02 2019 MANAGEMENT: >STATE:1571254562,GET_CONFIG,,,,,,
Wed Oct 16 20:36:02 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Oct 16 20:36:02 2019 PUSH: Received control message: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: timers and/or timeouts modified
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: --ifconfig/up options modified
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: route options modified
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: peer-id set
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Wed Oct 16 20:36:02 2019 OPTIONS IMPORT: data channel crypto options modified
Wed Oct 16 20:36:02 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Oct 16 20:36:02 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 20:36:02 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 20:36:02 2019 interactive service msg_channel=680
Wed Oct 16 20:36:02 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=15 HWADDR=64:5d:86:de:ba:0c
Wed Oct 16 20:36:02 2019 open_tun
Wed Oct 16 20:36:02 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{A57A613B-71AD-4B08-B3ED-B21498CA0243}.tap
Wed Oct 16 20:36:02 2019 TAP-Windows Driver Version 9.21 
Wed Oct 16 20:36:02 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {A57A613B-71AD-4B08-B3ED-B21498CA0243} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Wed Oct 16 20:36:02 2019 Successful ARP Flush on interface [13] {A57A613B-71AD-4B08-B3ED-B21498CA0243}
Wed Oct 16 20:36:02 2019 MANAGEMENT: >STATE:1571254562,ASSIGN_IP,,10.8.0.6,,,,
Wed Oct 16 20:36:07 2019 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Oct 16 20:36:07 2019 MANAGEMENT: >STATE:1571254567,ADD_ROUTES,,,,,,
Wed Oct 16 20:36:07 2019 C:\WINDOWS\system32\route.exe ADD 192.168.10.0 MASK 255.255.255.0 10.8.0.5
Wed Oct 16 20:36:07 2019 Route addition via service succeeded
Wed Oct 16 20:36:07 2019 C:\WINDOWS\system32\route.exe ADD 10.8.0.1 MASK 255.255.255.255 10.8.0.5
Wed Oct 16 20:36:07 2019 Route addition via service succeeded
Wed Oct 16 20:36:07 2019 Initialization Sequence Completed
Wed Oct 16 20:36:07 2019 MANAGEMENT: >STATE:1571254567,CONNECTED,SUCCESS,10.8.0.6,,1194,,

Server log

Wed Oct 16 19:42:26 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Oct 16 19:42:26 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Oct 16 19:42:26 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Wed Oct 16 19:42:26 2019 Diffie-Hellman initialized with 2048 bit key
Wed Oct 16 19:42:26 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 19:42:26 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 19:42:26 2019 interactive service msg_channel=0
Wed Oct 16 19:42:26 2019 ROUTE_GATEWAY 192.168.10.1/255.255.255.0 I=2 HWADDR=00:25:64:b2:96:e4
Wed Oct 16 19:42:26 2019 open_tun
Wed Oct 16 19:42:26 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{7444F55E-5A93-429C-BFEE-1F5F8EB22D9E}.tap
Wed Oct 16 19:42:26 2019 TAP-Windows Driver Version 9.23 
Wed Oct 16 19:42:26 2019 Sleeping for 10 seconds...
Wed Oct 16 19:42:36 2019 Successful ARP Flush on interface [10] {7444F55E-5A93-429C-BFEE-1F5F8EB22D9E}
Wed Oct 16 19:42:36 2019 ******** NOTE:  Please manually set the IP/netmask of 'Ethernet 2' to 10.8.0.1/255.255.255.252 (if it is not already set)
Wed Oct 16 19:42:36 2019 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Wed Oct 16 19:42:36 2019 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Wed Oct 16 19:42:36 2019 Route addition via IPAPI succeeded [adaptive]
Wed Oct 16 19:42:36 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Wed Oct 16 19:42:36 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Oct 16 19:42:36 2019 setsockopt(IPV6_V6ONLY=0)
Wed Oct 16 19:42:36 2019 UDPv6 link local (bound): [AF_INET6][undef]:1194
Wed Oct 16 19:42:36 2019 UDPv6 link remote: [AF_UNSPEC]
Wed Oct 16 19:42:36 2019 MULTI: multi_init called, r=256 v=256
Wed Oct 16 19:42:36 2019 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Wed Oct 16 19:42:36 2019 ifconfig_pool_read(), in='Godzilla10,10.8.0.4', TODO: IPv6
Wed Oct 16 19:42:36 2019 succeeded -> ifconfig_pool_set()
Wed Oct 16 19:42:36 2019 ifconfig_pool_read(), in='Godzilla09,10.8.0.8', TODO: IPv6
Wed Oct 16 19:42:36 2019 succeeded -> ifconfig_pool_set()
Wed Oct 16 19:42:36 2019 IFCONFIG POOL LIST
Wed Oct 16 19:42:36 2019 Godzilla10,10.8.0.4
Wed Oct 16 19:42:36 2019 Godzilla09,10.8.0.8
Wed Oct 16 19:42:36 2019 Initialization Sequence Completed
Wed Oct 16 19:44:15 2019 :57852 TLS: Initial packet from [AF_INET6]::ffff::57852, sid=852a9d85 2711c85e
Wed Oct 16 19:44:15 2019 :57852 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=, OU=changeme, CN=Indigo, name=changeme, emailAddress=
Wed Oct 16 19:44:15 2019 :57852 VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=, OU=changeme, CN=Godzilla10, name=changeme, emailAddress=
Wed Oct 16 19:44:15 2019 7:57852 peer info: IV_VER=2.4.7
Wed Oct 16 19:44:15 2019 7:57852 peer info: IV_PLAT=win
Wed Oct 16 19:44:15 2019 9.77:57852 peer info: IV_PROTO=2
Wed Oct 16 19:44:15 2019 .77:57852 peer info: IV_NCP=2
Wed Oct 16 19:44:15 2019 39.77:57852 peer info: IV_LZ4=1
Wed Oct 16 19:44:15 2019 77:57852 peer info: IV_LZ4v2=1
Wed Oct 16 19:44:15 2019 57852 peer info: IV_LZO=1
Wed Oct 16 19:44:15 2019 :57852 peer info: IV_COMP_STUB=1
Wed Oct 16 19:44:15 2019852 peer info: IV_COMP_STUBv2=1
Wed Oct 16 19:44:15 2019 :57852 peer info: IV_TCPNL=1
Wed Oct 16 19:44:15 2019 39.77:57852 peer info: IV_GUI_VER=OpenVPN_GUI_11
Wed Oct 16 19:44:15 2019 .39.77:57852 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Oct 16 19:44:15 2019 
77:57852 [Godzilla10] Peer Connection Initiated with [AF_INET6]::ffff::57852
Wed Oct 16 19:44:15 2019 Godzilla10/77:57852 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Wed Oct 16 19:44:15 2019 Godzilla10/77:57852 MULTI: Learn: 10.8.0.6 -> Godzilla10/:57852
Wed Oct 16 19:44:15 2019 Godzilla10/:57852 MULTI: primary virtual IP for Godzilla10/:57852: 10.8.0.6
Wed Oct 16 19:44:17 2019 Godzilla10/77:57852 PUSH: Received control message: 'PUSH_REQUEST'
Wed Oct 16 19:44:17 2019 Godzilla10/7:57852 SENT CONTROL [Godzilla10]: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Wed Oct 16 19:44:17 2019 Godzilla10/7:57852 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Oct 16 19:44:17 2019 Godzilla10/7852 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 19:44:17 2019 Godzilla10/77:57852 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 19:46:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60146
Wed Oct 16 19:46:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60146
Wed Oct 16 19:46:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60146
Wed Oct 16 19:46:22 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60146
Wed Oct 16 19:46:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60146
Wed Oct 16 19:52:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:51889
Wed Oct 16 19:52:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:51889
Wed Oct 16 19:52:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:51889
Wed Oct 16 19:52:22 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:51889
Wed Oct 16 19:52:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:51889
Wed Oct 16 19:56:02 2019 Godzilla10/57852 [Godzilla10] Inactivity timeout (--ping-restart), restarting
Wed Oct 16 19:56:02 2019 Godzilla10/7:57852 SIGUSR1[soft,ping-restart] received, client-instance restarting
Wed Oct 16 19:58:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60102
Wed Oct 16 19:58:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60102
Wed Oct 16 19:58:23 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60102
Wed Oct 16 19:58:39 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:60102
Wed Oct 16 20:04:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54458
Wed Oct 16 20:04:11 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54458
Wed Oct 16 20:04:15 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54458
Wed Oct 16 20:04:23 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54458
Wed Oct 16 20:04:39 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54458
Wed Oct 16 20:10:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:56480
Wed Oct 16 20:10:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:56480
Wed Oct 16 20:10:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:56480
Wed Oct 16 20:10:22 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:56480
Wed Oct 16 20:10:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:56480
Wed Oct 16 20:16:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:57860
Wed Oct 16 20:16:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:57860
Wed Oct 16 20:16:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:57860
Wed Oct 16 20:16:22 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:57860
Wed Oct 16 20:16:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:57860
Wed Oct 16 20:22:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:50752
Wed Oct 16 20:22:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:50752
Wed Oct 16 20:22:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:50752
Wed Oct 16 20:22:21 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:50752
Wed Oct 16 20:22:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:50752
Wed Oct 16 20:28:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54832
Wed Oct 16 20:28:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54832
Wed Oct 16 20:28:14 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54832
Wed Oct 16 20:28:22 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54832
Wed Oct 16 20:28:38 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:54832
Wed Oct 16 20:34:08 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:65352
Wed Oct 16 20:34:10 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:65352
Wed Oct 16 20:34:15 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:65352
Wed Oct 16 20:34:23 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:65352
Wed Oct 16 20:34:39 2019 TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]::ffff:192.168.10.1:65352
Wed Oct 16 20:35:59 2019 :53749 TLS: Initial packet from [AF_INET6]::ffff:3749, sid=7330ad84 8745e66f
Wed Oct 16 20:35:59 2019 7:53749 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=IndigoRebel, OU=changeme, CN=Indigo, name=changeme, emailAddress=
Wed Oct 16 20:35:59 2019 39.77:53749 VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=IndigoRebel, OU=changeme, CN=Godzilla10, name=changeme, emailAddress=
Wed Oct 16 20:35:59 2019 77:53749 peer info: IV_VER=2.4.7
Wed Oct 16 20:35:59 2019 :53749 peer info: IV_PLAT=win
Wed Oct 16 20:35:59 2019 7:53749 peer info: IV_PROTO=2
Wed Oct 16 20:35:59 2019 7:53749 peer info: IV_NCP=2
Wed Oct 16 20:35:59 2019 .77:53749 peer info: IV_LZ4=1
Wed Oct 16 20:35:59 2019 77:53749 peer info: IV_LZ4v2=1
Wed Oct 16 20:35:59 2019 :53749 peer info: IV_LZO=1
Wed Oct 16 20:35:59 2019 77:53749 peer info: IV_COMP_STUB=1
Wed Oct 16 20:35:59 2019 77:53749 peer info: IV_COMP_STUBv2=1
Wed Oct 16 20:35:59 2019 :53749 peer info: IV_TCPNL=1
Wed Oct 16 20:35:59 2019 9.77:53749 peer info: IV_GUI_VER=OpenVPN_GUI_11
Wed Oct 16 20:35:59 2019 .77:53749 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Oct 16 20:35:59 2019 77:53749 [Godzilla10] Peer Connection Initiated with [AF_INET6]::ffff::53749
Wed Oct 16 20:35:59 2019 Godzilla10/9.77:53749 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Wed Oct 16 20:35:59 2019 Godzilla10/7:53749 MULTI: Learn: 10.8.0.6 -> Godzilla10/7:53749
Wed Oct 16 20:35:59 2019 Godzilla10/77:53749 MULTI: primary virtual IP for Godzilla10/.39.77:53749: 10.8.0.6
Wed Oct 16 20:36:00 2019 Godzilla10/9.77:53749 PUSH: Received control message: 'PUSH_REQUEST'
Wed Oct 16 20:36:00 2019 Godzilla10/77:53749 SENT CONTROL [Godzilla10]: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Wed Oct 16 20:36:00 2019 Godzilla10/9.77:53749 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Oct 16 20:36:00 2019 Godzilla10/.77:53749 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 20:36:00 2019 Godzilla10/77:53749 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

I just noticed in the server log it says

******** NOTE: Please manually set the IP/netmask of 'Ethernet 2' to 10.8.0.1/255.255.255.252 (if it is not already set)

I have the mask set as 255.255.255.0 Could that be the issue?

CraftyClown

TinCanTech wrote
CraftyClown wrote Is there a reason the OpenVPN mask is 255.255.255.255 instead of 255.255.255.0?
This is why log snippets are not enough, you must have changed your server config.

I suggest you read this:
https://forums.openvpn.net/viewtopic.php?f=7&t=7806

For your edification:
There are two approaches to making this work:
Routing, by setting up routing correctly.

NAT, which is the solution 300000 is trying to explain.

My client config is currently:

client
dev tun
proto udp
remote indigorebel.ddns.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert Godzilla10.crt
key Godzilla10.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3

and my server config is

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.255.0"
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
ip-win32 manual

I feel like I'm missing the wood for the trees here.

300000

can you uncommand this line ifconfig-pool-persist ipp.txt

add this one push "redirect-gateway local def1 " on server and restart again .

CraftyClown

300000 wrote can you uncommand this line ifconfig-pool-persist ipp.txt

add this one push "redirect-gateway local def1 " on server and restart again .

Nope still nothing 🙁

Here's the server log

Wed Oct 16 21:46:45 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Oct 16 21:46:45 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Oct 16 21:46:45 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Wed Oct 16 21:46:45 2019 Diffie-Hellman initialized with 2048 bit key
Wed Oct 16 21:46:45 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 21:46:45 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Oct 16 21:46:45 2019 interactive service msg_channel=0
Wed Oct 16 21:46:45 2019 ROUTE_GATEWAY 192.168.10.1/255.255.255.0 I=2 HWADDR=00:25:64:b2:96:e4
Wed Oct 16 21:46:45 2019 open_tun
Wed Oct 16 21:46:45 2019 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{7444F55E-5A93-429C-BFEE-1F5F8EB22D9E}.tap
Wed Oct 16 21:46:45 2019 TAP-Windows Driver Version 9.23 
Wed Oct 16 21:46:45 2019 Sleeping for 10 seconds...
Wed Oct 16 21:46:55 2019 Successful ARP Flush on interface [10] {7444F55E-5A93-429C-BFEE-1F5F8EB22D9E}
Wed Oct 16 21:46:55 2019 ******** NOTE:  Please manually set the IP/netmask of 'Ethernet 2' to 10.8.0.1/255.255.255.252 (if it is not already set)
Wed Oct 16 21:46:55 2019 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.2
Wed Oct 16 21:46:55 2019 Warning: route gateway is not reachable on any active network adapters: 10.8.0.2
Wed Oct 16 21:46:55 2019 Route addition via IPAPI failed [adaptive]
Wed Oct 16 21:46:55 2019 Route addition fallback to route.exe
Wed Oct 16 21:46:55 2019 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Wed Oct 16 21:46:55 2019 Could not determine IPv4/IPv6 protocol. Using AF_INET6
Wed Oct 16 21:46:55 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Oct 16 21:46:55 2019 setsockopt(IPV6_V6ONLY=0)
Wed Oct 16 21:46:55 2019 UDPv6 link local (bound): [AF_INET6][undef]:1194
Wed Oct 16 21:46:55 2019 UDPv6 link remote: [AF_UNSPEC]
Wed Oct 16 21:46:55 2019 MULTI: multi_init called, r=256 v=256
Wed Oct 16 21:46:55 2019 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Wed Oct 16 21:46:55 2019 Initialization Sequence Completed
Wed Oct 16 21:47:08 2019 7:58016 TLS: Initial packet from [AF_INET6]::ffff::58016, sid=ff6ed1b4 24e7c988
Wed Oct 16 21:47:08 2019 58016 VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=IndigoRebel, OU=changeme, CN=Indigo, name=changeme, emailAddress=
Wed Oct 16 21:47:08 2019 82.38.39.77:58016 VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=IndigoRebel, OU=changeme, CN=Godzilla10, name=changeme, emailAddress=
Wed Oct 16 21:47:08 2019 .77:58016 peer info: IV_VER=2.4.7
Wed Oct 16 21:47:08 2019 .77:58016 peer info: IV_PLAT=win
Wed Oct 16 21:47:08 2019 77:58016 peer info: IV_PROTO=2
Wed Oct 16 21:47:08 2019 9.77:58016 peer info: IV_NCP=2
Wed Oct 16 21:47:08 2019 9.77:58016 peer info: IV_LZ4=1
Wed Oct 16 21:47:08 2019 77:58016 peer info: IV_LZ4v2=1
Wed Oct 16 21:47:08 2019 .77:58016 peer info: IV_LZO=1
Wed Oct 16 21:47:08 2019 77:58016 peer info: IV_COMP_STUB=1
Wed Oct 16 21:47:08 2019 .77:58016 peer info: IV_COMP_STUBv2=1
Wed Oct 16 21:47:08 2019 39.77:58016 peer info: IV_TCPNL=1
Wed Oct 16 21:47:08 2019 9.77:58016 peer info: IV_GUI_VER=OpenVPN_GUI_11
Wed Oct 16 21:47:08 2019 9.77:58016 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Oct 16 21:47:08 2019 9.77:58016 [Godzilla10] Peer Connection Initiated with [AF_INET6]::ffff:82.38.39.77:58016
Wed Oct 16 21:47:08 2019 Godzilla10/9.77:58016 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Wed Oct 16 21:47:08 2019 Godzilla10/.77:58016 MULTI: Learn: 10.8.0.6 -> Godzilla10/82.38.39.77:58016
Wed Oct 16 21:47:08 2019 Godzilla10/.77:58016 MULTI: primary virtual IP for Godzilla10/82.38.39.77:58016: 10.8.0.6
Wed Oct 16 21:47:09 2019 Godzilla10/.77:58016 PUSH: Received control message: 'PUSH_REQUEST'
Wed Oct 16 21:47:09 2019 Godzilla10/7:58016 SENT CONTROL [Godzilla10]: 'PUSH_REPLY,route 192.168.10.0 255.255.255.0,redirect-gateway def1,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Wed Oct 16 21:47:09 2019 Godzilla10/9.77:58016 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Oct 16 21:47:09 2019 Godzilla10/.77:58016 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Oct 16 21:47:09 2019 Godzilla10/39.77:58016 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

CraftyClown

So 300000 earlier you said I shouldn't need any routing entries in my router if I do this your way, is that right?

So shall I remove them and try this again?