On 2020-05-25 23:30, Marek Marczykowski-Górecki wrote: > On Mon, May 25, 2020 at 02:00:00PM -0400, Demi M. Obenour wrote: >> What is the correct setup for IPv6 routing on an OpenBSD HVM? >> IPv4 works fine, but IPv6 does not, although I can ping the gateway >> over IPv6. I suspect that the difference has something to do with >> proxy NDP vs proxy ARP, but I am not sure. > > This is likely. We do have enabled proxy ARP, but not proxy NDP. So, > setting any gateway on IPv4 should work, but not for IPv6. > > You can see expected configuration via qvm-prefs. Especially > "visible_gateway6" property is what you should set as the gateway. > But you can also play with proxy NDP, maybe more convenient solution > would be to just enable it (and keep an eye open for side effects).
Linux refuses to enable proxy NDP for a whole subnet, although this might be possible with a userspace daemon. That said, I would be fine so long as I was able to rely on a single fixed gateway address. (What I would really prefer is to avoid NDP and ARP entirely, and configure the corresponding tables statically. This should be quite possible on Linux, for example. This reduces both attack surface and the number of things that can go wrong.) >> In case it matters, I would prefer to avoid hardcoding the default >> gateway, but if that is necessary, I will. The addresses for the Xen >> network interfaces are already configured automatically by a script I >> wrote that reads the information from XenStore, but OpenBSD doesn’t >> seem to support userspace access to Xen grant tables or event channels, >> so reading from QubesDB would require building a custom kernel. >> I would prefer to avoid that. > > That's a bummer. Are there any plans for userspace access to those > interfaces? Without them, you won't have qrexec neither (if you'd like > this to be some next step). Not sure. I doubt that they are planning on writing drivers to allow this access themselves. If it is possible to grant access to them without allowing userspace to compromise the kernel, the OpenBSD team might be willing to accept patches, provided that whoever submitted the patches was willing and able to maintain them long-term. On the other hand, OpenBSD already has Xen netfront and blkfront drivers, so much of the infrastructure is already present. Another option is to use networking instead, but that is slow, ugly, and requires every OpenBSD qube to have network access. Furthermore, OpenBSD does not have netback or blkback drivers, so the only way it can serve as sys-net is if it is a frontend to the real sys-net. I have already had to patch /etc/rc and replace /usr/sbin/sysupgrade with my own version, so implementing deep integration with OpenBSD is likely to be a significant amount of work. Part of the difficulty is that OpenBSD is quite minimal. There are no loadable kernel modules, so we cannot add our own drivers without a custom kernel, and there are no bind mounts, so I had to resort to loopback NFS (which in turn requires extra work to avoid deadlocking at shutdown). Due to work commitments, I will not be able to work any further on QubesOS for a while. I hope what I have learned will be useful for others who want to run other OSs under Qubes. Sincerely, Demi -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0a2b64b4-4b87-7dec-119a-0e451428207a%40gmail.com.
signature.asc
Description: OpenPGP digital signature
