No connection on saved machine

Recently, within the past week, when I start a saved virtual machine, be it either whonix gateway or workstation, there will be no internet connection. When I click connect from the available connections it will tell me “IP configuration was unavailable”

This is on the newest version of whonix. I have tried reloading and restarting tor. If i power off the machine and restart it then the connection will work fine. So I am not sure what the problem is, as it has worked fine in the past.

Good day,

what network settings, did you set for Gateway and Workstation in the VBox settings?

Have a nice day,

Ego

Adapter 1
Attached to: NAT
Adapter Type: PCnet-Fast III (Am79C973)
Cable connected

Adapter 2
Attached to: Internal Network
Name: Whonix
Adapter Type: PCnet-Fast III (Am79C973)
Promiscuous Mode: Deny
Cable connected

This should be it:
Known Issues - Whonix

Thanks for the reply Patrick

When I try to run timesync in the saved machine with no connection, it tells me “[ERROR] [timesync] Network Time Synchronization (timesync) done, but no success!!!
Is your internet connection down?”

My internet connection is not down, and even before trying to run timesync, the machines time was the same as the host and actual time.

Exactly that is the known issue explained in the above link.

Okay. So I am now unable to save machine state because of this issue?

That would be the easiest or just read the documentation since it’s
already answered.

Sorry for the ignorance, but I am still not getting this.

As per the instructions above, I load up my saved workstation, start up a new gateway, then run timesync in my workstation, and it fails to complete or even progress the timesync.

When running it in terminal I get this
[INFO] [timesync] Whonix is produced independently of, with no guarantee from, The Tor Project. Whonix is experimental software. Do not rely on it for strong anonymity. https://www.whonix.org
[INFO] [timesync] Starting to watch /var/log/sdwdate.log…
[INFO] [timesync] Watching /var/log/sdwdate.log…
[INFO] [timesync] Running “sudo service sdwdate restart”…
9075: sdwdate (not timesync!): signal SIGTERM received…
9075: sdwdate (not timesync!): signal SIGTERM received. Cleaning up…
9075: sdwdate (not timesync!): signal SIGTERM received. Exiting.
11757: Running sdwdate… pid: 11757 | LD_PRELOAD:
11757: sdwdate_preparation: who_ami is set to user.
11757: dispatching DISPATCH_PRE (SDW_MODE: startup): /usr/lib/timesync/timesync_pre --autostart --identifier “timesync” --progressbaridx “$ID” --mode “$SDW_MODE” --whoami “$who_ami”
[INFO] [timesync] Done, restarted sdwdate, which should now be running in background…
11757: dispatching DISPATCH_PRE done.
11757: SDWDATE_CURRENT_POOL: SDWDATE_POOL_ONE | array_length: 14 | allowed_member_failures: 5 | temp: 4.76 | array_length_remember: 0
11757: dispatching DISPATCH_PREREQUISITE (SDW_MODE: startup) (LD_PRELOAD: ): /usr/lib/anon-shared-helper-scripts/te_pe_tb_check
11757: DISPATCH_PREREQUISITE exited 2 | Tor Bootstrap Result: Tor’s Control Port could not be reached. Did you start Gateway beforehand? Please run whonixcheck on Gateway. | waiting…

At this point gateway is running, and running whonixcheck within it tells me that it is connected to tor. Still nothing in my workstation. So I power off gateway and restart it. Still nothing.

Now timesync in workstation says it has failed. So I manually set the clock, which at this point is only 1 minute behind the host clock anyway. Still nothing.

As I mentioned before, I have never had this issue until about a week or so ago. Prior to that I would load my saved workstation, start a new gateway, and the internet in the workstation would work straight away without any issue.

bump

Short: Better do not suspend or hilbernate your computer or Whonix VMs while Whonix is running.

&

It’s recommended against to pause/suspend/save/hibernate the
Whonix-Gateway, because it’ll be difficult to restore the clock after
resume.

If the guy who put this thing together says, “Don’t do it”, why would you do it? and then come ask for help to fix it?

That said, if this is correct:

you might be dealing with a separate issue here.

Some info that would be helpful:

  1. VirtualBox adapter settings for Workstation (you only listed Gateway above)
  2. cat /etc/network/interfaces.d/30_non-qubes-whonix
  3. cat /etc/resolv.conf
  4. What does Whonixcheck in Workstation say?

Block out any sensitive IP addresses. Have you used a VPN recently that might have overwritten nameservers?

If the guy who put this thing together says, “Don’t do it”, why would you do it? and then come ask for help to fix it?

I had never saved gateway prior to this issue happening. When it happened and I could not connect in workstation, then and only then did I try saving gateway. Which is irrelevant anyway as the solution to saving gateway is simply running timesync, which I stated in detail in the above post did not work.

  1. VirtualBox adapter settings for Workstation (you only listed Gateway above)
    Attached to: Internal Network
    Adapter Type: PCnet-FAST III (Am79C973)
    Promiscuous Mode: Deny
    Cable connected

  2. cat /etc/network/interfaces.d/30_non-qubes-whonix

Loopback interface.

auto lo
iface lo inet loopback

When using Virtual Machines (not Physical Isolation),

- eth0 is an internal, isolated, virtual network

- provided and only visible inside Virtual Machines

- solely used to communicate with the Gateway

- it has no access to the host.

- Thus, the following IP address can NOT cause conflicts

with your LAN network or router.

auto eth0
iface eth0 inet static
## Increment last octet of address
## on optional additional workstations.
address 10.152.152.xx
netmask 255.255.192.0
gateway 10.152.152.xy

   ## Out commented.
   ## For what do we require the network and broadcast
   ## instances anyway?
   #network 192.168.0.0
   #broadcast 192.168.0.255

If we had a DHCP server running on Gateway’s

network interface eth1, we could alternatively use DHCP.

It has not been researched yet, if that were safe, or if

DHCP has in context of anonymity linux distributions any

odd features, such as “tell me the IP of your upstream router”.

#auto eth0
#iface eth0 inet dhcp

  1. cat /etc/resolv.conf
    nameserver 10.152.152.xy

  2. What does Whonixcheck in Workstation say?
    [ERROR] [whonixcheck] Tor Bootstrap Result:
    Tor’s Control Port could not be reached!

Troubleshooting:

  • Confirm that Whonix-Gateway is running.
  • Run whonixcheck on Whonix-Gateway and confirm success.
  • If you’re running multiple Whonix-Workstations simultaneously, confirm that separate IP addresses are configured (see Multiple Whonix-Workstation).
  • Rerun whonixcheck here in this Whonix-Workstation.

(Technical information:)
(Code: 255)
(tor_bootstrap_timeout_type: none)
(tor_bootstrap_status: Socket error: Received empty socket content.)
(check_socks_port_open_test: 7)
(Tor Circuit: not established)

Running whonixcheck in gateway confirms it is connected to tor

I have never used a VPN within whonix, but I do use one all the time on my host machine.

Network settings look correct assuming

  1. Internal Network = Whonix
  2. 10.152.152.xy = Gateway eth1 IP

Are you running multiple Workstations into the Gateway?

Actual / Local time doesn’t matter. All 3: Host, Gateway, Workstation are set to UTC, correct?

  1. & 2. Correct

I am only running one Workstation.

Gateway and Workstation are set to UTC, but my host machine is not, and never has been.

whonixhead:

Gateway and Workstation are set to UTC, but my host machine is not, and never has been.

Right, setting the host to UTC is neither required nor recommended.

Ah, didn’t know that. I thought this was saying that your host should be in UTC:

If your host clock (In UTC! [2][3]) is more than 1 hour in the past or more than 3 hours in the future, Tor can’t connect.

Maybe less ambiguous to replace “In UTC” with “when converted to UTC”. Or maybe it’s just me :slightly_smiling:

whonixhead, I’m out of ideas. Sorry can’t help more.

Thanks anyway for your help entr0py

entr0py:

Maybe less ambiguous to replace “In UTC” with “when converted to UTC”.

I am sure that also would be misunderstood. Needs to be even more explicit.