Eddie: Hangs at 'Checking route IPv4'

[Drew.Joe77.Crypto 1]

I recently updated to: eddie-ui_2.20.0_windows-10_x64_installer

Now, Eddie goes through latency checks and stops at the message in the subject line. Eddie will hang there for a long moment, then disconnect. Does anyone know what causes this problem and how to fix it? Thanks!

[RandomlyGenerated 0]

What is it that you are trying to do?

I am experiencing this same issue.

I am trying to daisychain VPN connections through VMWare Workstation.  I have a perfect (working) VPN connection on my host computer, then I start VMWare Workstation and go into a virtual windows machine ( I have also tried this with the same result in Manjaro (arch linux distro) and Ubuntu), then I attempt to connect to a new VPN connection within the VM and everything seems to go fine until it says "Checking route IPv4", then it just hangs for a very long time with no further details in the logs. I actually have to kill the process of eddie and openvpn daemon because eddie won't even respond to cancelling once that "Checking route IPv4" starts.

I have been doing this daisychain method for years with VMWare Workstation so I know it works. I think the issue may have something to do with wintun? I have tried wintun on the host machine then wintun in the vm. I have tried wintun on the host machine and TAP in the VM, both fail. The only time I have had success is when I did wintun on the host machine and then wintun in the VM, then I connected to the same server in the VM that I was already connected to on the host machine.

For me, I have all IPv6 turned off for all adapters (no IPv6 addresses showing in the network tab in eddie except loopback), and I specifically choose the correct adapter for both the host and the VM in eddie.

Any solutions for this issue would be highly appreciated.

[OpenSourcerer 1435]

2 hours ago, RandomlyGenerated said:

I have a perfect (working) VPN connection on my host computer, then I start VMWare Workstation and go into a virtual windows machine ( I have also tried this with the same result in Manjaro (arch linux distro) and Ubuntu), then I attempt to connect to a new VPN connection within the VM and everything seems to go fine until it says "Checking route IPv4", then it just hangs for a very long time with no further details in the logs. I actually have to kill the process of eddie and openvpn daemon because eddie won't even respond to cancelling once that "Checking route IPv4" starts.

Configure the VM network as a bridge and try again.
 

2 hours ago, RandomlyGenerated said:

For me, I have all IPv6 turned off for all adapters (no IPv6 addresses showing in the network tab in eddie except loopback)

Why, though?

[RandomlyGenerated 0]

1 hour ago, OpenSourcerer said:

Configure the VM network as a bridge and try again.
 
Why, though?

If I configure the network as a bridge then it is just a separate tunnel because VMWare is replicating a physical connection state. The point of NAT is to do a tunnel within a tunnel.

I have done this many times over the years. 0 issues until now and clearly I am not the only person getting this "Checking route IPv4" problem.

[OpenSourcerer 1435]

2 minutes ago, RandomlyGenerated said:

If I configure the network as a bridge then it is just a separate tunnel because VMWare is replicating a physical connection state. The point of NAT is to do a tunnel within a tunnel.

There were reports in the past about VM interfaces configured in NAT mode not being able to check reverse routes, is all I wanted to say. if it worked for you at some point – what's the last thing you did before it failed?
 

6 minutes ago, RandomlyGenerated said:

I have done this many times over the years. 0 issues until now and clearly I am not the only person getting this "Checking route IPv4" problem. 

Then trying to start the net config from scratch should be easy to rule out that sort of issue. You may not be the first person getting that error, but you are the first getting it in your specific setup.

[RandomlyGenerated 0]

17 minutes ago, OpenSourcerer said:

There were reports in the past about VM interfaces configured in NAT mode not being able to check reverse routes, is all I wanted to say. if it worked for you at some point – what's the last thing you did before it failed?

The failure point is when I moved to a newer experimental version of eddie and it included wintun. But I have also succeeded in getting this setup to work when I connect the instance of eddie inside the VM to the same AirVPN server that the host machine is connected to.
 

17 minutes ago, OpenSourcerer said:

Then trying to start the net config from scratch should be easy to rule out that sort of issue. You may not be the first person getting that error, but you are the first getting it in your specific setup.

Yeah, that's fair. My bad.

I'm still pretty confused why this isn't working. On paper it seems like it should be fine and straight forward, but this "Checking route IPv4" just doesn't want to go away. That is why I was so curious what the OP did to get this error.

EDIT: I just confirmed again that chaining VPN connections does work when I connect the instance of Eddie inside the VM to the same AirVPN server that the host machine is connected to. It works with TAP and with wintun. But as soon as I attempt to connect to any server other than the same as the host machine, it results in "Checking route IPv4" with no additional information in logs.

[OpenSourcerer 1435]

Are you still getting the error if you connect the guest only?

[Drew.Joe77.Crypto 1]

18 hours ago, OpenSourcerer said:

Are you still getting the error if you connect the guest only?

I am not sure how to do this, but if it will get Eddie up and running again, I am all for it.

It's very strange. Not only does having Eddie installed now result in the error message above with the failure to connect, it also seems to affect my ability to connect to the airvpn website! I now have Eddie uninstalled, and can access the website.

I am going to look for an older version of the Eddie installer in the hope that the update that is causing the problem will not be on the older version.
 

On 4/24/2021 at 8:11 AM, RandomlyGenerated said:

What is it that you are trying to do?

I am experiencing this same issue.

I am trying to daisychain VPN connections through VMWare Workstation.  I have a perfect (working) VPN connection on my host computer, then I start VMWare Workstation and go into a virtual windows machine ( I have also tried this with the same result in Manjaro (arch linux distro) and Ubuntu), then I attempt to connect to a new VPN connection within the VM and everything seems to go fine until it says "Checking route IPv4", then it just hangs for a very long time with no further details in the logs. I actually have to kill the process of eddie and openvpn daemon because eddie won't even respond to cancelling once that "Checking route IPv4" starts.

I have been doing this daisychain method for years with VMWare Workstation so I know it works. I think the issue may have something to do with wintun? I have tried wintun on the host machine then wintun in the vm. I have tried wintun on the host machine and TAP in the VM, both fail. The only time I have had success is when I did wintun on the host machine and then wintun in the VM, then I connected to the same server in the VM that I was already connected to on the host machine.

For me, I have all IPv6 turned off for all adapters (no IPv6 addresses showing in the network tab in eddie except loopback), and I specifically choose the correct adapter for both the host and the VM in eddie.

Any solutions for this issue would be highly appreciated.

I did nothing differently. That's what made this so odd. I was having issues connecting through IPv6 at first. If I restarted my computer from sleep mode, Eddie would get hung up at IPv6. The only way to correct this was to fully restart the computer before turning Eddie back on. I attempted the update in the hope that it would correct this issue, and found that no matter the boot method, I could not get Eddie to connect at all, and it was now terminating at the IPv4 message above. I also was having general connectivity issues, too, but those have improved.

[Drew.Joe77.Crypto 1]

I downloaded and installed an older version (2.19.7) of Eddie, and got exactly the same result. This is all Eddie will do now (see attached). Having Eddie installed also interferes with my ability to access this webpage. I cannot explain it.

All I can think to do now is reinstall the most recent version, get the same result, and then open a ticket with the log after uninstalling Eddie so I can get back to this webpage.

[OpenSourcerer 1435]

9 hours ago, Drew.Joe77.Crypto said:

I am not sure how to do this, but if it will get Eddie up and running again, I am all for it.

What do you mean, you're not sure? Connect Eddie only in the VM, don't connect with host…?!?

[Drew.Joe77.Crypto 1]

15 hours ago, OpenSourcerer said:

What do you mean, you're not sure? Connect Eddie only in the VM, don't connect with host…?!?

When I open Eddie (and it's working normally) it connects to a server under my login . I do not know how to change it to a 'Guest' setting in the virtual machine, and if it were not connected with a host, how would it route to the internet? I cannot say I have seen a 'Guest' setting.

 

[OpenSourcerer 1435]

5 hours ago, Drew.Joe77.Crypto said:

When I open Eddie (and it's working normally) it connects to a server under my login . I do not know how to change it to a 'Guest' setting in the virtual machine, and if it were not connected with a host, how would it route to the internet? I cannot say I have seen a 'Guest' setting.

A virtual machine is called a guest. The machine on which VMs run is called a host. It's an analogy to host-guest relationships in everyday life in which hosts share food, shelter and whatnot (= resources) with their guests while the guests generally can keep to themselves, though supervised by the host to some extent. It's what happens in virtualization, too.
I asked you not to connect on the physical machine but connect in the VM only and see if you still get the error in the VM.

[mikeb2k2001 1]

I found this post from another forum which solved the issue for me. I'm on v 2.20.0
 

Under the "DNS" settings tab, deselect "Check AirVPN DNS", then go to the "Advanced" tab and deselect "Check if the Tunnel Works".  Worked for me on v2.17.2

[OpenSourcerer 1435]

13 hours ago, mikeb2k2001 said:

Under the "DNS" settings tab, deselect "Check AirVPN DNS", then go to the "Advanced" tab and deselect "Check if the Tunnel Works".  Worked for me on v2.17.2 

What you're suggesting is to turn off the smoke alarm because it's too loud. This is not a long-term solution. Helps only if you know for a fact nothing can catch fire for a time.
It also doesn't solve the problem for OP, which is the unsuccessful Eddie connection in a VM.

[mikeb2k2001 1]

5 hours ago, OpenSourcerer said:

What you're suggesting is to turn off the smoke alarm because it's too loud. This is not a long-term solution. Helps only if you know for a fact nothing can catch fire for a time.
It also doesn't solve the problem for OP, which is the unsuccessful Eddie connection in a VM.

Indeed, The problem still remains but at least this way the VPN can connect. Without 'turning off the smoke alarm' one wouldn't be even able to get through the door, so at least we can have our internet fix for now...

Fingers crossed for a complete solution.

[OpenSourcerer 1435]

18 hours ago, mikeb2k2001 said:

Indeed, The problem still remains but at least this way the VPN can connect. Without 'turning off the smoke alarm' one wouldn't be even able to get through the door, so at least we can have our internet fix for now...

It is still not a fix. You're disabling a safety check. Eddie rightfully cancels the connection attempt because it couldn't verify a working tunnel. This could point to a legitimate problem with configuration, and in the case of a cascaded VPN connection (host and guest would like to connect to AirVPN) it will likely be the fact a reverse connection to Eddie in the VM gets dropped somewhere. If you disable such a check in the VM, and the tunnel is really not working as it should, you got yourself a leak.
 

18 hours ago, mikeb2k2001 said:

Fingers crossed for a complete solution.

Working on it with OP.

[madrat 19]

On 5/2/2021 at 3:53 AM, OpenSourcerer said:

It is still not a fix. You're disabling a safety check. Eddie rightfully cancels the connection attempt because it couldn't verify a working tunnel. This could point to a legitimate problem with configuration, and in the case of a cascaded VPN connection (host and guest would like to connect to AirVPN) it will likely be the fact a reverse connection to Eddie in the VM gets dropped somewhere. If you disable such a check in the VM, and the tunnel is really not working as it should, you got yourself a leak.
 
Working on it with OP.

Just to throw my 2 cents into the pile, I had the same problem and was told by admin - "Hello and thank you for your choice!

Please try the following settings:
- from Eddie's main window select "Preferences" > "Advanced"
- de-tick "Check if the VPN tunnel works"
- click "Save"
- from Eddie's main windows select "Preferences" > "DNS"
- de-tick "Check Air VPN DNS"
- from Eddie's main window enable "Network Lock" option (important, because you have disable some safety check previously)

Test again a connection to reproduce the issue and check whether the connection goes through this time. If so, go to ipleak.net web site and make sure that everything is fine.

We are looking forward to hearing from you.

Kind regards
AirVPN Support Team"
 
So, if it is a temporary fix, I hope admin will try and correct it in the future.

[OpenSourcerer 1435]

That's a weird suggestion for a solution. The check is there so you don't have to go to ipleak.net yourself and check the tunnel everytime you connect. Unless, of course, this suggestion was meant to be a temporary workaround after identifying the actual problem, in which case it is imperative to emphasize the temporary nature of this suggestion.

[madrat 19]

On 5/4/2021 at 7:03 AM, OpenSourcerer said:

That's a weird suggestion for a solution. The check is there so you don't have to go to ipleak.net yourself and check the tunnel everytime you connect. Unless, of course, this suggestion was meant to be a temporary workaround after identifying the actual problem, in which case it is imperative to emphasize the temporary nature of this suggestion.

If they have identified the actual problem, I am not aware of it, unless they are working on it for a future update. I've gone back and re-checked both boxes and will see what happens. I agree with you. It seems like a temporary solution.

[Drew.Joe77.Crypto 1]

On 4/30/2021 at 1:46 PM, mikeb2k2001 said:

I found this post from another forum which solved the issue for me. I'm on v 2.20.0
 

Under the "DNS" settings tab, deselect "Check AirVPN DNS", then go to the "Advanced" tab and deselect "Check if the Tunnel Works".  Worked for me on v2.17.2

THIS WORKED! Thank you!

[Drew.Joe77.Crypto 1]

4 hours ago, Drew.Joe77.Crypto said:

On 4/30/2021 at 1:46 PM, mikeb2k2001 said:

I found this post from another forum which solved the issue for me. I'm on v 2.20.0
 

Under the "DNS" settings tab, deselect "Check AirVPN DNS", then go to the "Advanced" tab and deselect "Check if the Tunnel Works".  Worked for me on v2.17.2

THIS WORKED! Thank you!

...AAAAAAaaannndd now it's NOT working again. I cannot win.

[Drew.Joe77.Crypto 1]

On 4/27/2021 at 2:00 AM, OpenSourcerer said:

A virtual machine is called a guest. The machine on which VMs run is called a host. It's an analogy to host-guest relationships in everyday life in which hosts share food, shelter and whatnot (= resources) with their guests while the guests generally can keep to themselves, though supervised by the host to some extent. It's what happens in virtualization, too.
I asked you not to connect on the physical machine but connect in the VM only and see if you still get the error in the VM.

How do I connect in the VM only?

[Drew.Joe77.Crypto 1]

On 5/3/2021 at 7:05 PM, madrat said:

Just to throw my 2 cents into the pile, I had the same problem and was told by admin - "Hello and thank you for your choice!

Please try the following settings:
- from Eddie's main window select "Preferences" > "Advanced"
- de-tick "Check if the VPN tunnel works"
- click "Save"
- from Eddie's main windows select "Preferences" > "DNS"
- de-tick "Check Air VPN DNS"
- from Eddie's main window enable "Network Lock" option (important, because you have disable some safety check previously)

Test again a connection to reproduce the issue and check whether the connection goes through this time. If so, go to ipleak.net web site and make sure that everything is fine.

We are looking forward to hearing from you.

Kind regards
AirVPN Support Team"
 
So, if it is a temporary fix, I hope admin will try and correct it in the future.

Instead of hanging on the previously screen capped window (IPv4), it cycles through servers, apparently not connecting to any.

The attached window is the only screen that might have different settings than the ones described above. I believe I have reset them to where they were before.

I tried wintun once. It had no effect.

[Drew.Joe77.Crypto 1]

I have uninstalled Eddie again. ☠️

[OpenSourcerer 1435]

5 hours ago, Drew.Joe77.Crypto said:

...AAAAAAaaannndd now it's NOT working again. I cannot win.

Could've told you right away that it won't work; your problem is somewhere between host and guest not properly forwarding requests one way or the other. Even the posts after the one I quoted hint at that; it's not an issue of Eddie.

But then again, if it's uninstalled, there is no reason to continue the troubleshooting session. Hope you find a solution.