Kicksecure Network Configuration

same situation here, it’s set to autostart and is ‘active’ but no world connection, installed -ws and -gw, the -ws has tor connectivity, KS does not.

is there anything else to fix KS to get connectivity ?

PS: am I correct that -ws display is fixed and can’t be changed to say 1600x900 or so ?


Thanks for your report. I figured it out. Kicksecure is shipping with a static IP set which is outside the range delegated for Default network. While would work for VBox Kicksecure - it makes no sense for KVM (

@Patrick Is it better to set another static IP for KS KVM? Or should we switch to dynamic assignment with a DHCP client installed here in this case?

1 Like

Not much thought went into this yet.

is originally based on

Kicksecure in VM would be better with static network configuration. More secure than DHCP. But a Kicksecure main goal is to be one day primarily useful on the host. VMs secondary. And to make networking work easily on the host we probably should enable DHCP by default, no way around that?

We could go for DHCP on the host by default and maybe some day static networking inside VMs if that’s worth going for.

Which DHCP client would be advisable?

sudo apt install dhcp-client

Package dhcp-client is a virtual package provided by:
isc-dhcp-client 4.4.1-2
dhcpcd5 7.1.0-2
dhcpcanon 0.8.5-2

1 Like

That actually opens a larger discussion. How should networking be setup on Kicksecure hosts anyhow? Using which tools? Any recommended / easy / modern / secure configuration?

CLI / GUI interoperability? Server (headless) and desktop (GUI) support? I’ve seen default installations in which the graphical XFCE session had networking (WiFi) but a virtual console did not have networking. That is bad because when users want to debug, not even their networking is working in virtual console, they never tried that before and can’t even install the required packages to make it work. Networking that works only in GUI but not in CLI or only in either is kinda bad.

Network manager? systemd-networkd? netplan? Others?

1 Like

Unfortunately not because there’s no way you can anticipate the internal IP range of users’ networks beforehand. Also it will vary across networks as they move around.


dhcpd is more updated with standards and lightweight compared to dhcp-client.

However dhcpcanon is best because it is written in Python and is focused on disclosing the least amount of info about the client PC to get the job done for user anonymity. Therefore preferred.

It must work out of the box or else we lose users. This is a minimal expectation of users trying out distros these days. Network Manager is easy to understand and familiar with users of any OS for inputting wifi info.

For cmdline wpa supplicant is the defacto standard on desktop and mobile. Network Manaager is the GUI front-end here.

Network Manager is the way to go. I wouldn’t rely on anything systemd because of feature creep and possibility of having privacy problematic features added in the future or increased attack surface that we turn off. Netplan is Ubuntu and we should avoid Ubuntu anything because their projects usually end up half finished and they hold the copyright/CLA.

1 Like

That sounds good.

Help welcome!

OK what package do I add dhcpcanon to? Will it override the static IP? It’s a priority for me to get it working because Kicksecure KVM is dead currently.

Offtopic: Also can we change the KS wallpaper and possibly theme to be different than Whonix? I found myself confused which environment I am in when working with Whonix simultaneously.

1 Like

Not easy.

Patches welcome.

1 Like

I thought it’s gone since we stripped dhcp out from Whonix? A DHCP client will be a must for KS baremetal whenever that comes around.

The easier ways to deal with it - My choices are either to

  • add a differently named version of Whonix-External network file to be included and imported wih KS in an extra step.
  • No longer support KVM KS as a broken product is worse than none at all.

This is the command to change it:

However a manual trial run of picking a solid background from the desktop settings menu doesn;t have any effect.

  • add a differently named version of Whonix-External network file to be included and imported wih KS in an extra step.

Yes. Please add a KS network file and manual instructions how to use
DHCP. That is the first step before this can be properly packaged. Hard
to package stuff without knowing what should be done and how.

  • No longer support KVM KS as a broken product is worse than none at all.

Yes. This will take time unless someone is working on it.

This is the command to change it:
However a manual trial run of picking a solid background from the desktop settings menu doesn;t have any effect.

It needs to be translated into a config file pull request.

1 Like

Experimented with a dedicated network for KS. It conflicts with Whonix-External because it uses the same range which it needs to be compatible with the static IP.

Couldn’t use any / a different IP range since it’s going to be DHCP anyhow?

No, because it was supposed to be a solution for KS as is. A different IP range requires a different static IP. In that case my problem would be solved - I can set it to some address in Default’s network.

Installing dhcpcanon pulls in a shit ton of deps takes half a gig of space. Didn’t try --install-no-deps. dhcpd doesn’t need anything.

Anyway no DHCP client works because static IP overrides them.

1 Like

Not sure I got this right, but why not first forget about any history, any workaround and implement it the proper way? DHCP + default network?

Should work.
Just like any generic Debian if a) we mask out the Whonix network settings package and b) install dhcp only for KS builds. Might require new flavor specific packages and/pr changes to the build flag possibly?

1 Like

Wasn’t ever and isn’t installed in KS already.

Easy. Going to be a dependency of already existing kicksecure-network-conf package.

It’s already implemented. Once it’s figured out the packaging / build is easy.

What’s missing:

  • install which (DHCP) package(s) with --no-install-recommends?
  • replace all contents of /etc/network/interfaces.d/30_kicksecure with
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp


  • Or is no /etc/network/interfaces.d/ config drop-in file at all required? Even better.
  • DHCP vs DNS?
  • Bonus:
    • Go extra mile of not only DHCP but also network manager?
      • DHCP pacakge going to be compatible with network manager?

During testing probably easiest (after installation of a DHCP package) to undo all changes by kicksecure-network-conf (which also sets up /etc/resolv.conf for DNSCrypt) to make non-DNSCrypt, standard DNS work.

sudo dpkg --force-all --purge kicksecure-network-conf
1 Like

Great. dhcpcanon clocks in at a more manageable 24MiB of space

Indeed that’s what I needed to make it work

It is needed AFAICT as it’s the only way to tell Linux how to interact with interfaces it sees.

I installed network-manager but it has no GUI icon anywhere I can interact with. Neither in the taskbar nor in the settings or whisker menu.

Removing this package absolutely breaks networking and I had to revert the snapshot to try again.

offtopic: udhcpd is onl 50KiB but has a long history of bad security bugs. Meanwhile dhcpcanon has no mentions on cvedetails.


Probably CLI only. GUI packages might be these ones:

Breaks even ping to IP (example: ping (google))?

Well, it would break /etc/resolv.conf.

Can you see what other files in https://github.com/Whonix/kicksecure-network-conf could result in such behavior if removed?

Another option would be “manual uninstallation”. I.e. undoing the effects (deleting files, changing config back) of any file shipped by package kicksecure-network-conf.

Uninstallation probably results in undo of kicksecure-network-conf.triggers and kicksecure-network-conf.links.

To re-disable predictable network interface (after kicksecure-network-conf removal) :

sudo ln -s /dev/null /etc/systemd/network/99-default.link
sudo update-initramfs -u

nm-tray and network-manager-gnome work after a reboot. We should only use one however. The gnome front-end is more aesthetic and easier to interact with.

Can no longer reproduce this and networking seems to work without the package installed.

1 Like

If you are going with Network manager, these are usually the relevant networking files for config and such: the /etc/NetworkManager directory which has /NetworkManager.conf. To make NM be the default networking, simply add [ifupdown] and under it put managed=false (in the Networkmanager.conf). in the “system-connections” folder under the same directory is where you define your default interface connection, applicable wifi, dns servers, ipv4/ipv6 etc. usually the file name is your access point/router name or whatever.
There is a built in conf.d folder for customizations and things.
If using dhcp, there is usually a dhclient script in /bin or /sbin. You can confine this with apparmor easily. There is a isc-dhcp package for obtaining addresses automatically.
Also, don’t forget nm comes with a useful tui interface. get to it by going to cli and type: nmtui . You can add connections, edit them, etc.
Edit: oh yeah, I forgot about dns.
You can use systemd-resolved and mask the systemd-networkd service. Or, nm can handle dns totally on its own. In that case you would also mask systemd-networkd, and use resolv.conf. Rather, your resolv.conf would say “generated by network manager” and the /run/systemd/resolve/resolv.conf no longer applies.
Is one better?
I have used both methods for dns. They both work reliably. Some like to only have one system manage networking, in that case mask systemd-resolved. Others do not care and leave systemd-resolved active. It makes no difference. Only thing is if you use systemd-resolved, you cannot edit resolv.conf directly like you can with pure network manager or say Wicd for example. In either case, you do not need a .network file in systemd either. But do not have both active at the same time otherwise strange things happen

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