ANSWERED Suddenly I cannot connect - keeps happening

[Greyzy 1]

Hi there,

yesterday everything went fine and today no connection is made (the PC was off inbetween, nothing else changed).

Here's the part from the log that keeps repeating (I attached the error log as a file also):
 

. 2024.04.28 09:35:29 - OpenVPN > [Alchiba] Peer Connection Initiated with [AF_INET]213.152.161.180:443
. 2024.04.28 09:35:29 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.5.133.1,dhcp-option DNS6 fde6:7a:7d20:185::1,tun-ipv6,route-gateway 10.5.133.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:185::10f1/64 fde6:7a:7d20:185::1,ifconfig 10.5.133.243 255.255.255.0,peer-id 0,cipher AES-256-GCM'
. 2024.04.28 09:35:29 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp'
. 2024.04.28 09:35:29 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:185::1'
. 2024.04.28 09:35:29 - OpenVPN > Pushed option removed by filter: 'tun-ipv6'
. 2024.04.28 09:35:29 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:185::10f1/64 fde6:7a:7d20:185::1'
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1627
. 2024.04.28 09:35:29 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2024.04.28 09:35:29 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2024.04.28 09:35:29 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2024.04.28 09:35:29 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2024.04.28 09:35:29 - OpenVPN > interactive service msg_channel=0
. 2024.04.28 09:35:29 - OpenVPN > ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=19 HWADDR=d0:17:c2:8a:0f:49
. 2024.04.28 09:35:29 - OpenVPN > open_tun
. 2024.04.28 09:35:30 - OpenVPN > tap-windows6 device [LAN-Verbindung 5] opened
. 2024.04.28 09:35:30 - OpenVPN > TAP-Windows Driver Version 9.21
. 2024.04.28 09:35:30 - OpenVPN > Set TAP-Windows TUN subnet mode network/local/netmask = 10.5.133.0/10.5.133.243/255.255.255.0 [SUCCEEDED]
. 2024.04.28 09:35:30 - OpenVPN > Notified TAP-Windows driver to set a DHCP IP/netmask of 10.5.133.243/255.255.255.0 on interface {F769143F-7A04-419D-B854-C37C888BA59C} [DHCP-serv: 10.5.133.254, lease-time: 31536000]
. 2024.04.28 09:35:30 - OpenVPN > Successful ARP Flush on interface [20] {F769143F-7A04-419D-B854-C37C888BA59C}
. 2024.04.28 09:35:30 - OpenVPN > IPv4 MTU set to 1500 on interface 20 using SetIpInterfaceEntry()
. 2024.04.28 09:35:34 - OpenVPN > TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
. 2024.04.28 09:35:34 - OpenVPN > C:\Windows\system32\route.exe ADD 213.152.161.180 MASK 255.255.255.255 192.168.0.1
. 2024.04.28 09:35:34 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
. 2024.04.28 09:35:34 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:34 - OpenVPN > C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.5.133.1
. 2024.04.28 09:35:34 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
. 2024.04.28 09:35:34 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:34 - OpenVPN > C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.5.133.1
. 2024.04.28 09:35:34 - OpenVPN > ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
. 2024.04.28 09:35:34 - OpenVPN > Route addition via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:34 - Interface LAN-Verbindung 5 metric changed from Automatic to 3, layer IPv4
. 2024.04.28 09:35:34 - Interface LAN-Verbindung 5 metric changed from Automatic to 3, layer IPv6
. 2024.04.28 09:35:35 - DNS leak protection with packet filtering enabled.
. 2024.04.28 09:35:36 - DNS IPv4 of a network adapter forced (LAN-Verbindung 5, from manual (10.24.209.1) to 10.5.133.1)
. 2024.04.28 09:35:36 - DNS IPv4 of a network adapter forced (LAN-Verbindung 4, from automatic to 10.5.133.1)
. 2024.04.28 09:35:36 - Routes, added a new route, 213.152.161.181 for gateway 10.5.133.1
. 2024.04.28 09:35:36 - Unable to compute route for 2a00:1678:2470:19:9016:df76:43b5:703e: IPv6 VPN gateway not available.
. 2024.04.28 09:35:36 - Flushing DNS
I 2024.04.28 09:35:36 - Checking route IPv4
. 2024.04.28 09:35:37 - Fetch url error:SSL connect error
. 2024.04.28 09:35:37 - Checking route (2° try)
. 2024.04.28 09:35:38 - Fetch url error:SSL connect error
. 2024.04.28 09:35:38 - Checking route (3° try)
. 2024.04.28 09:35:40 - Fetch url error:SSL connect error
E 2024.04.28 09:35:40 - Checking route IPv4 failed.
. 2024.04.28 09:35:40 - OpenVPN > Initialization Sequence Completed
! 2024.04.28 09:35:40 - Disconnecting
. 2024.04.28 09:35:40 - Routes, removed a route previously added, 213.152.161.181 for gateway 10.5.133.1
. 2024.04.28 09:35:40 - Sending soft termination signal
. 2024.04.28 09:35:43 - Connection terminated.
. 2024.04.28 09:35:43 - IPv6 restored with packet filtering.
. 2024.04.28 09:35:43 - DNS IPv4 of a network adapter restored to original settings (LAN-Verbindung 5, to 10.24.209.1)
. 2024.04.28 09:35:44 - DNS IPv4 of a network adapter restored to original settings (LAN-Verbindung 4, to automatic)
. 2024.04.28 09:35:44 - DNS leak protection with packet filtering disabled.
. 2024.04.28 09:35:44 - Interface LAN-Verbindung 5 metric restored from 3 to Automatic, layer IPv4
. 2024.04.28 09:35:44 - Interface LAN-Verbindung 5 metric restored from 3 to Automatic, layer IPv6
. 2024.04.28 09:35:44 - OpenVPN > C:\Windows\system32\route.exe DELETE 213.152.161.180 MASK 255.255.255.255 192.168.0.1
. 2024.04.28 09:35:44 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:44 - OpenVPN > C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.5.133.1
. 2024.04.28 09:35:44 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:44 - OpenVPN > C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.5.133.1
. 2024.04.28 09:35:44 - OpenVPN > Route deletion via IPAPI succeeded [adaptive]
. 2024.04.28 09:35:44 - OpenVPN > Closing TUN/TAP interface
. 2024.04.28 09:35:44 - OpenVPN > TAP: DHCP address released
. 2024.04.28 09:35:44 - OpenVPN > SIGTERM[hard,] received, process exiting
I 2024.04.28 09:35:47 - Checking authorization ...
. 2024.04.28 09:35:48 - IPv6 disabled with packet filtering.

I read in other posts that logging out and back in can be a solution. I tried that, but it didn't help (it had worked before a few weeks back).

Please advise how to fix this!

Thanks,
Tom

 

Eddie error.txt

[Greyzy 1]

I also read in another post that switching to wireguard might help:
 

Quote

To do so:

• from Eddie's main window please select "Preferences" > "Protocols"
• uncheck "Automatic"
• select the line with WireGuard port 51820. The line will be highlighted
• click "Save" and test again connections to various servers

Problem is: that's not in my list of protocols! Why is that? Do I need to install it somehow?

Please help!

Thanks,
Tom

[Staff 9972]

@Greyzy

Hello!

The SSL connect error is fatal. It could be caused by some packet filtering tool blocking specific connections (please check) or some incompatibility with Windows 7. Please consider to upgrade to a more modern system, if possible.

WireGuard availability in Eddie starts from version 2.21.2: if you're running an older version, WireGuard is not supported by Eddie. Also, maybe the support is missing in your Windows 7 and even if you run a more modern Eddie version it will be unable to offer WireGuard connections.

Please consider, if possible, to upgrade to a more modern system. If for some sinister reason you are stuck with Windows 7 and want to try WireGuard but Eddie can't run it, you can consider the native software, which is still Windows 7 compatible for now. Instructions are available here:
https://airvpn.org/windows/wireguard/gui/

Kind regards
 

[Greyzy 1]

Thanks for your reply!
I upgraded to the latest version of EDDIE, but WireGuard still doesn't show up in the list. I then did what the last link said (install WireGuard that way).

How does that work then?
- do I still need to run EDDIE in addition to the WireGuard tool?
- can I run WireGuard in "network lock" mode (= if the tunnel breaks down no other connection is made)?
- how fast is the WireGuard connection (any limits?)?

[monstrocity 31]

In Windows 7, completely remove Eddie and install Wireguard msi: https://download.wireguard.com/windows-client/
Go to the client area, setup your config files for the servers you mainly use, and download them.
Rename your config files to something short, like the "server name".config
Import your config files into the WireGuard interface.
Once you've added your config files to WireGuard, choose a tunnel and click on edit.
You should see "Block untunneled traffic (kill-switch). Make sure it's checked.

You may need to adjust the default MTU of 1320 that's offered in the AirVPN client area.
You can modify the config files in the WireGuard application itself using the edit button, where it says MTU in the screenshot. (Or, you can modify the config files in notepad or better yet, notepad++, and re-import them.) 
I had to raise mine for the tunnel to work. If MTU 1320 doesn't work for you, experiment with one config file, adjusting the MTU by 10 or so until the tunnel is stable. Make sure to deactivate the tunnel before modifying the MTU.

[Greyzy 1]

Thanks for your reply! I did what you wrote and set up WireGuard. The tunnel appears to be working fine (I can surf the internet and see that the IP has been changed).

My problem is now that I cannot connect to my NAS anymore. I reconnected the drives in the explorer to their drive letters by using their internal IP addresses (192.168.0.xxx\folder), but I still cannot connect. As soon as I turn off the tunnel the drives are back.

How can I fix that?

[monstrocity 31]

Connecting to a NAS using WireGuard is well beyond my expertise. Perhaps other members or @Staff have some advice here.

[Staff 9972]

@Greyzy

Hello!

The solution is relatively simple when you use a subnet calculator: you must tell WireGuard that some subnet (in this case your local network) must NOT fall into the VPN tunnel through the AllowedIPs directive.

The AllowedIPs directive in the WireGuard *.conf file lists the set of IP addresses that the local host should route to the remote peer through the WireGuard tunnel. By constructing from the global address space the complementary set of the range of your subnetwork you will solve the problem.

Please read the following thread for more complete explanations and definite solution:
https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?tab=comments#comment-217411

Kind regards
 

[Greyzy 1]

Yes, I just want to have access to my local drives (media players, NAS) as when WireGuard is not running. If WireGuard blocks traffic in my LAN (to my drives) then it's useless.
 

[go558a83nk 362]

30 minutes ago, Staff said:

@Greyzy

Hello!

The solution is relatively simple when you use a subnet calculator: you must tell WireGuard that some subnet (in this case your local network) must NOT fall into the VPN tunnel through the AllowedIPs directive.

The AllowedIPs directive in the WireGuard *.conf file lists the set of IP addresses that the local host should route to the remote peer through the WireGuard tunnel. By constructing from the global address space the complementary set of the range of your subnetwork you will solve the problem.

Please read the following thread for more complete explanations and definite solution:
https://airvpn.org/forums/topic/55801-wireguard-access-local-network/?tab=comments#comment-217411

Kind regards
 

The one thing that confuses me about this well known list of IP ranges is that 64.0.0.0/2 includes in its range the 127.x.x.x. addresses - localhost.  So I guess then that any request on the system to localhost would be sent out the VPN tunnel except that it reaches its destination before it's sent to the virtual adapter?

[Greyzy 1]

@Staff Thanks for your help!

It works now, after I did NOT include the IPv6 addresses in the calculator's first input field (I listed all my local IP addresses in the second input field).
 

Quote

This indicates to WireGuard that all IPv4 addresses (0.0.0.0/0) and all IPv6 addresses (::/0) should be routed through the peer.

In the final output result there is no '::/0' (it was there before when my local drives were still blocked).

In the post you mentioned someone reported leaking of his IP address. I checked with https:://ipleak.net and didn't see a problem. Any recommendations how to check for and prevent leaking?

[Staff 9972]

19 minutes ago, go558a83nk said:

The one thing that confuses me about this well known list of IP ranges is that 64.0.0.0/2 includes in its range the 127.x.x.x. addresses - localhost.  So I guess then that any request on the system to localhost would be sent out the VPN tunnel except that it reaches its destination before it's sent to the virtual adapter? 

Hello!

No worries, as loopback is directly connected. For the same reason "everything works" when you specify in AllowedIPs the whole IPv4 space with 0.0.0.0/0, which is the default settings in so many configurations.

Kind regards
 

[Greyzy 1]

8 hours ago, monstrocity said:

You should see "Block untunneled traffic (kill-switch). Make sure it's checked.

 

After I edited the "AllowedIPs" setting in the config file I no longer see the checkbox for the "kill switch". Is there another way to activate this? Maybe a command line in the config?

@Staff Any ideas from you?

[Staff 9972]

4 minutes ago, Greyzy said:

After I edited the "AllowedIPs" setting in the config file I no longer see the checkbox for the "kill switch". Is there another way to activate this? Maybe a command line in the config?

@Staff Any ideas from you?

Hello!

We think WireGuard developers are correct, as you can't allow some traffic outside tunnel AND block all traffic outside the tunnel. Therefore that option correctly disappears. You can consider to block traffic leaks (except for the local network) with firewall rules.

Kind regards
 

[Greyzy 1]

I found this post elsewhere: https://www.ivpn.net/knowledgebase/linux/linux-wireguard-kill-switch/

I added the code from step #2, but I am not sure if this works on my WIN-7 PC as it was posted in the GNU/LINUX section. Any comments?