Is it possible to change sys-net's network class in case of collisions with VPN networks?

[peterw...@gmail.com]

Hi I have a VPN which uses 10.0.0.0/8 this makes collisions with all the subnets that sys-net uses, I was wondering if I could switch out the networks and use a class B network instead.

Let me know if this info is not sufficient, I am going home from work so I'm in a hurry :P

Thanks for your time.

Best regards,
Petur.

[Dominique St-Pierre Boucher]

I am also interested by this request. I have no idea how to change this!

Dominique

[Chris Laprise]

Seems the definition of a /8 block could be the cause; this looks sloppy
on the part of the VPN service provider.

You could monitor the logs of your VPN client to see what ip/route
commands are being pushed down (assuming a protocol similar to openvpn)
and then add an override to the local config that uses a more specific
block like /16. But you have to consider if there are many (addressable
to you) hosts on that VPN net and if their effective host addresses
range beyond 16 bits; there probably aren't but if so then this solution
may not work.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Dominique St-Pierre Boucher]

Hi Chris,

I work for a big company and the use 10.0.0.0/8 for the internal network. Multiple Site with all 10.x.0.0/16 network. Impossible to have that changed.

All I want, is to change the base IP adressing scheme for the Qubes VM!

Thanks

Dominique

[Unman]

I had started on the basis that Qubes provides a classic
internet-inna-box, and hacked about with SNAT. But there's a far
simpler solution.

First, take a backup of /usr/lib64/python2.7/site-packages/qubes/ - just
copy that directory somewhere safe.
Second, take a backup of /usr/lib64/python2.7/site-packages/qubes/ -
Shutdown all running network connected qubes.

Look in /usr/lib64/python2.7/site-packages/qubes/modules -
delete 005QubesNetVm.pyc and 005QubesNetVm.pyc
edit 005QubesNetVm.py and change every occurrence of 10.137 to 172.16
save the file.

Restart sys-net, and any network connected qubes, as usual.
Job done.

NB, this isn't perfect because it doesn't correctly set the proxy service
IP. If you use the default Qubes proxy you'll have to adjust iptables
to get it working properly.
Also, you'll see that disposableVMs have a different range - I don't use
that at all, and have custom scripts to spawn disposableVMs attached to
different routes. Should be trivial to work round that if you do
something different.
Both are, as they say, left as an exercise for the reader.


This is, of course a hack, not supported, and undoubtedly breaks your
warranty.
If it all goes horribly wrong, shutdown all qubes, restore the original
files from your backup and restart the network.

unman