Unable to get VPN Before Tor (User -> VPN -> Tor -> Internet) working, network interfaces are reset

Support
42

Hi 0brand,

I tried your suggestion.

When I execute the command:

aa-disable /etc/apparmor.d/user.lib.sdwdate.url_to_unixtime

This error is printed:

ERROR: Invalid or unknown keywords in 'signal set=(rtmin+*) peer=unconfined

43

Sorry, my mistake:

sudo aa-disable /etc/apparmor.d/user.lib.sdwdate.url_to_unixtime

Try:

sudo aa-disable /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime

1 Like
44

Thanks but I tried both usr and user, the error is the same, unfortunately.

45

Sorry to keep pestering people with this, and special thanks to 0brand, but if this is indeed just a matter of disabling apparmor, would anyone know what my error is?

I am using:

aa-disable /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime

usr, not user, but I’ve tried both.

The file (/etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime) exists though. Not sure why this command doesn’t work. The error means nothing to me.

46 
sudo aa-disable /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime

ERROR: Values added to a non-existing variable @{HOMEDIRS}: /rw/home/ in tunables/home.d/live-mode

47

Disable.

sudo mv /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime /root

And reboot.

Re-enable.

sudo mv /root/usr.lib.sdwdate.url_to_unixtime /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime

And reboot.

Untested.

I would be beyond surprised if /etc/apparmor.d/usr.lib.sdwdate.url_to_unixtime is the cause, though.

48

I’ve tested it now. I used the approach suggested by Patrick.

The exact same problem still happens.

I still get:

pcnet32 0000:00:03.0 eth0: link up, 100Mbps, full-duplex
pcnet32 0000:00:08.0 eth1: link up, 100Mbps, full-duplex

49

The good news, I realized the problem was in the logs all along. The bad news, your system is not keeping the correct time. Meaning your clock is jumping ahead. Under normal use (no vpn) time sync is able to correct this but using a VPN is compounding this issue.

See how sdwdate is jumping 1 hour ahead of your OpenVPN logs? But this is happening at the same time.(should both have the same time stamps) Take a look at the rest of your logs and pay attention to the time stamps.

Just to elaborate: Even though sdwdate is set to sleep for 70 minutes try to ignore that when you look at the rest of your logs. I think its pretty clear because Tor can not be fully bootstrapped when your VPN connection is down. Time problem.

Openvpn.log

Sat Nov 24 15:26:13 2018 TUN/TAP device tun0 opened

Sat Nov 24 15:26:13 2018 Note: Cannot set tx queue length on tun0: Operation not permitted (errno=1)

Sat Nov 24 15:26:13 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

Sat Nov 24 15:26:13 2018 /usr/bin/ip_unpriv link set dev tun0 up mtu [redacted]

Sat Nov 24 15:26:13 2018 /usr/bin/ip_unpriv addr add dev tun0 [redacted]/24 broadcast [redacted]

Sat Nov 24 15:26:18 2018 /usr/bin/ip_unpriv route add [redacted]/32 via 10.0.2.2

Sat Nov 24 15:26:18 2018 /usr/bin/ip_unpriv route add 0.0.0.0/1 via [redacted]

Sat Nov 24 15:26:18 2018 /usr/bin/ip_unpriv route add 128.0.0.0/1 via [redacted]

Sat Nov 24 15:26:18 2018 UID set to tunnel

Sat Nov 24 15:26:18 2018 Initialization Sequence Completed

Sat Nov 24 15:30:39 2018 [server] Inactivity timeout (–ping-restart), restarting

Sat Nov 24 15:30:39 2018 SIGUSR1[soft,ping-restart] received, process restarting

Sat Nov 24 15:30:39 2018 Restart pause, 5 second(s)

sdwdate.log

2018-11-24 15:27:49 - sdwdate - INFO - Success. Sleeping for 70 minutes.

2018-11-24 15:27:49 - sdwdate - INFO - Running command: sleep 4200.139213678

2018-11-24 15:27:50 - /usr/bin/whonix-gateway-firewall - OK: Skipping firewall mode detection since already set to ‘full’.

2018-11-24 15:27:50 - /usr/bin/whonix-gateway-firewall - OK: (Full torified network access allowed.)

2018-11-24 15:27:50 - /usr/bin/whonix-gateway-firewall - OK: Whonix firewall loaded.

2018-11-24 16:37:50 - sdwdate - WARNING - Clock got changed by something other than sdwdate. seconds_to_sleep: 4200 time_delta: 4201

2018-11-24 16:37:50 - sdwdate - INFO - Running sdwdate main loop. iteration: 2 / 10000

2018-11-24 16:37:50 - sdwdate - INFO - Running sdwdate main loop. iteration: 2 / 10000

2018-11-24 16:37:50 - sdwdate - INFO - Prerequisite check: The clock is sane.

Within build timestamp Sat May 12 16:21:25 UTC 2018 and expiration timestamp Tue May 17 10:00:00 UTC 2033.

Clock within consensus parameters consensus/valid-after 2018-11-24 14:00:00 and consensus/valid-until 2018-11-24 17:00:00.

2018-11-24 16:37:50 - sdwdate - INFO - Prerequisite check: Tor fully bootstrapped.

2 Likes
50

2 posts were split to a new topic: How to route Windows internal network to Whonix?

51

Awesome work. What should I do? Should I force my clock to be correct? I believe I’ve tried that before using date and then hwclock --systohc.

I’ll try again in the meantime, while I’m waiting for advice.

52

Unfortunately I don’t have an answer for you. You can try #Clock_Fix but I don’t think that will help. Setting the correct time generally works only if your clock is not jumping. This can only be answered by someone more experienced. To start maybe do a little research to see if your hardware has this problem?

2 Likes
53

Thanks.

I will start with trying on different hardware to rule out hardware issues.

I wasn’t aware that my clock was jumping around. I’ve never noticed this before and I’m not noticing it now. Why this would be a problem only within a Whonix gateway guest box, is beyond me.

54

I’ve tested on different hardware now.

I haven’t actually tested VPN+Tor, but I did test only Tor, and I noticed the same jump in time in sdwdate’s log file.

The time is 23, then it jumps back to 22! Just as sdwdate performs its /bin/date --set operations!

Both my host time and guest time (before sdwdate runs!) is not UTC, and I think it is related to that, I’ve also read this:

“Warning: The system clock inside Whonix is set to UTC to prevent against time zone leaks. This means it may be a few hours ahead or behind the user’s host system clock. It is strongly recommended not to change this setting.”

So perhaps this behavior is normal, and we’re back to square one?

55

I have some interesting news.

On different hardware. I DON’T HAVE THIS ISSUE.

However, before I get too excited I will note that:

On working hardware, I’m using the 14.0.0.9.6 CLI version.
On the “defective” hardware, I’m using 14.0.0.7.4 GUI version.

I will now try with the same version on my defective hardware.

56

Hi rob75

When using just Tor you will be fine. Its when using both Tor and VPN that you have the problem. I was using those logs to show what was happening in openvpn.log was not matching up in the sdwdate.log. Its not easy to see unless you compare time stamps and activity line by line. Then you can get a picture as to what is going on.

1 Like
57

I cannot reproduce my original problem in version 14.0.0.9.6 (CLI) on the original (“defective”) hardware!