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

[IMPLEMENTED] Feature request/suggestion: GW network settings

Development
#1

Hi,

with Whonix 8 out the door, I have a feature request/suggestion for Whonix 9. That is: An easy way to change the GW network settings, i.e. the GW IP address. To my knowledge this isn’t possible at the moment. Is it? At least I come across more and more configuration files at both the GW and the Workstation that has 192.168.0.10 hardcoded into it.

Unfortunately, I currently have no overview about all configuration files involved here. I’m thinking about some shell script that one may run - on demand - on both GW and Workstation to alter the GW network settings, i.e. to somehow sed/awk affected (hardcoded) files. At first glance I thought about a build script integration but an OS-integrated script seems to be better here (opinions?) as it’d also allows to alter the download versions of both GW and Workstation.

What do you think? Also, if that’s too tricky (for someone but Patrick who knows every single configuration file in Whonix), what about changing it to GW 172.16.0.10 as of Whonix 9+, Workstation 172.16.0.11 or something even more obscure like 172.16.23.10, respectively 172.16.23.11 by default? You get the idea. From my very own perspective 192.168.0.10, respectively 192.168.0.11 isn’t the most clever choice here considering it’s common use in SOHO routers.

Thanks!

#2

To clarify:
You want to be able to run the gateway in physical isolation mode (on it’s own hardware). The gateway is connected to your home router with one network adapter and the workstation via the other adapter. You’re worried that the gateway will be assigned 192.168.0.10 by the adapter connected to the router, thus causing both gateway adapters to be 192.168.0.10; Correct?

#3

Yes! In my very specific case, I’m using physical isolation. Also, I know how to deal with (changing the upstream network if it interferes). I’m just suggesting that something like 172.16.23.10 would be a wiser choice.

  1. desire to reconfigure (currently difficult) by both newbies and advanced users would be very unlikely
  2. newbies may easily hit this issue (every second/third SOHO router uses 192.168.0.0/24)

I haven’t thought about the situation without physical isolation yet, but spontaneously I would think that an upstream 192.168.0.0/24 network (which is highly likely) would cause troubles as well.

Also to consider here: A “moving/nomadic Whonix” (so to speak), i.e. a Whonix that’s used with distinct upstream connections all the time. 172.16.23.10 would most likely never lead to issues here, while 192.168.0.10 is highly likely to cause troubles. Just suggesting.

#4

A script to change gateway IP, well… Looks like some work. And the issue is, at some point files names may change or new files including this IP address might be introduced. Making the script outdated. So one would have to keep this constantly in mind. Does anyone really need to change them so often?

Changing gateway IP should be simple. You can find them all by doing:

cd Whonix grep -r 192.168.0.10 *
There is no variables x=192 y=168 and $x$y thing. It’s always simple 192.168.0.10.

You can mass change and replace them in Whonix’s source code using some mass and replace editor of your choice (jedit or so).

This change would cause quite some confusion in new version. Used in the wiki in a lot places:
https://www.whonix.org/w/index.php?search=192.168.0.10&fulltext=1

Also Whonix-Workstation IP (192.168.0.11) would have to be changed. Please keep https://www.whonix.org/wiki/Multiple_Whonix-Workstations in mind. (One may want to create 20 VMs or something like that.)

Can you think some more please about which IP is least likely to cause issues? And then create a VM test build (or change existing VM and reboot) with this change and see if everything (hidden services, torchat, leaktest) is working please?

#5
A script to change gateway IP, well... Looks like some work. And the issue is, at some point files names may change or new files including this IP address might be introduced. Making the script outdated. So one would have to keep this constantly in mind. Does anyone really need to change them so often?
I see! Forget about the script solution then ;)
This change would cause quite some confusion in new version. Used in the wiki in a lot places: https://www.whonix.org/w/index.php?search=192.168.0.10&fulltext=1
I understand that. Also, this is just a suggestion. Still (I was actually wondering why nobody thought about this), from my very own perspective using a 192.168.0.0/24 network for Whonix in the first place (when initially developing it) was a very bad idea due to the reasons outlined. Now, it's certainly OK to leave it as is. Better yet would be to bite the bullet at some point in time and introduce something clever instead, maybe with Whonix 9+.
Also Whonix-Workstation IP (192.168.0.11) would have to be changed. Please keep https://www.whonix.org/wiki/Multiple_Whonix-Workstations in mind. (One may want to create 20 VMs or something like that.)
I do not get your point here. Running 20 VMs with either 192.168.0.10 or 172.16.23.10 as the GW is the very same thing IF we'd introduce a more deliberated default with Whonix 9+. Forget about the scripting I proposed as an alternative. The changed default would be best here.
Can you think some more please about which IP is least likely to cause issues? And then create a VM test build (or change existing VM and reboot) with this change and see if everything (hidden services, torchat, leaktest) is working please?
Thinking about a clever default, we have 3 distinct Private IP ranges available.
  1. 10.0.0.0 - 10.255.255.255
  2. 172.16.0.0 - 172.31.255.255
  3. 192.168.0.0 - 192.168.255.255

Afaik, 192.168.(0,1,2).0/24 + 10.0.(0,1,2).0/24 are used in 99-100% of SOHO routers. So, my suggestion is to use something (lots of opportunities here) more obscure, i.e. something that’s not interfering in 99%-100% of the cases instead of using something that interferes in 25%-50% of the cases. As of breakage: If introduced as a default as of Whonix 9+, it won’t break anything if replaced correctly. It’s just another private IP address range as opposed to a public one.

#6

I agree with you. We can introduce this change in next version already. Not many lines have to be changed.

[quote]Also Whonix-Workstation IP (192.168.0.11) would have to be changed. Please keep https://www.whonix.org/wiki/Multiple_Whonix-Workstations in mind. (One may want to create 20 VMs or something like that.)[/quote] I do not get your point here. Running 20 VMs with either 192.168.0.10 or 172.16.23.10 as the GW is the very same thing IF we'd introduce a more deliberated default with Whonix 9+. Forget about the scripting I proposed as an alternative. The changed default would be best here.
I was talking about network classes here. Ideally we pick a network class that supports more than 255 distinct IP addresses, so we don't have to change this ever again. This tool (www.subnet-calculator.com/) seems useful.

VirtualBox uses 10.0.2.15, so we should avoid it. Also we should avoid other ranges likely used by VMware, KVM, QubesOS, etc. Also perhaps we should think about further ports to other virtualizers? Which IP range seems seems to support that best?

I guess there is an advantage is starting with xx.xx.xx.10 instead of xx.xx.xx.0, because in future one might want to drop other gateways in front or behind Whonix-Gateway (i2p-Gateway, Corridor-Gateway, cacheing-Gateway, Scanning-Gateway, etc.)?

Perhaps there is somewhere a list of reserved ranges already? Perhaps we should even apply for such a range?

An arbitrary suggestion (without researching if there is an existing list of used ranges by others):
Gateway IP: IP 10.12.15.10
Workstation IP: 10.12.15.11
Submast: 255.0.0.0
Range: 10.0.0.1 - 10.255.255.254

#7

I’m sorry … this thread somehow slipped completely off my radar (until now).

I was talking about network classes here. Ideally we pick a network class that supports more than 255 distinct IP addresses, so we don't have to change this ever again. This tool (www.subnet-calculator.com/) seems useful.
I'm not too sure if we really need more than 254 distinct ip addresses here. Your decision after all.
VirtualBox uses 10.0.2.15, so we should avoid it. Also we should avoid other ranges likely used by VMware, KVM, QubesOS, etc. Also perhaps we should think about further ports to other virtualizers? Which IP range seems seems to support that best?
We have to research this. Not within my spontaneous knowledge pool, so to speak. Also, see below my comment on your proposed ip range.
I guess there is an advantage is starting with xx.xx.xx.10 instead of xx.xx.xx.0, because in future one might want to drop other gateways in front or behind Whonix-Gateway (i2p-Gateway, Corridor-Gateway, cacheing-Gateway, Scanning-Gateway, etc.)?
I guess we misunderstood each other here. I was talking about xx.xx.xx.0/24 as a common short notation of xx.xx.xx.1-255, 255.255.255.0 here. Not promoting xx.xx.xx.0 as a GW address (wouldn't work anyway according to my humble knowledge).
Perhaps there is somewhere a list of reserved ranges already? Perhaps we should even apply for such a range?
There is no such "reserved" ranges. Private ip ranges mentioned previously are free-to-use for anyone without any reservation needed (not even possible, think LAN ip addresses)
An arbitrary suggestion (without researching if there is an existing list of used ranges by others): Gateway IP: IP 10.12.15.10 Workstation IP: 10.12.15.11 Submast: 255.0.0.0 Range: 10.0.0.1 - 10.255.255.254
I vote against this. As I said earlier 192.168.(0,1,2).0/24 + 10.0.(0,1,2).0/24 are the ones we should avoid like plague due to reasons outlined. I vote for something within 172.16.0.0 - 172.31.255.255 (VirtualBox, QubesOS, etc to be sorted out). Seems to be least likely conflicting.
#8
I'm not too sure if we really need more than 254 distinct ip addresses here. Your decision after all.
Thinking big. Whonix in cooperate networks. Whonix for ISPs etc. I wouldn't want to add unnecessary limitations while we're at it so we don't have to discuss & change this again.

Not reserved in that sense. More like “registered”. As in, they added themselves to a list and we’re better off not using the same one. Collaborative. No sanction if we disobey. Still useful to consider it.

#9

Proposal for Whonix 9. (Outdated!)

Gateway eth1.

auto eth1
iface eth1 inet static
       address 11.150.150.150
       netmask 255.255.192.0

Workstation eth0.

auto eth0
iface eth0 inet static
       address 11.150.150.151
       netmask 255.255.192.0
       gateway 11.150.150.150
#10

Implemented.

#11

@Patrick: you can’t say I didn’t warn you^^… good luck with that

Internet WAN or backbone routers (those that manage traffic between Internet Service Providers) all generally support CIDR to achieve the goal of conserving IP address space. Mainstream consumer routers often do not support CIDR, therefore [u]private networks (including home networks) and even small public networks (LANs) often do not employ it. [/u]

Source: http://compnetworking.about.com/od/workingwithipaddresses/a/cidr_notation.htm

#12

What config would you suggest?

#13

Damn it. This has to be changed again. I misread the private IP addresses list. 11.150.150.150 is not part of it. Only 10.0.0.0 through 10.255.255.255. So I’ll pick one from there.

#14

Yep, better don’t touch CIDR. It looks impressive but smells like a lot of trouble.

imo normal people are familiar with 192.168.x.x but it is overcrowded, 10.x.x.x looks too scary^^ and appears also quite often, so I would chose some 172.16.x.x.

#15

Proposal for Whonix 9.

Gateway eth1.

auto eth1
iface eth1 inet static
       address 10.152.152.10
       netmask 255.255.192.0

Workstation eth0.

auto eth0
iface eth0 inet static
       address 10.152.152.11
       netmask 255.255.192.0
       gateway 10.152.152.10
#16

So it finally stays classful - then I agree :slight_smile:

#17

Implemented.

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