ANSWERED Checking IPv4 route stuck...

[Sister123 0]

Hello

I'm using Eddy UI on Windows 10, version 2.21.8. i have USB GSM Modem.

When I'm trying to connect my AirVPN it's getting stuck on Checking Ipv4 route... what I can do now

Here is the log file as well

. 2024.04.11 19:42:53 - Flushing DNS
I 2024.04.11 19:42:53 - Checking route IPv4
. 2024.04.11 19:44:03 - Checking route (4° try)
. 2024.04.11 19:44:28 - Checking route (5° try)
E 2024.04.11 19:44:49 - Checking route IPv4 failed, last reason: Fetch url error:Timeout was reached
! 2024.04.11 19:44:49 - Disconnecting
. 2024.04.11 19:44:49 - Sending soft termination signal
. 2024.04.11 19:44:52 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2024.04.11 19:44:54 - OpenVPN > Closing TUN/TAP interface
. 2024.04.11 19:44:54 - OpenVPN > delete_route_ipv6(fde6:7a:7d20:ba::/64)
. 2024.04.11 19:44:54 - OpenVPN > C:\WINDOWS\system32\netsh.exe interface ipv6 delete route fde6:7a:7d20:ba::/64 4 fe80::8 store=active
. 2024.04.11 19:44:54 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ipv6 delete address 4 fde6:7a:7d20:ba::10d7 store=active
. 2024.04.11 19:44:54 - OpenVPN > NETSH: C:\WINDOWS\system32\netsh.exe interface ipv4 delete address 4 10.4.186.217 store=active
. 2024.04.11 19:44:54 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2024.04.11 19:44:55 - Routes, delete 0.0.0.0/1 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:55 - Routes, delete 128.0.0.0/1 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:56 - Routes, delete ::/1 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:56 - Routes, delete 8000::/1 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:57 - Routes, delete 185.104.184.45/32 for interface "Wi-Fi (Broadcom 802.11n Network Adapter)".
. 2024.04.11 19:44:57 - Routes, delete 185.104.184.43/32 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:57 - Routes, delete 2001:ac8:20:5:e56b:4c39:f245:7761/128 for interface "Eddie (Wintun Userspace Tunnel)".
. 2024.04.11 19:44:57 - Routes, delete 185.104.184.45/32 for interface "Wi-Fi (Broadcom 802.11n Network Adapter)", not exists.
. 2024.04.11 19:44:58 - DNS IPv4 of a network adapter restored to original settings (Eddie, to automatic)
. 2024.04.11 19:44:58 - DNS IPv6 of a network adapter restored to original settings (Eddie, to automatic)
. 2024.04.11 19:44:58 - DNS IPv4 of a network adapter restored to original settings (Ethernet 2, to automatic)
. 2024.04.11 19:44:58 - DNS IPv6 of a network adapter restored to original settings (Ethernet 2, to automatic)
. 2024.04.11 19:44:58 - DNS leak protection with packet filtering disabled.
. 2024.04.11 19:44:58 - Interface Eddie metric restored from 3 to Automatic, layer IPv4
. 2024.04.11 19:44:58 - Interface Eddie metric restored from 3 to Automatic, layer IPv6
. 2024.04.11 19:44:58 - Connection terminated.
I 2024.04.11 19:45:00 - Cancel requested.
! 2024.04.11 19:45:00 - Session terminated.
 

[Staff 10014]

@Sister123

Hello!

To verify whether it's some block against UDP or not, could you please test a connection over WireGuard and check whether it goes through successfully? To switch to WireGuard:

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

Kind regards
 

[Sister123 0]

Thanks for your reply.

I did as you mentioned , connected to WireGuard official port 51820 and connection was successfull.

So what can I do now. It's safe to connect this way? My privacy is not less doing it that way? Should I use selected protocol? 

Thanks.

[Staff 10014]

@Sister123

Hello!

Yes, it's safe, and you could even get better performance.

The outcome shows that there is no general UDP block. Either the check route failure recorded by Eddie is a false positive, or there is actually something blocking OpenVPN when it works in UDP to port 443. To quickly discern (if you are curious to know) you could disable route and DNS check, go back to OpenVPN and verify whether the connection is successful:

• switch back to the previous OpenVPN + UDP port 443 connection mode
• from Eddie's main window select "Preferences" > "Advanced"
• uncheck "Check if the VPN tunnel works"
• click "Save"
• select "Preferences" > "DNS"
• uncheck "Check Air VPN DNS"
• click "Save"
• enable Network Lock
• try again a connection and test whether traffic goes through

If the connection is successful and the traffic goes through fine, then Eddie is wrong and the route check failure is a false positive (for unknown reasons, at the moment). Otherwise, there's really something interfering, in which case you can check any packet filtering tool both on your router and system. In this last case, if you find nothing blocking then the block is most probably enforced by your ISP.

Kind regards