On Tuesday, June 4, 2019 at 12:44:46 AM UTC+8, ronpunz wrote: > On 6/3/19 12:10 PM, unman wrote: > > On Mon, Jun 03, 2019 at 09:28:01AM +0000, ronpunz wrote: > >> On 6/3/19 12:54 AM, unman wrote: > >>> On Sun, Jun 02, 2019 at 06:24:33PM +0000, ronpunz wrote: > >>>> On 6/2/19 3:11 PM, unman wrote: > >>>>> On Sun, Jun 02, 2019 at 02:04:57PM +0000, ronpunz wrote: > >>>>>> On 6/2/19 1:46 PM, unman wrote: > >>>>>>> On Sun, Jun 02, 2019 at 01:41:48PM +0000, ronpunz wrote: > >>>>>>>> On 6/2/19 1:06 AM, unman wrote: > >>>>>>>>>> Not sure which direction to go next and to be honest, feel a bit > >>>>>>>>>> out of my > >>>>>>>>>> depth. When I started this task I thought there was a simple > >>>>>>>>>> correlation > >>>>>>>>>> between openFW to sys-net and fw to sys-firewall. In reality it > >>>>>>>>>> seems a > >>>>>>>>>> fair bit more complicated than that. For example, fw seems to have > >>>>>>>>>> a dual > >>>>>>>>>> firewall and network interface role? > >>>>>>>>>> > >>>>>>>>> I dont understand what this means. > >>>>>>>>> There is simple correlation as you describe, it's just that fw > >>>>>>>>> needs to > >>>>>>>>> do a little more work to provide the internal interface to the HVM. > >>>>>>>>> > >>>>>>>>> What error do you get when you bring up em0? > >>>>>>>>> What's the output from ifconfig? > >>>>>>>>> > >>>>>>>> I note the ifconfig screen shots were missed off my reply. > >>>>>>>> > >>>>>>>> They should be here > >>>>>>>> > >>>>>>> I'm sorry - can you cut and paste the contents rather than imaging? > >>>>>> Copy/paste as requested > >>>>>> > >>>>> ?? > >>>>> I cant see the images - paste the contents in the mail. > >>>>> > >>>> Sorry. I'm a bit confused. I pasted them in the mail and they're > >>>> viewable on > >>>> the qubes user forum at > >>>> https://groups.google.com/forum/#!topic/qubes-users/MpXLhz5COvM > >>>> > >>>> Please let me know if there's more i can do > >>>> > >>> I cant view them. > >>> Please post the contents, not pictures. > >>> > >> Gotcha. However, that's easier said than done. After trying and failed > >> using > >> various OCR software. To cut a long story short, I've ended up typing the > >> whole thing out as follows: > >> > >> joo# ifconfig > >> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768 > >> index 5 priortity 0 llprio 3 > >> groups: lo > >> ininet6 :: 1 prefixlen 128 > >> inet6 fe80 ::1%lo0 prefixlen 64 scopeid 0x5 > >> inet 127.0.0.1 netmask 0xff000000 > >> xnf0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > >> lladdr 00:16:3e:5e:6c:00 > >> index 1 priortity 0 llprio 3 > >> media: ethernet manual > >> status: active > >> inet: 10.137.0.10 netmask 0xff000000 broadcast 10.255.255.255 > >> re0: flags =8802<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500 > >> lladdr 1c:1b:0d:a4:1e:e4 > >> index 2 priortity 0 llprio 3 > >> media: ethernet autoselect (none) > >> status: no carrier > >> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > >> lladr 68:05:ca:55:75:6f > >> index 3 priortity 0 llprio 3 > >> groups: egress > >> media: ethernet autoselect 1000baseT > >> (full-duplex,master.rxpause,txpause) > >> status: active > >> enc0: flags=0<> > >> index 4 priortity 0 llprio 3 > >> groups: enc > >> status: active > >> pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136 > >> index 6 priortity 0 llprio 3 > >> groups: pflog > >> > >> I'm now able to successfully ping 8.8.8.8 but not google.com. Indicating a > >> dns issue? > >> > >> The dns setting in pf is iptables -t nat -I PR-QBS -p udp --dport 53 -j > >> DNAT > >> --to 9.9.9.9 > > I'm sorry for the pain in doing this - you could always have booted the > > openBSD qube with a USB attached, and transferred the files that way. > > Like a sneakernet but smaller scale - a fingernet? > > > > You dont say *from where* you are able to ping. Yes, this looks like a > > DNS issue. > > > > If you want to get this working from the BSD qube, then check > > /etc/resolv.conf > > This isn't necessary - in fact you may prefer NOT to allow outgoing > > traffic originating from the openBSD firewall. > > > > You say that rule you have is "in pf" - do you mean "in fw"?? It's just > > not a pf thing. > > So if it *is* in fw, and you are able to ping from fw, then this is looking > > good. > > Simplest way to proceed is to set /etc/resolv.conf in fw to use 9.9.9.9 > > > > Give just a little more detail on what's working and from where. > > > Update > > I've noticed that the contents of fwVM's /etc/resolv.conf does not > survive a reboot. The file contents revert to default values: > "nameserver 10.137.0.1 nameserver 10.137.3.254" > > I hope this helps debuging
That's normal, apparently that happens every single time an AppVM starts up even if you personally changed the value in the TemplateVM itself. Trust me, that's part of my frustrations back then lol. Could you try having another AppVM running and connected to your Openbsd netvm and see if you can access the internet just fine? If it happens to be that your AppVM fails to make DNS queries then one other way for you to solve this DNS problem is to rely on DNSCrypt instead: https://github.com/jedisct1/dnscrypt-proxy/releases There are things that you need to setup before running dnscrypt-proxy 1. Creating a dnscrypt-proxy.toml file using the example-dnscrypt-proxy.toml file 2. Tailoring the dnscrypt-proxy.toml file settings according to your preferences 3. Changing contents of your /etc/resolv.conf to this: nameserver 127.0.0.1 options edns0 single-request-reopen Thankfully there is no need to compile it yourself so it shouldn't be too much of a hassle. As for the problematic thing about /etc/resolv.conf resetting itself to 10.137. bla bla after starting, what you can do is copy the changed resolv.conf to your home directory and make a script in your dom0 terminal that will copy it and replace the newly refreshed /etc/resolv.conf. The general idea is to start the AppVM using qvm-run command that will do just that. CAUTION: You would not want to do this on your Openbsd netvm but instead on your other AppVM connected to your netvm. But I recommend to first have a firewallvm connected before the AppVM then connect the AppVM to the firewallvm whilst having no firewall rules set to it just yet for testing purposes. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5e9e79b9-d34e-4f9d-b35a-8dcbbdf04a10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
