Re: [qubes-users] Re: Looking to edit rules.ml of my mirage-firewall VM but since I cannot run shell, IDK what to do
On Thursday, April 11, 2019 at 8:02:33 PM UTC+8, Thomas Leonard wrote:
> On Thursday, April 11, 2019 at 4:16:17 AM UTC+1, Sphere wrote:
> > @unman Thanks for the clarification. I suppose I misunderstood it wrong
> > since I thought you have to set it directly using some sort of text editor
> > and be done with it. So I'll have to recompile it I see, welp guess I have
> > no choice but go through with that haha
> >
> > On Thursday, April 11, 2019 at 3:16:32 AM UTC+8, 799 wrote:
> > > Hello,
> > >
> > >
> > >
> > > Thomas Leonard schrieb am Mi., 10. Apr. 2019, 20:42:
> > > (...)
> > >
> > > To change the rules, you edit rules.ml, rebuild and redeploy (this should
> > > only take a couple of seconds after the first build).
> > >
> > >
> > > (...)
> > >
> > >
> > >
> > > Can you or someone from the mirage fw for Qubes team give some examples
> > > how to write rules for mirage?
> > >
> > >
> > > Examples:
> > >
> > >
> > > 1) can access via ssh
> > > 2) can reach using via TCP
> > > 3) Block access from to
> > >
> > > I think some example rules will make it easier to understand how to write
> > > rules.
>
> I've added some examples at
> https://github.com/mirage/qubes-mirage-firewall/pull/54 (see the changes to
> rules.ml).
>
> Actually, matching on individual machines was a bit ugly, so I also made some
> changes to let you name all the machines you want to refer at the start of
> the rules file. You'll need those changes too for the new examples to work.
>
> > > Regarding rebuilding and redployment:
> > > Maybe we can write a small script that will do the following:
> > >
> > >
> > > - launch mirage build VM
> > > - apply changes to rules.ml
> > > - rebuild
> > > - copy new kernel files back to dom0
> > > - shutdown mirage build VM
> > > - restart mirage firewall proxyVM
>
> See:
> https://github.com/mirage/qubes-mirage-firewall/#easy-deployment-for-developers
>
> e.g. I build and deploy the firewall from my dev VM with:
>
> [dev]$ make && test-mirage qubes_firewall.xen mirage-firewall
>
> It does what you describe, and also tails the log file so you can see it from
> the build VM. The process is triggered from the build VM rather than from
> dom0 because working in dom0 is risky. There is a policy so that only the
> builder VM can push the kernel, and only the mirage-firewall kernel can be
> updated.
>
> Note that the instructions for test-mirage show how to set up a "mirage-test"
> unikernel. You'll need to use "mirage-firewall" as the name instead.
>
> > I second this idea. I'm having a hard time myself trying to absorb the very
> > raw instructions of making rules in the rules.ml
> >
> > While the added convenience expands the surface of attack by a bit, I think
> > this can be very useful in environments where you have to frequently
> > interact with firewall rules.
> >
> > Also got questions about makings rules in rules.ml
> >
> > let from_client = function
> > | { dst = (`External _ | `NetVM) } -> `NAT
> > | { dst = `Client_gateway; proto = `UDP { dport = 53 } } -> `NAT_to
> > (`NetVM, 53)
> > | { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet
> > addressed to firewall itself"
> > | { dst = `Client _ } -> `Drop "prevent communication between client VMs"
> >
> > Does `NAT_to (`NetVM, 53) mean that NAT will be applied to the outgoing
> > packet then NetVM itself will process the DNS Query within its own VM
> > context? If this is right, then configuring a wrong DNS server within NetVM
> > would essentially mean DNS resolutions will fail right?
>
> Yes. Client AppVMs are by default configured to use the firewall as their DNS
> (check your /etc/resolv.conf). The firewall then just forwards these requests
> to sys-net.
>
> > Or is this because the rule { dst = `Client_gateway; proto = `UDP { dport =
> > 53 } } -> `NAT_to (`NetVM, 53) is intended for internal DNS resolutions?
> > (From my own understanding, that seems to be the case but I'd like to be
> > corrected if this rule really is for internet DNS resolutions)
> >
> > Moving forward, if I have no lapses in understanding the guidelines in
> > making rules, then this must be the ruleset for allowing only outgoing
> > traffic towards port 25, 110, and 143:
> >
> > let from_client = function
> > | { dst = (`External _ | `NetVM); proto = `TCP { dport = 25, 110, 143 } }
> > -> `NAT
>
> Nearly: dport = (25 | 110 | 143)
>
> > | { dst = (`Client_gateway | `Firewall_uplink) } -> `Drop "packet
> > addressed to firewall itself"
> > | { dst = `Client _ } -> `Drop "prevent communication between client VMs"
> >
> > I also want to know why there is an underscore in front of `External and
> > `Client
>
> That space contains information about which client or external machine it is.
> "_" matches anything.
Thank you very much for the sweet details! Sorry if I only got to reply now as
I was on vacation
--
You received this message because you are
Re: [qubes-users] qubes-mirage-firewall 0.5
I have been briefly reminded that technology is not some magic bullet where you just fire and forget. Thank you for this -- 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/977cc4bb-868b-43ff-b044-fe8ffb3a7238%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] /usr/bin/notify-send does not work when invoked via qubes-rpc
On Sun, Apr 21, 2019 at 06:50:06AM -0700, tom...@gmail.com wrote: > Hi all, > > I struggle to get something that's working in Q3.2 also in Qubes4: > > - I need to display message from AppVm on the screen (via notify-send in > dom0) and do it via qubes-rpc executed in AppVm "storage". rpc procedure is > named 'storage.log' > - allow policy in dom0: > > cat /etc/qubes-rpc/policy/storage.log: > > storage dom0 allow > > $anyvm $anyvm deny > - procedure: > > cat /etc/qubes-rpc/storage.log > > #!/usr/bin/bash > > > > read message > > /usr/bin/notify-send "$message" > > RPC is called this way in appvm 'storage': > > echo 'message from vm'|qrexec-client-vm dom0 storage.log > > What happens: > - In Q3.2 this works since years > - In Q4 action is executed, but nothing is displayed on screen. Action is > actually executed-in journalctl I see 'storage.log' is allowed, and if I add > 'echo $message|systemd-cat' that message is logged also. > > > - If its run in dom0, message is displayed on the screen: > > echo 'dom0 message'|/etc/qubes-rpc/storage.log > > > It seems like /usr/bin/notify-send does nothing when invoked via RPC. > > Any ideas? > Can I ask why you want to do this? Why dont you just call notify-send in the qube? What is the advantage of using a qubes-rpc call here? -- 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/20190422020659.u7d5by5wffuzmy4m%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] MirageOS as NetVM
Faq: Can I install Qubes OS on a system without VT-d? Yes. You can even run a NetVM, but you will not benefit from DMA protection for driver domains. On a system without VT-d, everything should work in the same way, except there will be no real security benefit to having a separate NetVM, as an attacker could always use a simple DMA attack to go from the NetVM to Dom0. Nonetheless, all of Qubes’ other security mechanisms, such as qube separation, work without VT-d. Therefore, a system running Qubes will still be significantly more secure than one running Windows, Mac, or Linux, even if it lacks VT-d. Since I only have 3GB RAM on my libreboot laptop, can I use Mirage to function as a NetVM to save memory? -- 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/8686fb250dab600d73df67dc166927d7.squirrel%40_. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Log qubes firewall packets
> >> Wondering how to log packets blocked and accepted by qubes firewall > >> for specific vm or all vms if thats the only option? Couldn't find > >> anything in website or google or qvm-firewall > > Unfortunately, Qubes firewall was not designed for such use case. > > > > If you are familiar with the iptables (and nftables too), you may be > > able to workraound this limitation. But it really not trivial to achieve So, logging is done via -j LOG target, like this (with same rules that would match actual action): iptables -t nat -A SSH2 -j LOG --log-prefix "DNAT SSH2-tunnel: " iptables -t nat -A SSH2 -j DNAT -p tcp --to 10.137.2.11:22 For blocked packages you should add log entry before DROP statements. You should review all chains and tables. Add your changes to sys-firewall:/rw/config/qubes-firewall-user-script. Be careful when inserting/adding rules, as they qubes dynamically changes the tables. By default LOG uses systemd log but it is configurable. Your question is not related to Qubes, but is general iptables-question. -- 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/a9399c1d-d316-48fb-af62-4832d60db84a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Log qubes firewall packets
Okay thanks, should I post this in issues as a feature request? On 4/21/19 4:06 PM, Zrubi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/21/19 9:13 PM, Frozentime345 wrote: Wondering how to log packets blocked and accepted by qubes firewall for specific vm or all vms if thats the only option? Couldn't find anything in website or google or qvm-firewall Unfortunately, Qubes firewall was not designed for such use case. If you are familiar with the iptables (and nftables too), you may be able to workraound this limitation. But it really not trivial to achieve . - -- Zrubi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAly8zUUACgkQVjGlenYH FQ3asQ//eFsUE/kigN5pFpkEYiQKxh5XGMtAaAtcdA4IhaPLqlnG+VkFZz0fTB3n Jv1sO6LYunL2DPSfOInUELHOu8ZiCMEIB4+SFqJszjCJADGDSBX7iEd5TyNDNU23 bV3hKU/6LI+bsDqbuwzteg/CgR8WxAtGhle/G/OOoQ3H2ViYxLOPudRLe0Pda12e zx1Ra7u0QMYXTO+vQWbvKcnlxkL41ataK+n1KkKYi+ToGfrmV5Kho0yg83H2ETXO +4xTcb5ZUtlmjgb0kP7Q14n5Qv5nLokzOCvAajGNDq6/IQQND0prD5GjIOztiCaB ugOWqGdWCVxJKyjoxF0YpzOrXZHzz1FsAH4/6zEhN8e8VvTf1moWCaAf2yOg4Qca wUKD78gBYtbO92eB5OEYkaKBE7GXOPOjKjHZQUBFFe8Z+BuOK55ZcEEwID8S+w3K QEaud/l5LetMK9GXrhZ4ti6vWEKLLPa9tDDOzUW7Qe+5+Epk96uj0NH/oM14Afmn TBGsw0YMCRuugfDrfpZOu+MMKxEt9zS3bLy6FBBIe7h84YV09Zl6mBzf3gWPqOSj cZpBlJVQaqY3P1A3yYhWyJ7eOdN+e36uV5a+PmBVm3mjMZcKkK4niLwDALGam/Zc U4g7XPVLJyssKFMd2FIL1d7QomC1gtI2w8jBbRzLQ4Xj7fsVyt0= =4NxJ -END PGP SIGNATURE- -- 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/578b2297-0d79-1678-0710-7369124b9069%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Log qubes firewall packets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 4/21/19 9:13 PM, Frozentime345 wrote: > Wondering how to log packets blocked and accepted by qubes firewall > for specific vm or all vms if thats the only option? Couldn't find > anything in website or google or qvm-firewall > Unfortunately, Qubes firewall was not designed for such use case. If you are familiar with the iptables (and nftables too), you may be able to workraound this limitation. But it really not trivial to achieve . - -- Zrubi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAly8zUUACgkQVjGlenYH FQ3asQ//eFsUE/kigN5pFpkEYiQKxh5XGMtAaAtcdA4IhaPLqlnG+VkFZz0fTB3n Jv1sO6LYunL2DPSfOInUELHOu8ZiCMEIB4+SFqJszjCJADGDSBX7iEd5TyNDNU23 bV3hKU/6LI+bsDqbuwzteg/CgR8WxAtGhle/G/OOoQ3H2ViYxLOPudRLe0Pda12e zx1Ra7u0QMYXTO+vQWbvKcnlxkL41ataK+n1KkKYi+ToGfrmV5Kho0yg83H2ETXO +4xTcb5ZUtlmjgb0kP7Q14n5Qv5nLokzOCvAajGNDq6/IQQND0prD5GjIOztiCaB ugOWqGdWCVxJKyjoxF0YpzOrXZHzz1FsAH4/6zEhN8e8VvTf1moWCaAf2yOg4Qca wUKD78gBYtbO92eB5OEYkaKBE7GXOPOjKjHZQUBFFe8Z+BuOK55ZcEEwID8S+w3K QEaud/l5LetMK9GXrhZ4ti6vWEKLLPa9tDDOzUW7Qe+5+Epk96uj0NH/oM14Afmn TBGsw0YMCRuugfDrfpZOu+MMKxEt9zS3bLy6FBBIe7h84YV09Zl6mBzf3gWPqOSj cZpBlJVQaqY3P1A3yYhWyJ7eOdN+e36uV5a+PmBVm3mjMZcKkK4niLwDALGam/Zc U4g7XPVLJyssKFMd2FIL1d7QomC1gtI2w8jBbRzLQ4Xj7fsVyt0= =4NxJ -END PGP SIGNATURE- -- 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/efc45631-892a-73fb-e6fc-ffb6f25532b5%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Log qubes firewall packets
Wondering how to log packets blocked and accepted by qubes firewall for specific vm or all vms if thats the only option? Couldn't find anything in website or google or qvm-firewall -- 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/049dca62-08a1-6f03-9fb7-73f99f5866b2%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes Installation freeze
I've so far been unable to get qubes 4.0.1 to install on my Dell laptop, it keeps freezing of file 909/1042 kernel-qubes-vm.x86_64. Its a nvme drive if that makes a difference. I've verified the ISO of qubes and that matches, I created the pen drive in Ubuntu using the DD command,as per the site, and I've used 2 different 16gb pen drives. The pen drive boots in legacy mode and lets me enter all settings and starts install. The installation hangs at the file shown above and I cannot find any way to exit or restart the machine other than a hard reboot. I've tried the UEFI troubleshooting on the qubes site as well, anyone else got any ideas? -- 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/29ccac95-230f-41c1-9969-a81213f10702%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-project] Re: Google "Season of Docs" -- deadline April 22
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 19/04/2019 10.15 PM, Andrew David Wong wrote: > On 19/04/2019 1.12 AM, Michael Carbone wrote: >> On 3/20/19 3:53 PM, Michael Carbone wrote: >>> On 3/15/19 3:27 AM, Andrew David Wong wrote: On 14/03/2019 8.28 AM, Michael Carbone wrote: > https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html > https://developers.google.com/season-of-docs/ This looks great. I think we should consider applying. >>> >>> will do! I'll loop in all the folks needed once it's open. >>> > >> hey all, > >> sorry for the short notice -- I'll be submitting the Season of Docs >> application on Monday night April 22 (deadline April 23). > >> Before then we need a 2019 Google Season of Docs page >> (https://www.qubes-os.org/gsod ?) that has project ideas for technical >> writing / documentation. > >> So let's get started with some brainstorming on technical writing / >> documentation needs! > >> Also with these ideas we need volunteer mentors - if you'd like to be a >> mentor, you need to register here: > >> https://forms.gle/a1x26WQGzURLerv66 > >> More info here: > >> https://developers.google.com/season-of-docs/ > >> https://developers.google.com/season-of-docs/docs/project-ideas > >> Thanks, >> Michael > > > Thanks, Michael. I've created an initial version of the GSoD page here: > > https://www.qubes-os.org/gsod/ > > It's pretty minimal and bare. Everyone, please help add content to this > page, especially project ideas to the ideas list. > Cross-posting to qubes-users for greater visibility. Everyone is welcome to contribute. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAly8tAAACgkQ203TvDlQ MDD7Tg//VziSc5HliLBV8ktn6O+PHuRnJO1/QWogC28ZiGZsZvAriex+mUIxqb8m 1GuTA3JxrRa0DAbN30V4poVF7EQhuaQ4Fp1DywriTJJ4hDsrDXj34EMlcitOIyEA z/ZuQwfosNrywV76BH52qiMUMnWY0bxwPftMnvJ5mQQ8eLtdmpN71Dr571Mu+0GW P++2MPtnCpVDhPSISqS8/ygVtN7LSbgMhtVVXr1vUHsUj77AUM1hnERgrLJyGm90 dvGEz5d1ZTuYftuPVMe+Gk8z4iCgc6O6v6Hqe6OuT3IOQGDkSjg+0M0wpTecgwHE wffEs0EgM8GXjgNheq99xcI4PcUwFwen1glau9C5Tu0YR32BynNqx2hCEBpsg8B1 xrC0gnoYyJOdoyhOk5w+SNvAMQwt87yLmeNH1WWfdLPfAx4DLymuGoFspXpz/4lJ 5gPVJ36VXW93itiHPLn3JCbCbDo3cLDvLY9EMPqQot35luJJwx9SJ361oQitxATt 8hyGVd0iNPiz9WrGL1gIMuJHu9yWBn+SLjnj3GsiXFQfz8a8cVwHFmsBs+i28Lzi MvLxggSv+wzS3XsPZA0VPJJHIJtG8dvw4hGLbiTSTO7J3sjyekzXO/YmhahxEIBV +l4xFV34fM2asx+DI+4oj4fenDEg0z9xv0XN1oiEdm03Q/DHqYc= =0n49 -END PGP SIGNATURE- -- 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/39abebc3-e3de-0a11-6349-709910a4f108%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] /usr/bin/notify-send does not work when invoked via qubes-rpc
Hi all, I struggle to get something that's working in Q3.2 also in Qubes4: - I need to display message from AppVm on the screen (via notify-send in dom0) and do it via qubes-rpc executed in AppVm "storage". rpc procedure is named 'storage.log' - allow policy in dom0: > cat /etc/qubes-rpc/policy/storage.log: > storage dom0 allow > $anyvm $anyvm deny - procedure: > cat /etc/qubes-rpc/storage.log > #!/usr/bin/bash > > read message > /usr/bin/notify-send "$message" RPC is called this way in appvm 'storage': > echo 'message from vm'|qrexec-client-vm dom0 storage.log What happens: - In Q3.2 this works since years - In Q4 action is executed, but nothing is displayed on screen. Action is actually executed-in journalctl I see 'storage.log' is allowed, and if I add 'echo $message|systemd-cat' that message is logged also. - If its run in dom0, message is displayed on the screen: > echo 'dom0 message'|/etc/qubes-rpc/storage.log It seems like /usr/bin/notify-send does nothing when invoked via RPC. Any ideas? -- 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/a3bfbe56-9408-4253-be6f-87bb0e244345%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Make files in AppVM persistent
Hello, unman schrieb am So., 21. Apr. 2019, 02:29: > (...) > Don't make the changes in the template. > bind-dirs is intended to work in the AppVM, (as I think you originally > tried). > You need to configure bind-dirs and restart the qube, *then* make any > changes that you want to make in /etc/openvpn. > You can check that the changes are there in /rw/bind-dirs/etc/openvpn. > Sorry, my mistake ... With your hint, the documentations says it already: (...) Inside your TemplateBasedVM (...) Maybe it would be good to change this into: (...) Inside your AppVM which is based on a Template (...) Additionally it seems that you need to run 6 steps, the numeration seems to be fixed, now it has two times 3 steps - I'll try to fix this in the GitHub repo. O/799. -- 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/CAJ3yz2ub1Zx0yS_ZuhHj%3D2cMcRkoc9ASG-Lw0r90PFgP94W8fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes4: net,fw,appvms-all in 10.137.0.* ?
Hi all, I tried test install of Qubes4 to test migration from 3.2 and I was surpised that sys-new,sys-fw and all appvm share same network 10.137.0.* This is in contrast to 3.2, where appVMs are in 10.137.2.*, firewalls in 10.137.1.*, and just sys-net in 10.137.0.* (like drawn in http://roscidus.com/blog/images/qubes/qubes-net.png) Why this change? I guess it did not happened accidentally in current v4 install. Seems I'll have to do lot of IP changes in iptable rules in sys-firewall (and for each appvm accepting connections from other appvm). I was hoping that appVM IPs will be kept when restoring from 3.2 backup (which anyway did not happen). If 10.137.0 is shared between all types of VMs there is no point in trying to manually set IPs to match those of 3.2 (in qubes .xml files describing vm configs), as networks are anyway different. regards, Tom -- 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/d190d69c-6b77-46f2-b212-6d9556f8c7bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
