[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

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

Hi rob75

Just to recap:

1. OpenVPN and Tor connect when Whonix-Gateway first starts.
2. ~ 120 to 240 seconds later you see this in dmesg and at the same time the OpenVPN connection goes down.

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

3. You are able to reconnect the VPN but disconnection continues to happen at the same time interval.
4. This problem is remedied by disabling sdwdate


I wasn’t able to produce any of the same behavior until I saw this.

When I run sudo ifconfig I get interesting results.

https://pastebin.com/RXDJ0ynn

While I didn’t produce the exact behavior i.e. No VPN connected issue. This issue continued to be a problem on concurrent VM boots.This might be causing an problem with time sync and/or whonix_firewall.

To be clear, ifconfig shouldn’t cause an issue. But possible running before whonix_firewall is loaded is interfering somehow.

I’ll have to test more.

1 Like

Thanks for your patience and taking the time to help me.

Your summary is largely accurate.

1: Yes.

2: Yes.

3: Not really, after the pcnet32 issue, then it doesn’t reconnect, at all to my knowledge. However, if I do systemctl restart for both openvpn@openvpn and tor, a few times (back and forth), then things start working again.

4: Yes.

Ah, this happens regardless of me running ifconfig or not (between reboots and even between reinstalls of Whonix gateway).

I want to say thanks for all the help so far.

However, I still have this problem. Should I file a bug report?

Could someone else, perhaps, please verify that what I’m doing works on their system?

I cannot believe that I’m still missing some simple step, which is the cause of all my issues with sdwdate. If I was, and I keep making the same mistake over and over when reinstalling the Whonix gateway, I would say it makes sense to assume others also have made the same mistake as I did.

It is probably in the interest of the community to point out this crucial step (if this is indeed the problem) that I’m making in the documentation so that others can avoid the same problem.

I can imagine that many simply give up when they encounter the problem.

Hi rob75

Could you try unloading the Apparmor sdwdate profile and see if that helps. Apparmor profile unload.

List the apparmor profiles

ls /etc/apparmor.d/

You should see output similar to this:

abstractions    local                usr.bin.whonixcheck.dpkg-old
cache           system_tor           usr.lib.onion-grater
disable         tunables             usr.lib.sdwdate.url_to_unixtime
force-complain  usr.bin.whonixcheck  usr.sbin.haveged

Using the file above, this would unload the sdwdate profile.

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

Now try running VPN with sdwate enabled.

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

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

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

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.

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

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.

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

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

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

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.

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

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.

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?

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.

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

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

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]