ProxyVM + AppVM Development

Qubes-Whonix
101

make gateway -- would read form a configuration file for options make workstation -- same ---^
Or just add the command line options you want? Either way. Config files are supported, cmd switches and even env vars. Go for it.

make get-sources      -- download/update all sources (if you git rid of submodules) get+verify

I’d be curious to look at the implementation.
Git submodules are a mess. Still a TODO.
(Whonix Forum)
If you have any suggestions…

make clean-all        -- remove any downloaded sources and built packages

Related to above.

make sign-all         -- sign all packages

https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/packaging-helper-script#L496

make clean-deb        -- remove any built packages

Probably would just need a shortcut to:
https://github.com/Whonix/Whonix/blob/master/help-steps/cleanup-files

make check            -- check for any uncommited changes and unsigned tags

For the former I just use “git status”. But if a make shortcut helps you, feel free to add such a feature. Usually there are no unsigned git tags. Never forgot that. But feel free to also provide that feature.

make check-depend     -- check for build dependencies ($(DEPENDENCIES))

check-depend for Whonix/Whonix or individual packages? For the former:
build-steps.d/1100_prepare-build-machine does that and more. Well, not check, but also install those.
But if you think a make check-depend would help?

make diff             -- show diffs for any uncommitted changes

Just run “git diff”? But if the shortcut helps you, go for it.

make grep RE=regexp   -- grep for regexp in all components

If the shortcut helps you, go for it.

make push             -- do git push for all repos, including tags

I have that somewhat, but implemented in a rather personal way:
https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/packaging-helper-script#L364
(I comment in the function I want to use, then run that script.)
Feel free to implement that.

make show-vtags       -- list components version tags (only when HEAD have such) and branches
make show-authors     -- list authors of Qubes code based on commit log of each component
make prepare-merge    -- fetch the sources from git, but only show new commits instead of merging
make show-unmerged    -- list fetched but unmerged commits (see make prepare-merge)
make do-merge         -- merge fetched commits

Should like just git shortcuts. I personally don’t need it, but if you find that useful, go for it.

102

Sure, I will take a look at implementing some type of Makefile. I hate them too, but they are useful. Mostly they will just call whatever existing scripts you already have anyway except for the newer features I plan to add.

[HR]

I have figured out how to update the template by just adding another 50_uwt_default rule with a conditional within it to detect if its a template and if it is disable uwt for apt-get and then apt-get will use a proxy.

I have placed an update proxy (tinyproxy) on the gateway, port 8082 internal interface only using these iptable rules (they are defined by Qubes). Basically the rules allow a standard proxy IP address of 10.137.255.254 on all AppVM’s and since the template has no network access the proxy IP is intercepted by the network vm, in this case Whonix gateway).

iptables -t nat -N PR-QBS-SERVICES

<script called with $1=start or "">
RULE_FILTER="INPUT -i vif+ -p tcp --dport 8082 -j ACCEPT"
RULE_NAT="PR-QBS-SERVICES -i vif+ -d 10.137.255.254 -p tcp --dport 8082 -j REDIRECT"

if [ "$1" == "start" ]; then
cat <<__EOF__ | iptables-restore -n
*filter
-I $RULE_FILTER
COMMIT
*nat
-I $RULE_NAT
COMMIT
__EOF__
else
    # Remove rules
    iptables -D $RULE_FILTER
    iptables -t nat -D $RULE_NAT
    exit 0
fi

So the rule works in wheezy without firewall, but I am having problems sorting though the Whonix firewall code to get the firewall not to drop the connection. What is happening is the template VM connects and immediately get disconnected.

I think this error may have something to do with it

Nov  2 18:59:56 host Tor[4388]: Rejecting request for anonymous connection to private address [scrubbed] on a TransPort or NATDPort.  Possible loop in your NAT rules? [4 similar message(s) suppressed in last 300 seconds]

So I am hoping somebody will be able to help me figure out how to get this working; its the second last step before its all ready to be merged in Qubes code.

103

[quote=“nrgaway, post:102, topic:512”]Sure, I will take a look at implementing some type of Makefile. I hate them too, but they are useful. Mostly they will just call whatever existing scripts you already have anyway except for the newer features I plan to add.

[HR]

I have figured out how to update the template by just adding another 50_uwt_default rule with a conditional within it to detect if its a template and if it is disable uwt for apt-get and then apt-get will use a proxy.[/quote]
Great!

104
So the rule works in wheezy without firewall, but I am having problems sorting though the Whonix firewall code to get the firewall not to drop the connection. What is happening is the template VM connects and immediately get disconnected.
Whonix's firewall /usr/bin/whonix_firewall in a nutshell: 1) goes up before the network goes up 2) if it fails to load (non-zero exit codes), network does not get up 3) first of all, it sets all iptabels policies to drop as a safety net and because a traffic white listing approach is best 4) having that said: next is to remove any iptables rules so we can cleanly load eventually changed rules (we're still protected by iptables default policy drop) 5) then it loads all firewall rules useful for Whonix

After 4) would be a good time to conditionally use your alternative iptables rules.

(Going to link to a specific git commit. Line numbers may change in later revisions.) [Not addressing you, you probably know that, but I try to keep my answers generic, so someone who does not know that and reads it much alter cannot be confused.]

Essentially after the “Flush old rules.” (line 218 https://github.com/Whonix/whonix-gw-firewall/blob/827ea83bed41256bda33ab69c173df2878966a30/usr/bin/whonix_firewall#L218) or eventually after the “IPv4 DROP INVALID INCOMING PACKAGES” (line 240 https://github.com/Whonix/whonix-gw-firewall/blob/827ea83bed41256bda33ab69c173df2878966a30/usr/bin/whonix_firewall#L240) would be a good place for experimentally adding your firewall rules.

Ideally your iptables firewall rules are already functioning under a wheezy iptables drop all by default situation.

iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP

(You could also undo this, but I guess it be much better for deeper understanding to leave that as is.)

If that works, we can perhaps add some kind of hook mechanism so you don’t have to patch it.

What else could go wrong… You still have no functional system DNS and I hope you won’t need it. A solution can be found either way.

I think this error may have something to do with it [code] Nov 2 18:59:56 host Tor[4388]: Rejecting request for anonymous connection to private address [scrubbed] on a TransPort or NATDPort. Possible loop in your NAT rules? [4 similar message(s) suppressed in last 300 seconds] [/code]
Yes. (Not exactly it, but a related message is documented here: https://www.whonix.org/wiki/Arm#Arm_FAQ)
105

Build issues:

[hr]

First confirming that the “wheezy” branch should now be used to build Whonix, and NOT the “whonix” branch?

According to:

Using to build:

git clone https://github.com/nrgaway/qubes-builder
cd ./qubes-builder
git fetch
git checkout wheezy
./README.whonix

[hr]

Error: /home/user/qubes-builder/keyrings/git directory does not exist

# Whonix Keyring # XXX: Check where this is being stored... Keyrings make sense DIR="$(readlink -m .)"; \ KEYRING_DIR_GIT="$DIR/keyrings/git"; \ export GNUPGHOME="$(readlink -m $KEYRING_DIR_GIT)"; \ echo '916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA:6:' | gpg --import-ownertrust; \ gpg --import keys_debian/whonix-developer-patrick.asc; \ gpg --list-keys; \ touch "$GNUPGHOME/pubring.gpg"; gpg: keyblock resource `/home/user/qubes-builder/keyrings/git/secring.gpg': file open error gpg: keyblock resource `/home/user/qubes-builder/keyrings/git/pubring.gpg': file open error gpg: fatal: /home/user/qubes-builder/keyrings/git: directory does not exist! secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 gpg: keyblock resource `/home/user/qubes-builder/keyrings/git/secring.gpg': file open error gpg: keyblock resource `/home/user/qubes-builder/keyrings/git/pubring.gpg': file open error gpg: no writable keyring found: eof gpg: error reading `keys_debian/whonix-developer-patrick.asc': general error gpg: import from `keys_debian/whonix-developer-patrick.asc' failed: general error gpg: Total number processed: 0 gpg: keyblock resource `/home/user/qubes-builder/keyrings/git/pubring.gpg': file open error gpg: fatal: /home/user/qubes-builder/keyrings/git: directory does not exist! secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 touch: cannot touch '/home/user/qubes-builder/keyrings/git/pubring.gpg': No such file or directory make: *** [get-sources] Error 1 [user@vm qubes-builder]$

Workaround used to bypass this fatal error of creating empty “./keyrings” and “./keyrings/git” directories before running the build script.

[hr]

Error: One of signed tag cannot be verified
Error: gpg: Can’t check signature: public key not found
Error: error: could not verify the tag ‘v4.1.6.1-17’

+ echo '--> Verifying tags...' --> Verifying tags... + /home/user/qubes-builder/verify-git-tag.sh qubes-src/vmm-xen HEAD ---> One of signed tag cannot be verified: object d91422d53fce81e273ee21a189b4cccb88bec667 type commit tag v4.1.6.1-17 tagger Marek Marczykowski-G��recki 1414194831 +0200

version 4.1.6.1-17
gpg: WARNING: unsafe permissions on homedir `/home/user/qubes-builder/keyrings/git’
gpg: Signature made Fri Oct 24 23:53:51 2014 UTC using RSA key ID 42CFA724
gpg: Can’t check signature: public key not found
error: could not verify the tag ‘v4.1.6.1-17’
No valid signed tag found!

  • exit 1
    make: *** [get-sources] Error 1
    [user@vm qubes-builder]$

Experienced each time on multiple build attempts. Haven’t resolved yet.

[hr]

106

[quote=“WhonixQubes, post:105, topic:512”]Build issues:

[hr]

First confirming that the “wheezy” branch should now be used to build Whonix, and NOT the “whonix” branch?

According to:

Using to build:

git clone https://github.com/nrgaway/qubes-builder
cd ./qubes-builder
git fetch
git checkout wheezy
./README.whonix

[hr]

Error: /home/user/qubes-builder/keyrings/git directory does not exist

Workaround used to bypass this fatal error of creating empty “./keyrings” and “./keyrings/git” directories before running the build script.

[hr]

Error: One of signed tag cannot be verified
Error: gpg: Can’t check signature: public key not found
Error: error: could not verify the tag ‘v4.1.6.1-17’

Experienced each time on multiple build attempts. Haven’t resolved yet.

[hr][/quote]

Keys are not being updated…

In the ./qubes-builder directory where you are running the README.whonix script, type the following to update to the newest version of qubes-builder (or just delete the directory and re-clone it):

git pull origin wheezy

I added some changes that will add the developers keys automatically before Whonix ones get added and tested it on a new VM here. I am testing the complete script now from start to end as well with the new build environment.

107

[quote=“Patrick, post:104, topic:512”](Going to link to a specific git commit. Line numbers may change in later revisions.) [Not addressing you, you probably know that, but I try to keep my answers generic, so someone who does not know that and reads it much alter cannot be confused.]

Essentially after the “Flush old rules.” (line 218 https://github.com/Whonix/whonix-gw-firewall/blob/827ea83bed41256bda33ab69c173df2878966a30/usr/bin/whonix_firewall#L218) or eventually after the “IPv4 DROP INVALID INCOMING PACKAGES” (line 240 https://github.com/Whonix/whonix-gw-firewall/blob/827ea83bed41256bda33ab69c173df2878966a30/usr/bin/whonix_firewall#L240) would be a good place for experimentally adding your firewall rules.

Ideally your iptables firewall rules are already functioning under a wheezy iptables drop all by default situation.

iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP

(You could also undo this, but I guess it be much better for deeper understanding to leave that as is.)

If that works, we can perhaps add some kind of hook mechanism so you don’t have to patch it.

What else could go wrong… You still have no functional system DNS and I hope you won’t need it. A solution can be found either way.[/quote]

Yup, you were right, that was the perfect spot to inject the tinyproxy rules!

I was able to get the iptables rules working properly so now the workstation can talk to the gateway proxy server without an issue. Now I need to figure out how get get the proxy server on the gateway to be able to connect through Tor to outside world to the Debian servers. What firewall rule would be required?

The tinyproxy software listens on the internal interface port 8082 and is run by the tinyproxy user and group. I initially created a uwt wrapper for it, but then the workstation could not see it anymore :slight_smile:

Here is the firewall code I am using to inject the rules into ‘whonix_firewall’:

       # Inject custom firewall rules into whonix_firewall
        sed -i -f - /usr/bin/whonix_firewall <<-EOF
                /^## IPv4 DROP INVALID INCOMING PACKAGES/,/######################################/c \\
                ## IPv4 DROP INVALID INCOMING PACKAGES \\
                ## \\
                ## --- THE FOLLOWING WS INJECTED --- \\
                ##     Qubes Tiny Proxy Updater \\
                iptables -t nat -N PR-QBS-SERVICES \\
                iptables -A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT \\
                iptables -A OUTPUT -o vif+ -p tcp -m tcp --sport 8082 -j ACCEPT \\
                iptables -t nat -A PREROUTING -j PR-QBS-SERVICES \\
                iptables -t nat -A PR-QBS-SERVICES -d 10.137.255.254/32 -i vif+ -p tcp -m tcp --dport 8082 -j REDIRECT \\
                \\
                # Route any traffic FROM netvm TO netvm BACK-TO localhost \\
                # Allows localhost access to tor network \\ 
                iptables -t nat -A OUTPUT -s ${ip} -d ${ip} -j DNAT --to-destination 127.0.0.1 \\
                ###################################### 
                EOF

PS. In ‘/etc/uwt.d/30_uwt_default’, there is a typo:

uwtport["/usr/bin/apt-get"]="9105"

Should be (as defined in ‘whonix_firewall’ and ‘apt-get.anondist’:

uwtport["/usr/bin/apt-get"]="9104"
108

Fixed typo, thanks!

[hr]

Where to you get the {ip} variable from?

109

I don’t know yet, what you need tinyproxy for? Is it’s purpose to do some kind of caching? For saving apt traffic? For the latter a proxy that understands apt such as apt-cacher-ng would be more suitable? apt-cacher-ng can be socksified. (So it can go through Tor. Did that once, dunno anymore how, but its in git history, I could figure out again if required.)

110

Because with a uwt wrapper all connections are forced though torsocks thereby through a Tor SocksPort and therefore you cannot access the local network anymore. (Unless you figure out to switch some settings in torsocks or other trickery or so.)

111

Maybe no additional iptables rules are required. Depends. Because on Whonix-Gateway you can do something like this.

It will work, because that custom SocksPort has already been prepared and connections to those are allowed.

Now since using uwt for servers that shall accept connections from local network also… You’d need to figure out if the proxy you want to use supports a setting for using a SocksPort for it’s outgoing connections.

112

The proxy is not for caching or saving traffic. Its sole purpose is to filter and limit traffic to only update repos for apt-get and yum and prevent any other type of traffic from proceeding though.

[quote=“Marek”]This HTTP proxy is to block access to everything but updates - to not let the
user to use the template to anything else but software installation/update.

Details about the reasoning are here:
https://wiki.qubes-os.org/ticket/568[/quote]

The base templates in Qubes do not have access to the network to keep them isolated since many AppVM’s used on top of the base template. For instance there is a Fedora-20-x86 base template and one would use it as a base to create an Email, Web, Work, Home, etc AppVM. The AppVM use a copy of the base template and when the AppVM is shutdown any data that was written to the root is lost. This helps keep the AppVM’s clean from malicious software and keeps them light weight.

Since the base templates have no network access by default, the developers created a proxy that allows very restricted access to the base templates for updating only. Here are the filter rules that are in effect to prevent the template from being able to access anything else but repositories:

/repodata/[A-Za-z0-9-]*\(primary\|filelists\|comps\(-[a-z0-9]*\)\?\|other\|prestodelta\|updateinfo\|pkgtags\)\.\(sqlite\|xml\)\(\.bz2\|\.gz\)\?$
/repodata/repomd\.xml$
\.rpm$
\.drpm$
^mirrors\.fedoraproject\.org:443$
^http://mirrors\..*/mirrorlist\?
\.deb$
/dists/[a-z-]*/\(InRelease\|Release\|Release.gpg\)$
/dists/[a-z-]*/.*/\(Packages\|Sources\|Release\)\(\|\.gz\|\.bz2\|\.xz\|\.lzma\)$
/dists/[a-z-]*/.*/\(Contents\|Translation\)-.*\(\|\.gz\|\.xz\|\.bz2\|\.lzma\)$
/dists/[a-z-]*/.*/\(Contents-.*\|Translation-.*\|Packages\)\.diff/\(Index\|[0-9.-]*\)\(\|\.gz\|\.xz\|\.bz2\|\.lzma\)$

So

113

[quote=“Patrick, post:108, topic:512”]Fixed typo, thanks!

[hr]

Where to you get the {ip} variable from?[/quote]

I wrote the startup script that brings up the internal interface since it is not brought up by network manager or using the ‘/etc/network/interfaces’ configuration file. Right before the iptables are injected I created the internal interface with the address of {ip}, then I do a search and replace on ips a bit of housekeeping then afterwards call ‘whonix_firewall’

114

[quote=“nrgaway, post:106, topic:512”]Keys are not being updated…

In the ./qubes-builder directory where you are running the README.whonix script, type the following to update to the newest version of qubes-builder (or just delete the directory and re-clone it):

git pull origin wheezy

I added some changes that will add the developers keys automatically before Whonix ones get added and tested it on a new VM here. I am testing the complete script now from start to end as well with the new build environment.[/quote]

Still encountering a fatal error with a failed signed tag verification.

Error Output:

+ echo '--> Verifying tags...' --> Verifying tags... + /home/user/qubes-builder/verify-git-tag.sh qubes-src/vmm-xen FETCH_HEAD ---> One of signed tag cannot be verified: object d91422d53fce81e273ee21a189b4cccb88bec667 type commit tag v4.1.6.1-17 tagger Marek Marczykowski-G��recki 1414194831 +0200

version 4.1.6.1-17
gpg: WARNING: unsafe permissions on homedir `/home/user/qubes-builder/keyrings/git’
gpg: Signature made Fri Oct 24 23:53:51 2014 UTC using RSA key ID 42CFA724
gpg: Good signature from “Marek Marczykowski-G�recki (Qubes OS signing key) <marmarek@>”
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 0064 428F 4554 51B3 EBE7 8A7F 0639 38BA 42CF A724
No valid signed tag found!

  • exit 1
    make: *** [get-sources] Error 1
    [user@vm qubes-builder]$

Here’s the ordered build steps I’m using:

git clone https://github.com/nrgaway/qubes-builder
cd ./qubes-builder
git fetch
git pull origin wheezy
mkdir ./keyrings
mkdir ./keyrings/git
git checkout wheezy
./README.whonix

A signed tag could not be verified and exited with a fatal error:

---> One of signed tag cannot be verified: object d91422d53fce81e273ee21a189b4cccb88bec667
No valid signed tag found! + exit 1 make: *** [get-sources] Error 1

Also:

The “mkdir ./keyrings” and “mkdir ./keyrings/git” commands can surely be handled by the build script. In fact, gpg also complains about “unsafe permissions”, so maybe the permissions could be better tweaked as well. But automating directory creation is the basic need.

gpg: WARNING: unsafe permissions on homedir `/home/user/qubes-builder/keyrings/git'
115

[quote=“WhonixQubes, post:114, topic:512”]Here’s the ordered build steps I’m using:

git clone https://github.com/nrgaway/qubes-builder cd ./qubes-builder git fetch git pull origin wheezy mkdir ./keyrings mkdir ./keyrings/git git checkout wheezy ./README.whonix [/quote]

Close, the pull is in the wrong order.

I just re-ran the following steps and confirm they worked for me:

[ul][li]First I suggest you start completely over with a brand new AppVM. I named mine development-qubes. Base it on the ‘Fedora-20-x64’ template.[/li]
[li]Start AppVM from Qubes Manager[/li]
[li]Start a Dom0 Konsole session[/li]
[li]Increase disk size to 10GB per VM you going to build, so in Dom0 Konsole type ‘[font=courier]qvm-grow-private devleopment-qubes 25GB[/font]’[/li]
[li]Start a Terminal session for new AppVM (development-qubes) and enter the following:[/li][/ul]

git clone https://github.com/nrgaway/qubes-builder
cd qubes-builder/
git fetch
git checkout whonix
./README.whonix
  - Answer y <enter> to yum update question

Do not create the keyrings directory, it will be created for you.

Those steps will build both the gateway and workstation. You can edit ‘[font=courier]examples/whonix.conf[/font]’ (which will be linked as ‘[font=courier]builder.conf[/font]’ after running script) to change build options to build wheezy or jessie or add gnome to those as well (just un-comment out lines you want to build).

There should be no issues listed previously in this thread for any distro except Whonix can not yet update from template and you SHOULD run both the gateway and workstation as standalone until the update situation is resolved.

So, once the templates are built, the last line explains how to get them to Dom0. I actually save that line and created a script in Dom0 I use anytime I need to grab templates I built. So you can edit a file named ‘get-templates.sh’ on dom0 and include the following"

#!/bin/bash

qvm-run --pass-io development-qubes 'cat /home/user/qubes-builder/qubes-src/linux-template-builder/rpm/install-templates.sh' > install-templates.sh
chmod a+x install-templates.sh

Then make the file executable and run it to grab and install the templates on dom0

cd ~
mkdir bin
cd bin
vi get-templates.sh # Add text above
chattr a+x get-templates.sh
./get-templates.sh
cd /tmp
/home/user/bin/get-templates.sh # Grabs install script
./install-template.sh # Will download template rpm; remove old one (if installed); install new ones

In order to get the text I listed to dom0, here is a trick I figured out.

- Highlight text you want to copy.
- Right click with mouse and select 'copy'
- Press <SHIFT>+<CTRL>+<C>
- in dom0 Konsole type 'cat /run/qubes/qubes-clipboard.bin'
- the text you just copied will be displayed in dom0 terminal so now you can highlight it from dom0 terminal and paste it where ever

[HR]

Qubes manager options to select for gateway:

[ul][li]Name: whonix-gateway[/li]
[li]Template: whonix-gateway-experimental[/li]
[li]Type: Proxy VM[/li]
[li]NetVM: firewallvm[/li]
[li]Check Standalone[/li][/ul]

[ul][li]Name: whonix-workstation[/li]
[li]Template: whonix-workstation-experimental[/li]
[li]Type: AppVM[/li]
[li]NetVM: whonix-gateway[/li]
[li]Check Standalone[/li][/ul]

[HR]

Start the gateway from Qubes Manager. The setup screen should come up and ask you about repo and starting Tor. Note that the first two screens where it displays disclaimer that the buttons are not visible, so just press [font=courier][/font], then [font=courier][/font] again for second screen. If you happen to not press [font=courier][/font], or somehow focus gets messed up, VM will power off so you will need to try again.

When you are finished setup, if you get an error message from time proxy or that tor can not do a check since bootstrap not complete, try running ‘[font=courier]whonixcheck[/font]’ again, and it should succeed.

Do same for Workstation. Or you can use a regular AppVM and just select ‘[font=courier]whonix-gateway[/font]’ as its netvm.

Note the first run dialog says the password is ‘[font=courier]changeme[/font]’ when there is actually no password as per Qubes defaults.

[HR]

Some issues with Whonix applications:

[ul][li]Some don’t run maybe?[/li]
[li]Stuff like tor browser may need to be started from terminal at this point[/li]
[li]???[/li][/ul]

[HR]

So now you have your whonix-gateway and whonix-workstation installed remember it is experimental at this point.

[HR]

Test and keep a log of issues that need to be addressed and things that work compared to HVM version.

Do leak tests and report results. This is important.

Don’t use it for anything important yet until leak tests, etc are confirmed.

Document as must as possible, including steps here since I will rely on you for that since I still busy with completing updating template and need to move a ton of whonix code around so it saves all user configurable files in one directory structure under ‘[font=courier]/srv/whonix[/font]’ and ‘[font=courier]/srv/whonix/.whonix[/font]’ (for anything whonix writes like setup.done). I find it more useful to have any configuration related options in one spot to make it easier to find and to get templates so they don’t need to be standalone, this will make it easier to link (bind) from the ‘[font=courier]/rw[/font]’ directory since AppVMs are essentially read-only (any data that gets written to root partition gets destroyed after VM is shut off).

Please start a new thread for issues. Maybe a few threads. One for gateway, One for workstation and maybe one for building (like this post can be copied to that one). I want to keep this thread to interact with progress and issues I am facing.

EDIT: Changed branch to use back to whonix. I will update the whonix branch with stable commits.

116

Thanks for making this nice verbose update. I will try again with the “whonix” git branch.

I see the new dedicated build thread you made and will segment out those issues here:

[b]Whonix Forum

[hr]

Regarding this Tor Browser launching issue you’re having:

[quote=“nrgaway, post:115, topic:512”]Some issues with Whonix applications:

[ul][li]Stuff like tor browser may need to be started from terminal at this point[/li][/ul][/quote]

Just a blind stab at it, but just wanted to make sure you’re aware that pre-9.3 Whonix was having this problem of not successfully launching the Tor Browser, except from the command line. Was fixed just recently in Whonix 9.3.

Not sure if that’s the issue here, but wanted to mention it in case you hadn’t seen it yet and/or are using an earlier version.

Could have to do with same or related code in the “tb-starter” package…

117

I should have done it before but was too busy with the templates. And I am also working on the wheezy and debian templates and added many features to them.

Regarding this Tor Browser launching issue you're having:

Just a blind stab at it, but just wanted to make sure you’re aware that pre-9.3 Whonix was having this problem of not successfully launching the Tor Browser, except from the command line. Was fixed just recently in Whonix 9.3.

Not sure if that’s the issue here, but wanted to mention it in case you hadn’t seen it yet and/or are using an earlier version.

Could have to do with same or related code in the “tb-starter” package…

GitHub - Kicksecure/tb-starter: Tor Browser Starter. Open Link Confirmation; Qubes integration; Command line --new-tab, --new-window; start menu entry; This package is produced independently of, and carries no guarantee from, The Tor Project.

Good to know. I am still using the 9.2 version. I don’t want to update to 9.3 since everything is working right now and I want to wait until most changes get merged upstream as well as being able to take advantage of the new GUI modules being written for repo maintenance and setup.

118

[quote=“Patrick, post:111, topic:512”]Maybe no additional iptables rules are required. Depends. Because on Whonix-Gateway you can do something like this.

It will work, because that custom SocksPort has already been prepared and connections to those are allowed.

Now since using uwt for servers that shall accept connections from local network also… You’d need to figure out if the proxy you want to use supports a setting for using a SocksPort for it’s outgoing connections.[/quote]

I have the updating working via Tor for tinyproxy now. I injected these rules to [font=courier]whonix_firewall[/font]:

## --- THE FOLLOWING WS INJECTED ---
##     Qubes Tiny Proxy Updater
iptables -t nat -N PR-QBS-SERVICES
iptables -A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT
iptables -A OUTPUT -o vif+ -p tcp -m tcp --sport 8082 -j ACCEPT
iptables -t nat -A PREROUTING -j PR-QBS-SERVICES
iptables -t nat -A PR-QBS-SERVICES -d 10.137.255.254/32 -i vif+ -p tcp -m tcp --dport 8082 -j REDIRECT
iptables -t nat -A OUTPUT -p udp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to ${ip}:53
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to ${ip}:9040

So, last step is to link files whonix writes to to (like [font=courier]/root/.whonix/first_run_initializer.done[/font]) [font=courier]/rw[/font] so they will persist on reboot

119

This is unfortunate, but it will not be needed anymore in more recent versions of whonix-initializer.
(Said this here Whonix Forum just for the record in case someone missed that.)
([Probably] fixed in whonix-inizializer 0.9-1 and above as well as 10.0.0.1.8-developers-only and above.)

120

Using this as general Qubes-Whonix development thread. The following is supposed as notification. It didn’t fit elsewhere and wasn’t worth a new forum thread.