On Thu, May 21, 2020 at 3:39 AM Claudio Jeker wrote: > > On Wed, May 20, 2020 at 07:00:56PM -0400, Jason Mader wrote: > > >Synopsis: IPv6 Internet hosts unreachable without a workaround > > >Category: system amd64 > > >Environment: > > System : OpenBSD 6.7 > > Details : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > OpenBSD 6.7 guest in VirtualBox 6.1.8 on host macOS 10.15.4 where the > > VM has an IPv6-only bridge network interface over en0 (MacBook Pro > > Wi-Fi), it's not possible to reach hosts beyond the gateway when > > OpenBSD is started. > > > > It is possible to secure shell from the host OS to the OpenBSD guest > > OS, but any attempt from OpenBSD to reach hosts outside the local > > network (dns, ntpd, etc.) fails. > > >How-To-Repeat: > > On the OpenBSD guest, a `ping6 2607:f8b0:4004:808::2004` > > (www.google.com) doesn't have a response. A packet capture on the host > > OS shows that the echo packet is going out, and the reply is coming > > back. The reply just doesn't seem to register on the OpenBSD guest. > > > > That is, until I trigger the workaround described below. > > >Fix: > > While looking into this, by happenstance I noticed that right after I > > `ping6` the gateway router that networking immediately starts to work > > correctly. I tried putting a "!ping6" command in hostname.vio0 but at > > the point when this is run the messages show no route to host. So the > > workaround I have is to put "ping6 -c 1 $gateway" in /etc/rc right > > before "echo -n 'starting early daemons:'" and that is good enough > > that the subsequent daemons (like ntpd) will start and be able to > > resolve dns and reach destinations. > > > > Of course it could be a problem with VirtualBox, but I wanted to share > > this. I also hoped to find a better workaround than editing /etc/rc to > > trigger the `ping6` or other helper at a point before networking is > > needed. > > > > This could be an issue with blocking ND packets in pf.conf. > Unlike ARP neighbor discovery uses multicast IPv6 packets which get > filtered by pf.conf. So something like this may help: > > # allow IPv6 router side > pass in inet6 proto icmp6 icmp6-type { routersol neighbrsol } > # allow IPv6 client side on external > pass in on external inet6 proto icmp6 icmp6-type { routeradv neighbradv } >
I gave your suggestion a try as, pass in inet6 proto ipv6-icmp all icmp6-type routersol pass in inet6 proto ipv6-icmp all icmp6-type neighbrsol pass in on external inet6 proto ipv6-icmp all icmp6-type routeradv pass in on external inet6 proto ipv6-icmp all icmp6-type neighbradv block return all pass all flags S/SA block return in on ! lo0 proto tcp from any to any port 6000:6010 block return out log proto tcp all user = 55 block return out log proto udp all user = 55 but it didn't work. I tried booting pf=NO. I also tried that the host OS has the $gateway in it's address mapping table while the OpenBSD guest is booting and tried adding a static NDP entry in OpenBSD. But so far, only `ping6` to the $gateway get's the networking working. I played with `traceroute6` to destinations beyond the $gateway, but that doesn't work. The workaround has to be to send something directly to the $gateway and then everything starts working. I have noticed some cases where `ping6 $gateway` doesn't work and the $gateway is in the OpenBSD guest's address mapping table. Deleting the entry, and then doing the `ping6` will get the network working. Meanwhile, from the $gateway device I can `ping6` OpenBSD.
