Cannot get IPv6 working on Qubes

230 views
Skip to first unread message

Franz

unread,
Jun 6, 2017, 6:27:10 PM6/6/17
to qubes...@googlegroups.com
Hello,

Since my ISP does not does not allow IPv6 connections, I set up a he.net tunnel in my openWRT router.

 It works connecting another linux computer to the router, but not connecting Qubes.

On Qubes, if I try to flag the box "require IPv6 addressing for this connection to complete" on network manager it is unable to connect. I tried both Fedora and Debian on sys-net, but none works.

Any idea what may be the problem? It should not be sys-firewall because it is behind sys-net.
best
Fran


Unman

unread,
Jun 6, 2017, 6:52:40 PM6/6/17
to Franz, qubes...@googlegroups.com
IPv6 isn't supported - some work has been done but it isn't complete as
yet. I don't think it is targeted until r4.

unman

Franz

unread,
Jun 6, 2017, 7:28:27 PM6/6/17
to Unman, qubes...@googlegroups.com
Ahhh!, many thanks Unman
unman

Alex

unread,
Jun 7, 2017, 2:27:17 AM6/7/17
to qubes...@googlegroups.com
On 06/07/2017 12:52 AM, Unman wrote:
>
> IPv6 isn't supported - some work has been done but it isn't complete
> as yet. I don't think it is targeted until r4.
>
AFAIR IPv6 was not meant to be supported in Qubes as is, because that
would mean that any networked AppVM would receive a public IPv6, but I
can't seem to find the e-mail thread (or the ITL blog post) where the
issue was explained.

What I can understand is that enabling IPv6 would mean:
* the NIC driver / direct memory access stuff would still be in the
sys-net vm
* if sys-net would like to act as a router, the subnet you get from
your ISP would have to be bigger than a /64
* sys-firewall should be able to perform the same filtering as today,
albeit with more complex rules (?)
* there would be no internal nat / private subnetting (?)

I'm not as much as knowledgeable on IPv6 as I should be, so I'm only
guessing the work that should be done.

If anybody could find/link/remember the reasons why IPv6 was explicitly
discarded in a first moment I'd like to re-read that...

--
Alex

signature.asc

pixel fairy

unread,
Jun 7, 2017, 7:53:09 AM6/7/17
to qubes-users, alex...@gmx.com
On Tuesday, June 6, 2017 at 11:27:17 PM UTC-7, Alex wrote:

> If anybody could find/link/remember the reasons why IPv6 was explicitly
> discarded in a first moment I'd like to re-read that...

heres the last thread i know of on the subject, https://groups.google.com/forum/?hl=en#!topic/qubes-devel/9WtBiQXvCOY

i believe the current plan is to nat ipv6, probably in v4.

you could probably do the same today from a proxyvm, which should work similarly to using one for a vpn. you would also have to set your ipv6 firewall rules in this, or another proxyvm chained to that.

pixel fairy

unread,
Jun 7, 2017, 7:54:45 AM6/7/17
to qubes-users, alex...@gmx.com
On Wednesday, June 7, 2017 at 4:53:09 AM UTC-7, pixel fairy wrote:

> i believe the current plan is to nat ipv6, probably in v4.

i should clarify, i meant the current plan being to nat ipv6 in qubes-os 4.x,
not to make some 4 to 6 translation bridge.

Franz

unread,
Jun 7, 2017, 8:39:31 AM6/7/17
to pixel fairy, qubes-users, Alex
Thanks. That is interesting. Once I set up a proxyvm for vpn and it was working, but I was following some instructions. What I would need is to leave an appVM open without nat, without firewall, just as it would be with a standard non-Qubes linux distribution with IPv6 working. Any idea how to do that?
Best
Fran
 
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b5c2033e-4ef9-4b6f-b52a-e9e52de7b24c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Unman

unread,
Jun 7, 2017, 9:37:38 AM6/7/17
to Franz, pixel fairy, qubes-users, Alex
On Wed, Jun 07, 2017 at 09:39:30AM -0300, Franz wrote:
> On Wed, Jun 7, 2017 at 8:53 AM, pixel fairy <pixel...@gmail.com> wrote:
>
> > On Tuesday, June 6, 2017 at 11:27:17 PM UTC-7, Alex wrote:
> >
> > > If anybody could find/link/remember the reasons why IPv6 was explicitly
> > > discarded in a first moment I'd like to re-read that...
> >
> > heres the last thread i know of on the subject, https://groups.google.com/
> > forum/?hl=en#!topic/qubes-devel/9WtBiQXvCOY
> >
> > i believe the current plan is to nat ipv6, probably in v4.
> >
> > you could probably do the same today from a proxyvm, which should work
> > similarly to using one for a vpn. you would also have to set your ipv6
> > firewall rules in this, or another proxyvm chained to that.
> >
> >
> Thanks. That is interesting. Once I set up a proxyvm for vpn and it was
> working, but I was following some instructions. What I would need is to
> leave an appVM open without nat, without firewall, just as it would be with
> a standard non-Qubes linux distribution with IPv6 working. Any idea how to
> do that?
> Best
> Fran
>

If you search the archive for cjdns, you'll find a thread where someone
did have IPv6 working. One issue is sorting the ip6tables, but this is
quite straight forward.

On reasons why IPv6 isnt yet implemented, there are various remarks.
Back in February Marek said:
<quote>
We're not considering having directly-addressable IPv6 VMs by default
(maybe an optional feature, but not sure if even that).
When we'll implement IPv6 support, it will also use NAT. There are many
reasons for that:
- not expose VMs to external traffic by default (even in case of some
firewall error, not allow directly address particular selected VM)
- not leak (or at least make it harder to guess) information about
source VM / number of them (or even the fact of using multiple VMs)
- not reconfigure every VM when user switch to a different network,
including plugging in VPN services etc
- the above is especially important in case of some privacy use
cases, to not leak "real" address to the VM
</quote>

unman

Alex

unread,
Jun 7, 2017, 9:40:53 AM6/7/17
to qubes...@googlegroups.com
On 06/07/2017 03:37 PM, Unman wrote:
> On Wed, Jun 07, 2017 at 09:39:30AM -0300, Franz wrote:
>> On Wed, Jun 7, 2017 at 8:53 AM, pixel fairy <pixel...@gmail.com>
>> wrote:
>>
>>> On Tuesday, June 6, 2017 at 11:27:17 PM UTC-7, Alex wrote:
>>>
>>>> If anybody could find/link/remember the reasons why IPv6 was
>>>> explicitly discarded in a first moment I'd like to re-read
>>>> that...
>>>
> [...]
> On reasons why IPv6 isnt yet implemented, there are various remarks.
> Back in February Marek said: <quote> We're not considering having
> directly-addressable IPv6 VMs by default (maybe an optional feature,
> but not sure if even that). When we'll implement IPv6 support, it
> will also use NAT. There are many reasons for that: - not expose VMs
> to external traffic by default (even in case of some firewall error,
> not allow directly address particular selected VM) - not leak (or at
> least make it harder to guess) information about source VM / number
> of them (or even the fact of using multiple VMs) - not reconfigure
> every VM when user switch to a different network, including plugging
> in VPN services etc - the above is especially important in case of
> some privacy use cases, to not leak "real" address to the VM
> </quote>
That was the quote I was looking for, thanks Unman.

--
Alex

pixel fairy

unread,
Jun 7, 2017, 10:28:39 AM6/7/17
to qubes-users, pixel...@gmail.com, alex...@gmx.com
On Wednesday, June 7, 2017 at 5:39:31 AM UTC-7, Francesco wrote:
>
> Thanks. That is interesting. Once I set up a proxyvm for vpn and it was working, but I was following some instructions. What I would need is to leave an appVM open without nat, without firewall, just as it would be with a standard non-Qubes linux distribution with IPv6 working. Any idea how to do that?

just run the tunnel client in that appvm.

if you need to install it to the templatevm, clone the templatevm to something like fedora24-ipv6, add the tunnel client to the new templatevm, then set that as the template of the appvm that needs it.

Franz

unread,
Jun 7, 2017, 1:32:27 PM6/7/17
to pixel fairy, qubes-users, Alex
Many thanks pixel fairy, but the tunnel is not supposed to work behind a nat and I understand that Qubes VMs access network through a nat. Am I wrong?
Best
Fran
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

pixel fairy

unread,
Jun 7, 2017, 6:22:30 PM6/7/17
to qubes-users
https://ipv6.he.net/certification/faq.php

it should work if the nat supports ip protocol 41, which most do.

worst case you would have to make a layer 2 vpn to some outside host and do it from there. openvpn can do this. but remember youd have to run that vpn in the appvm. thats another rabbit hole. this is probably another hole, but you only have to figure it out once.

cooloutac

unread,
Jun 7, 2017, 10:47:56 PM6/7/17
to qubes-users

as basic security the first thing I've always done to harden a box is to disable ipv6. most sane windows and ubuntu hardening guides will have that as the very first suggestion.

I'm sure there is many reasons but for me its just the simple fact that things can leak/tunnel through cause not everything is designed to monitor ipv6 yet. Some firewall programs I use for example do not support ipv6. Also It is also noisier on logs for admins that can eyeball. Also sometimes its not just your endpoint that can be misconfigured but some remote host you are connecting to.

Basically what you want to do I consider a security risk. My ISP also does not use ipv6 and I have no need for it either, unless just for some experimentation and learning. But i'm no expert and obviously you have your reasons and you should be able to do what you want. I just hope its not enabled by default...

Franz

unread,
Jun 9, 2017, 7:30:47 AM6/9/17
to pixel fairy, qubes-users, Alex
It worked @pixel fairy. Into /etc/networ/interfaces I had to put the settings provided by he.net, but changing the external IP address to the internal Qubes IP address  for that applVM  10.137.2.59/32. But had to put only 10.137.2.59, wihout the last /32.

Many thanks for your patience. I did not suppose it could be so easy! I went crazy installing the tunnel into an additional router....  for nothing. One should have a clear picture before starting,

Many thanks to all who replied trying to help.
Best
Fran
 
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages