Re: [EXT] Re: [qubes-users] wireless " intruder "
On Thursday, January 7, 2021 at 9:24:44 AM UTC haa...@web.de wrote: > On 1/6/21 6:11 PM, Ulrich Windl wrote: > > On 1/3/21 2:24 PM, haaber wrote: > > ... > >>> Maybe nmap causes the mirage death. That wouldn't be a good job by > >>> mirage though and should be reported as bug to the dev. > >> I thought that, too. How would verify it is really nmap? As a test, I > >> scanned two phones in my wifi (in the same dispVM), without any > trouble, > >> using the same command. I re-scanned the offensive object, 181 seconds > >> later mirage is dead again. Fascinating. > > > > Are there logs (the famous "last words")? > > (my) mirage does not log. It has a fixed size of 32 MB, not much space > for logging .. and dom0 has no useful info on that incident. > It should log to the console, which is recorded by dom0 in guest-mirage-firewall.log (you can also get to it via qubes-manager IIRC). Most likely it ran out of memory adding NAT entries for all the ports. Is this the current release version (using mini-os and PV) or the Git version (using solo5 and PVH)? The solo5 version has some problems with memory at the moment (https://github.com/mirage/qubes-mirage-firewall/issues/120 - seems to be reporting inaccurate heap stats). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/37174eba-4570-4b26-a002-acac85aa62d2n%40googlegroups.com.
[qubes-users] Re: Question on the new format of rules for Qubes mirage firewall
On Saturday, July 6, 2019 at 6:09:52 AM UTC+1, pr...@tutanota.de wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> With the old format of rules for the mirage firewall I had the following
> setup:
>
> ...
> let git_addr = Ipaddr.V4.of_string_exn "192.168.1.101"
>
> let allowed_to_git = List.map Ipaddr.V4.of_string_exn
> [ "10.137.0.20" ;
> "10.137.0.21"
> ]
>
> let local_subnet = Ipaddr.Prefix.of_string_exn "192.168.0.0/16"
>
> let mgmt_local = Ipaddr.V4.of_string_exn "10.137.0.22"
>
> let from_client = function
> | { src = `Client c; dst = `External e } when Ipaddr.Prefix.mem e
> local_subnet
> && c#other_ip = mgmt_local -> `NAT
> | { src = `Client c; dst = `External e } when e = Ipaddr.V4 git_addr
> && List.mem c#other_ip allowed_to_git -> `NAT
> ...
>
> Is it possible to get the same functionality with the new rules using the
> prefix
> and the lists of addresses? It would also be useful to be able to block
> prefixes
> as well if that's possible.
There are two ways to get that working. The quick way is to get the src/dst IP
addresses from the `packet` field instead, e.g.
let externals = [
"192.168.1.101", `Git;
]
...
| { src = `Client _;
dst = `External `Git;
packet = `IPv4 ({Ipv4_packet.src}, _)}
when List.mem src allowed_to_git -> `NAT
Another solution would be to edit firewall.ml to allow specifying subnets, not
just hosts. That's a bit more work, though.
--
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/8c2ffafe-4893-44ec-bb6a-38501449dbbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Mirage-firewall - build fails
On Wednesday, June 19, 2019 at 10:31:41 AM UTC+1, ronpunz wrote: > In the past I've successfully built mirage-firewall on several > occasions. However following a recent reinstall of qubesos I've been > unable to successfully build the firewall. > > In summary I've tried building using fedora-29, fedora-30 and debian-10. > The errors associated with fedora 29 & 30 are similar and are listed below: > > Maybe someone can point me to a solution? [...] > # File "lib/xenstore.ml", line 165, characters 19-34: > # Error: The module OS is an alias for module Os_xen, which is missing Sorry about that - it should be fixed now (see https://github.com/mirage/qubes-mirage-firewall/pull/72). I needed to depend on netchannel >= 1.11.0 before it had been released, so I set it to use the latest Git version instead (I should have pinned it to a fixed version instead of just using the latest). 1.11.0 was released soon afterwards, and I've now removed the pin, so it's back to using an official release. -- 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/a94834c0-6ccc-4d95-b753-41686c1585dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.6
On Wednesday, May 29, 2019 at 4:27:05 PM UTC+1, ronpunz wrote: > On 5/29/19 2:08 PM, Thomas Leonard wrote: > > On Wednesday, May 29, 2019 at 2:27:28 PM UTC+1, ron...@riseup.net wrote: > >> On 2019-05-29 07:57, Thomas Leonard wrote: > >>> I'm pleased to announce the release of qubes-mirage-firewall 0.6: > >>> > >>>https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6 > >>> > >>> This is a unikernel that can run as a QubesOS ProxyVM, replacing > >>> sys-firewall. It may be useful if you want something smaller or > >>> faster-to-start than the Linux-based sys-firewall. It requires around > >>> 32MB of RAM when running and requires "0.0s" of CPU time to boot, > >>> according to "xl list". It does not need or use a hard-disk, and does > >>> not persist any state between reboots. > >>> > >>> For installation instructions, see: > >>> > >>>https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md > >>> > >>> To upgrade from an earlier release, just overwrite > >>> /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz in dom0 with the new > >>> version and restart the firewall VM. > >> I upgraded to mirage-firewall 0.6. > >> Is there any way to verify that i'm now running 0.6 rather than an > >> earlier version? > > When 0.6 boots, it prints a message like this, which earlier versions > > didn't: > > > > INF [dao] Got network configuration from QubesDB: > > NetVM IP on uplink network: 10.137.0.5 > > Our IP on uplink network: 10.137.0.19 > > Our IP on client networks: 10.137.0.19 > > > > So if you see that in the logs then you're running 0.6. But yeah, maybe it > > should print a version number somewhere too... > > > The output from my log is: > > 2019-05-29 12:38:50 -00:00: INF [dao] Got network configuration from > QubesDB: > NetVM IP on uplink network: 10.137.0.5 > Our IP on uplink network: 10.137.0.30 > Our IP on client networks: 10.137.0.30 > > It differs from your example but I guess its OK? Yes - you're running 0.6! -- 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/db6b724d-4726-4258-b27e-b6775ad32a10%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to update dom0 via mirage-firewall
On Wednesday, May 29, 2019 at 2:06:44 PM UTC+1, ron...@riseup.net wrote: > I'm trying to get mirage-firewall as the vehicle for dom0 updates. > Seemingly, it's only possible to update dom0 using sys-firewall or > sys-whonix via the following settings: Qubes VM Manager -> System -> > Global Settings -> UpdateVM -> sys-whonix. > Anyone know how to get mirage-firewall as the default update mechanism > for dom0? That won't work - the dom0 updater wants to run the shell script /usr/lib/qubes/qubes-download-dom0-updates.sh in UpdateVM, which is only going to work on a Unix-type system (mirage-firewall doesn't have any kind of shell). But you can use any Linux VM as your UpdateVM instead. https://www.qubes-os.org/doc/software-update-dom0/ says: > The role of UpdateVM can be assigned to any VM in the Qubes VM Manager, and > there are no significant security implications in this choice. By default, > this role is assigned to the firewallvm. -- 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/00f830f5-251c-488e-a944-a5edcfa6d0a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.6
On Wednesday, May 29, 2019 at 2:27:28 PM UTC+1, ron...@riseup.net wrote: > On 2019-05-29 07:57, Thomas Leonard wrote: > > I'm pleased to announce the release of qubes-mirage-firewall 0.6: > > > > https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6 > > > > This is a unikernel that can run as a QubesOS ProxyVM, replacing > > sys-firewall. It may be useful if you want something smaller or > > faster-to-start than the Linux-based sys-firewall. It requires around > > 32MB of RAM when running and requires "0.0s" of CPU time to boot, > > according to "xl list". It does not need or use a hard-disk, and does > > not persist any state between reboots. > > > > For installation instructions, see: > > > > https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md > > > > To upgrade from an earlier release, just overwrite > > /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz in dom0 with the new > > version and restart the firewall VM. > > I upgraded to mirage-firewall 0.6. > Is there any way to verify that i'm now running 0.6 rather than an > earlier version? When 0.6 boots, it prints a message like this, which earlier versions didn't: INF [dao] Got network configuration from QubesDB: NetVM IP on uplink network: 10.137.0.5 Our IP on uplink network: 10.137.0.19 Our IP on client networks: 10.137.0.19 So if you see that in the logs then you're running 0.6. But yeah, maybe it should print a version number somewhere too... -- 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/0c193bd4-3953-40e2-9857-2d32e2b370ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes-mirage-firewall 0.6
I'm pleased to announce the release of qubes-mirage-firewall 0.6: https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.6 This is a unikernel that can run as a QubesOS ProxyVM, replacing sys-firewall. It may be useful if you want something smaller or faster-to-start than the Linux-based sys-firewall. It requires around 32MB of RAM when running and requires "0.0s" of CPU time to boot, according to "xl list". It does not need or use a hard-disk, and does not persist any state between reboots. For installation instructions, see: https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md To upgrade from an earlier release, just overwrite /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz in dom0 with the new version and restart the firewall VM. For a blog post explaining the background for this, with a walk-through of the code (it's written in OCaml), see: http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ Changes to rules language: - Allow naming hosts (@talex5, #54). Previously, we passed in the interface, from which it was possible (but a little difficult) to extract the IP address and compare with some predefined ones. Now, we allow the user to list IP addresses and named tags for them, which can be matched on easily. - Add some types to the rules (@talex5, #54). Before, we inferred the types from `rules.ml` and then the compiler checked that it was consistent with what `firewall.ml` expected. If it wasn't then it reported the problem as being with `firewall.ml`, which could be confusing to users. - Give exact types for `Packet.src` (@talex5, #54). Before, the packet passed to `rules.ml` could have any host as its `src`. Now, `from_client` knows that `src` must be a `Client`, and `from_netvm` knows that `src` is `External` or `NetVM`. - Combine `Client_gateway` and `Firewall_uplink` (@talex5, #64). Before, we used `Client_gateway` for the IP address of the firewall on the client network and `Firewall_uplink` for its address on the uplink network. However, Qubes 4 uses the same IP address for both, so we can't separate these any longer, and there doesn't seem to be any advantage to keeping them separate anyway. Bug fixes: - Upgrade to latest mirage-nat to fix ICMP (@yomimono, @linse, #55). Now ping and traceroute should work. Reported by @xaki23. - Respond to ARP requests for `*.*.*.1` (@talex5, #61). This is a work-around to get DHCP working with HVM domains. Reported by @cgchinicz. See: https://github.com/QubesOS/qubes-issues/issues/5022 - Force backend MAC to `fe:ff:ff:ff:ff:ff` to fix HVM clients (@talex5, #61). Xen appears to configure the same MAC address for both the frontend and backend in XenStore. This works if the client uses just a simple ethernet device, but fails if it connects via a bridge. HVM domains have an associated stub domain running qemu, which provides an emulated network device. The stub domain uses a bridge to connect qemu's interface with eth0, and this didn't work. Force the use of the fixed version of mirage-net-xen, which no longer uses XenStore to get the backend MAC, and provides a new function to get the frontend one. - Wait if dom0 is slow to set the network configuration (@talex5, #60). Sometimes we boot before dom0 has put the network settings in QubesDB. If that happens, log a message, wait until the database changes, and retry. Reproducible builds: - Add patch to cmdliner for reproducible build (@talex5, #52). See https://github.com/dbuenzli/cmdliner/pull/106 - Use source date in .tar.bz2 archive (@talex5, #49). All files are now added using the date the `build-with-docker` script was last changed. Since this includes the hash of the result, it should be up-to-date. This ensures that rebuilding the archive doesn't change it in any way. Reported by @h01ger. Documentation changes: - Added example rules showing how to block access to an external service or allow SSH between AppVMs (@talex5, #54). Requested at https://groups.google.com/d/msg/qubes-users/BnL0nZGpJOE/61HOBg1rCgAJ. - Add overview of the main components of the firewall in the README (@talex5, #54). - Link to security advisories from README (@talex5, #58). - Clarify how to build from source (@talex5, #51). - Remove Qubes 3 instructions (@talex5, #48). See https://www.qubes-os.org/news/2019/03/28/qubes-3-2-has-reached-eol/ -- 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/dc83add8-3a60-4957-a4db-828a9cd36e76%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.5
On Tuesday, April 23, 2019 at 5:02:36 PM UTC+1, brend...@gmail.com wrote: > Hi Thomas, > > The build script uses download.camlcity.org which appears to be chronically > down. > > Any consideration for replacements? It's up for me. What error are you seeing? -- 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/e2b00c4b-0744-456e-8a24-3ba5c33aba39%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Windows 10 Pro HVM does not work with Mirage Firewall
On Friday, April 19, 2019 at 12:19:28 PM UTC+1, Claudio Chinicz wrote: > On 19/04/2019 12:05, Thomas Leonard wrote: > > On Thursday, April 18, 2019 at 9:53:25 AM UTC+1, Claudio Chinicz wrote: > >> Hi All, > >> > >> Once again I turn to the Qubes Community to ask for help. > >> > >> I have a Mirage Firewall VM that works with HVM (Linux Mint) and > >> Debian/Fedora template-based PVMs. > >> > >> My Windows 10 HVM, which works just fine through sys-firewall > >> (copy/paste and file sharing with other VMs dont, but I can live with it). > >> > >> I've tried setting up networking manually by adding its IP, mask and > >> gateway and rebooting but it did not work. It works with DHCP instead > >> when getting network through sys-firewall. > >> > >> I've followed all the ideas from here > >> (https://www.windowscentral.com/how-regain-internet-access-after-installing-update-windows-10) > >> and it still did not work. > >> > >> One last piece of information, my Windows 10 Pro was successfully > >> activated using a key I provided. > >> > >> Any ideas? This is not critical, since I can continue using > >> sys-firewall, but would love to free some memory by using Mirage. > > > > There might be clues in the firewall VM's logs. You can see them with Qubes > > Manager (right-click on mirage-firewall and choose Logs -> > > guest-mirage-firewall.log). Open the logs just after booting Windows and > > seeing that networking doesn't work and look at the end. > > > > You can also do "sudo xl console mirage-firewall" in dom0 to follow the > > logs and then boot Windows and watch for new entries. > > > > Hi Thomas, > > Thanks in advance. Please see below logs from guest-mirage-firewall.log. > My Windows VM is 10.137.0.21. > > What really surprises me is why I does not work even if I set my > ip/mask/gateway as it works with Linux Mint? What's different with Windows? > > Best Regards, > > Claudio > > 2019-04-18 11:20:11 -00:00: INF [qubes.db] got update: > "/mapped-ip/10.137.0.21/visible-ip" = "10.137.0.21" > 2019-04-18 11:20:11 -00:00: INF [qubes.db] got update: > "/mapped-ip/10.137.0.21/visible-gateway" = "10.137.0.23" [...] > 2019-04-18 11:20:22 -00:00: INF [client_eth] who-has 10.137.0.1? > 2019-04-18 11:20:22 -00:00: INF [client_eth] unknown address; not responding (continued at https://github.com/mirage/qubes-mirage-firewall/issues/56) -- 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/90a21fd2-ae0b-4963-86ac-4c91155e7112%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Windows 10 Pro HVM does not work with Mirage Firewall
On Thursday, April 18, 2019 at 9:53:25 AM UTC+1, Claudio Chinicz wrote: > Hi All, > > Once again I turn to the Qubes Community to ask for help. > > I have a Mirage Firewall VM that works with HVM (Linux Mint) and > Debian/Fedora template-based PVMs. > > My Windows 10 HVM, which works just fine through sys-firewall > (copy/paste and file sharing with other VMs dont, but I can live with it). > > I've tried setting up networking manually by adding its IP, mask and > gateway and rebooting but it did not work. It works with DHCP instead > when getting network through sys-firewall. > > I've followed all the ideas from here > (https://www.windowscentral.com/how-regain-internet-access-after-installing-update-windows-10) > > and it still did not work. > > One last piece of information, my Windows 10 Pro was successfully > activated using a key I provided. > > Any ideas? This is not critical, since I can continue using > sys-firewall, but would love to free some memory by using Mirage. There might be clues in the firewall VM's logs. You can see them with Qubes Manager (right-click on mirage-firewall and choose Logs -> guest-mirage-firewall.log). Open the logs just after booting Windows and seeing that networking doesn't work and look at the end. You can also do "sudo xl console mirage-firewall" in dom0 to follow the logs and then boot Windows and watch for new entries. -- 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/cd71cfb3-05ef-4ce9-b101-d257fac5d439%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: just dreaming: mirage-tor ?
On Tuesday, April 9, 2019 at 1:40:29 AM UTC+1, haaber wrote: > as you may have noticed by the mirage-firewall discussions, one > impressive point is the size of mirage -- 32M. That is not yet the 640K > I grew up with, but much more memory-friendly than the > standard-sys-firewall (which took 384M in my system). Another (to me: > inexplicably large) qube in my system is sys-whonix - it takes almost > 900M of memory! So I was day-dreaming if a mirage-tor is potentially > within reach ? Or is that > - too complex > - too hard to keep living, since tor itself evolves quickly See: https://lists.xenproject.org/archives/html/mirageos-devel/2019-04/msg00018.html -- 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/7f0e42fd-a0d6-42de-b716-edae8790ed74%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.5
On Monday, April 8, 2019 at 9:45:05 AM UTC+1, Sphere wrote: > So I have briefly read README.md about this and does this thing really have > to run as a PV VM and cannot be a PVH VM? See: https://lists.xenproject.org/archives/html/mirageos-devel/2019-04/msg00019.html -- 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/b12d447f-4dfb-4233-a2f9-0c5d61a45012%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 Saturday, April 13, 2019 at 12:24:47 AM UTC+1, 799 wrote:
> Hello Thomas.
> On Thu, 11 Apr 2019 at 14:02, Thomas Leonard wrote:
> [...]
>
> I've added some examples at
> https://github.com/mirage/qubes-mirage-firewall/pull/54 (see the changes to
> rules.ml).
>
> Thanks a lot for your excellent work and adding more information to
> mirage-firewall, greatly appreciated.
> Regarding the example rules:
>
> | { src = `Client `Dev; dst = `Client `Untrusted; proto = `TCP { dport = 22 }
> } -> `Accept
> | { dst = `External `GoogleDNS } -> `Drop "block Google DNS"
>
> these two rules are easy to understand and will help me setting up rules
> between the AppVms
>
> | { src = `Client _; dst = `Client _; proto = `TCP _; packet }
> when not (is_tcp_start packet) -> `Accept
>
> Can you add more details about this rules, its an any-to-any rule, but what
> is "when not (is_tcp_start packet) ?
The Dev->Untrusted:ssh rule allows TCP packets from Dev to Untrusted:ssh, but
you also need to allow packets in the other direction. There are various ways
to do that; this example rule allows any TCP packet that isn't trying to start
a new TCP connection to go between AppVMs, which should do the trick.
You don't need this for external sites because the `NAT action also adds a rule
that translates the responses, and that automatically allows the responses
through. But `Accept just lets the packet through without remembering anything
about the new connection.
is_tcp_start is defined in packet.ml. It means the same as Packet.is_tcp_start,
but we can leave off the module name because of the "open Packet" at the top of
rules.ml.
(* The first message in a TCP connection has SYN set and ACK clear. *)
let is_tcp_start = function
| `IPv4 (_ip, `TCP (hdr, _body)) -> Tcp.Tcp_packet.(hdr.syn && not hdr.ack)
| _ -> false
People who know more than me about TCP can probably suggest better ways to do
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/9e22ca35-9d4e-40d1-beaa-ae89a3f67278%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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 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.
--
[qubes-users] Re: Looking to edit rules.ml of my mirage-firewall VM but since I cannot run shell, IDK what to do
On Wednesday, April 10, 2019 at 3:12:25 AM UTC+1, Sphere wrote: > So I have now also boarded the mirage-firewall VM hype to replace > sys-firewall in order to take advantage of the very nice small memory > consumption of just 32 MB > > After searching around I literally failed to find anything that could help me > know how I'm gonna edit rules.ml in the mirage-firewall VM > > The VM as it is right now is running on fedora-29 and trying to launch > gnome-terminal/xterm in the VM using qvm-run returns with the error code that > I usually get when it doesn't recognize the command/command does not exist in > the VM at all > > May I ask for any leads in getting through this? mirage-firewall doesn't use a hard disk, so being based on the fedora-29 template doesn't make any difference (it won't load anything from it). It's not Linux. There's no terminal, no graphics system, and no bash. Not even /bin/sh. In fact, there's no filesystem, so no "/" at all. Commands are handled here: https://github.com/mirage/qubes-mirage-firewall/blob/master/command.ml - as you can (maybe) see, it only supports SetDateTime and WaitForSession commands by default. To change the rules, you edit rules.ml, rebuild and redeploy (this should only take a couple of seconds after the first build). Rules.from_client is an OCaml function that takes one argument giving information about an IP packet as input, and returns an action saying what to do about it. The type of this argument is specified in https://github.com/mirage/qubes-mirage-firewall/blob/master/packet.ml To get a quick overview of OCaml syntax, try https://try.ocamlpro.com/ For lots of details: http://dev.realworldocaml.org/ I believe some people are planning to add support for reading the rules from QubesDB so you can instead configure the firewall interactively with the dom0 GUI, like you can for sys-firewall. I'm not sure what the status of that work is, though. -- 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/c333a2f9-8932-4cc3-a375-df7eaf6d9c6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes-mirage-firewall chaining
On Monday, April 8, 2019 at 11:20:13 PM UTC+1, qmirfw wrote: > Hello, > > I got the qubes-mirage-firewall working in a simple > > sys-net --> sys-mirage-fw --> disp1234 > > situation, but when I wanted to include it in my normal chain, as in > > sys-net --> sys-mirage-fw --> sys-firewall --> AppVMs > > my AppVMs can't access the network. > > Is this supposed to work? > > In Xen console of the mirage firewall I can see the linux firewall > connecting, but then lines like this: > > WRN [client_net] Incorrect source IP 10.137.0.45 in IP packet from > 10.137.0.12 (dropping) What is the IP address of sys-firewall and the AppVM? It sounds like mirage-firewall got a packet from sys-firewall with source address 10.137.0.45, but it thinks that sys-firewall should have the IP address 10.137.0.12 (and be doing NAT on behalf of its clients). -- 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/bd0b616b-d9a9-408a-a335-44f7d3122eaf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes-mirage-firewall 0.5
On Monday, April 8, 2019 at 1:29:53 PM UTC+1, haaber wrote: [...] > Q2: How do you integrate the pull/52 into the qubes-mirage-firewall > folder without fiddling files by hand? To test that PR: git pull origin pull/52/head rm -rf _build sudo ./build-with-docker.sh -- 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/27409062-9dee-4f3d-b2a1-08740903bf2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes-mirage-firewall 0.5
On Monday, April 8, 2019 at 12:29:30 PM UTC+1, haaber wrote: > here is some build-news. next hint: give your template a lot of *disk > space*. My last error was due to that, but of course it did not tell me > "disc full" but some random other message. So now I am getting closer: > sudo ./build-with-docker.sh > > > Step 9/9: > Successfully tagged qubes-mirage-firewall:latest > Building Firewall... > error while executing ocamlbuild -use-ocamlfind -classic-display -tags > bin_annot -quiet -Xs _build-solo5-hvt,_build-ukvm > -pkgs mirage config.cmxs > + mkdir /home/opam/qubes-mirage-firewall/_build > mkdir: cannot create directory > '/home/opam/qubes-mirage-firewall/_build': Permission denied > Command exited with code 1. > Failure: >Error during command "mkdir /home/opam/qubes-mirage-firewall/_build": > Ocamlbuild_pack.My_std.Exit_with_code(10). > > -- > > so we are back with the question of /home/opam instead of /home/user ... > > Is docker trying to write to the "real" /home or at some sort of > chroot'ed /home inside docker ??? Aaaargh! `_build` is your _build directory, which is mounted into the chroot by the -v option. You can go into the environment yourself and try making it manually to find out what the problem is: $ docker run --rm -it --entrypoint bash -v $(pwd):/home/opam/qubes-mirage-firewall qubes-mirage-firewall opam@aaa050f3779c:~/qubes-mirage-firewall$ mkdir _build The Docker build user has UID 1000, which should be the same as the default qubes user (use "id" inside and outside of the build environment to see). -- 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/35cebfb0-6351-4b7d-a754-2774717baf95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes-mirage-firewall 0.5
On Monday, April 8, 2019 at 2:20:28 AM UTC+1, haaber wrote: > > On Sunday, April 7, 2019 at 6:06:13 AM UTC+1, haaber wrote: > >> Hey Thomas, > >> > >> I are right, it that was definitely better to put the FAQ on the site > >> (and this list). I did set up a standalone debian-10 to build, and the > >> process went through smoothly. Thank you. The 'but' comes now: BUT, in > >> the end the checksum fails! > > > > Did you use Docker to build it in your standalone qube? It should match if > > so. If not, it's unlikely to match because you're probably building against > > different library versions. > > OK that is a convincing argument for docker. So: I did it, actually > three times, more and more frustrated. First in my "failed" template, > then after having wiped old build remainders, then, to be sure, in a > brand new debian-10. I did (and only did(!), since it was a brand new > template) > > sudo apt-get install docker docker.io > git clone https://github.com/mirage/qubes-mirage-firewall.git > cd qubes-mirage-firewall > su > bash -x ./build-with-docker.sh > > > This fails, reproducibly over two days and several templates. Here is > the output (sorry, a few lines) [...] > fatal: Unable to look up github.com (port 9418) (Temporary failure in > name resolution) I believe that the Qubes sys-firewall by default prevents template VMs from connecting to anything except their package repositories. It's OK to install Docker in a template VM if you want, but everything else should be done in an AppVM. I've added more details at https://github.com/mirage/qubes-mirage-firewall/pull/51/files I tested this with Debian 9, but I assume it would work the same on Debian 10. By the way, while testing it I found one case where the hash can change even with Docker, and proposed a fix for that at https://github.com/mirage/qubes-mirage-firewall/pull/52 -- 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/f7d1494e-aea5-4ba1-883c-6fc805f71af0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.5
On Sunday, April 7, 2019 at 9:23:13 PM UTC+1, 799 wrote: > Hello Thomas, > > > > Thomas Leonard schrieb am Do., 4. Apr. 2019, 12:27: > I'd like to announce the release of qubes-mirage-firewall 0.5: > > https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.5 > (...) > > For installation instructions, see: > > https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md, > > > thanks for the work you put into your mirage-firewall, as I have read your > announcement several times in the past, I'd like to give it a try, but I > would like to see some more information which is targeted towards newbies. > To me it is not clear how I can setup the mirage-firewall. > It seems that your suggestion is to build a docker image and while this > covered in the installation howto > (https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md) the > docker building must be started within an AppVM ... should this be a template > VM? a dedicated HVM? And should it be debian or fedora? > I'd like to have a step for step instruction which takes a standard Qubes > Installation as baseline and then ends in a working mirage firewall. > As mentioned I would be more than happy o contribute to the documentation, > but can you clarify the starting point? I've proposed some extra text suggesting users should "Create a new Fedora-29 AppVM (or reuse an existing one)": https://github.com/mirage/qubes-mirage-firewall/pull/51 Does that help? -- 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/37ab3faa-af0e-4306-8b13-86d4da22555f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes-mirage-firewall 0.5
On Sunday, April 7, 2019 at 6:06:13 AM UTC+1, haaber wrote:
> Hey Thomas,
>
> I are right, it that was definitely better to put the FAQ on the site
> (and this list). I did set up a standalone debian-10 to build, and the
> process went through smoothly. Thank you. The 'but' comes now: BUT, in
> the end the checksum fails!
>
> sha256sum vmlinuz
> 570be5685298acb014cfaec132a35469e1cafbe2f731945dc5c57e8956e6638f
Did you use Docker to build it in your standalone qube? It should match if so.
If not, it's unlikely to match because you're probably building against
different library versions.
> I stored the output of find . -type f -exec sha256sum \{} \; of the
> qubes-mirage-firewall folder in this file
>
> https://framabin.org/p/?d9b2b5de724e5c2a#20uFbk/hVlaZnMqHYQ/DXjv9Lav3+Y8Fw7rU05k1IhY=
>
> to avoid sending 260 lines here. If someone has recently build the
> version 0.5, could you run a diff on that to see what happened ? Cheers,
> Bernhard
If you want to check that building without Docker gives exactly the same result
as building with it (which might not be too easy...) you'll need to make sure
that every installed OCaml library has the same version at least.
I'd suggest copying the firewall directory and building the copy with Docker
(be sure to delete the copied _build directory first). Then you can compare
between the two on your own computer.
For example, running "opam list" will show you the local (non-Docker) versions
chosen.
To enter the Docker virtual build environment (after building), do:
$ docker run --rm -it --entrypoint bash qubes-mirage-firewall
That will get you a bash prompt, and you can run "opam list" there to see which
versions the Docker build is using, and compare.
Note that any changes you make within the Docker build environment will be lost
when you exit the shell.
To make sure it always uses the same version, the Docker image contains a Git
clone of the opam repository, which it pins (in Dockerfile) to a particular
commit. That means that the build-with-docker script will always build against
the versions available at that fixed point in time, not the latest ones.
You might also find that Debian packages affect it (e.g. make sure you have the
same version of gcc, as there are a few C source files used too).
If you need to get things in or out of the Docker environment, you can use -v
to share a directory. e.g.
$ docker run --rm -it -v $(pwd):/mnt --entrypoint bash qubes-mirage-firewall
will share the current directory with Docker, mounted at `/mnt` in the virtual
environment.
You might also be interested in the console output from the Travis CI build
(this also lists the versions used):
https://travis-ci.org/mirage/qubes-mirage-firewall/builds/515629873
Hope that helps.
--
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/8e80a54d-a0b4-41cb-969e-01950f6f49a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes-mirage-firewall 0.5
I got a few emails about this. I'm going to answer the questions here because this is a community project and everyone should see the discussion. Q: The build-with-docker script hard-codes /home/opam. What if your user has a different name? The Docker build creates a virtual environment based on the `ocaml/opam2:debian-9-ocaml-4.07` image (template). In this image, the user is always called "opam". Using Docker means that every build is exactly the same, regardless of whether you're using Fedora or Debian as the OS for your Qube. The build script contains the hash of the expected image, so you can be sure the unikernel you built is byte-for-byte identical with the one we built. It also means that you don't have to install any special tools (except Docker itself). The build is isolated from your own files, except that it shares the `_build` directory, which is where you will find the output files. Q: Can I build on Debian without using Docker? Yes. I got it working with this: sudo apt-get update sudo apt-get install rsync pkg-config git gcc make m4 patch unzip bubblewrap curl 0install-core 0install add opam http://tools.ocaml.org/opam.xml opam init --compiler=4.07.1 --disable-sandboxing eval $(opam env) opam install mirage mirage configure -t xen && make depend && make tar Trying to keep these instructions up-to-date wastes a lot of volunteer time however, so I would much prefer people to use the Dockerfile if they have any problems building with their own OS. Q: Why does installing opam without Docker want to modify my .profile? So it can make commands such as `ocaml` point to the ones that it has installed in your home directory. If you're worried about what opam is doing to your system, I suggest using the build-with-docker script to sandbox everything. Q: Do I need some standalone system that docker can 'mess up' and that I delete after build? Feel free to create a `firewall-builder` VM for this if you don't trust Docker to sandbox things correctly in your existing qubes. Q: You have binaries on the github site, but neither checksums nor signatures There is a checksum in the build-with-docker file which should match the binary. In the case of the 0.5 release, you should see: $ sha256sum vmlinuz 1f72adad30cbd4f8315983240bd150811084cb93d360c14740fadb36394c7aa8 vmlinuz Perhaps future releases will come with signatures. Q: Where can I ask questions about this? - You can reply to this thread, where I will see it along with other Qubes users (I know several people here are using it; see previous discussions). - You can file issues at https://github.com/mirage/qubes-mirage-firewall/issues - You can ask on the Mirage mailing list - see https://mirage.io/community/ - To report a security bug, see https://mirage.io/security -- 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/ea8b34c5-20ee-44db-acbe-c59ad22cc57c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes-mirage-firewall 0.5
I'd like to announce the release of qubes-mirage-firewall 0.5: https://github.com/mirage/qubes-mirage-firewall/releases/tag/v0.5 This is a unikernel that can run as a QubesOS ProxyVM, replacing sys-firewall. It may be useful if you want something smaller or faster-to-start than the Linux-based sys-firewall. It requires around 32MB of RAM when running and requires 0.0s of CPU time to boot, according to "xl list". It does not need or use a hard-disk, and does not persist any state between reboots. For installation instructions, see: https://github.com/mirage/qubes-mirage-firewall/blob/master/README.md For a blog post explaining the background for this, with a walk-through of the code (it's written in OCaml), see: http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ Changes since 0.4: - Update to the latest mirage-net-xen, mirage-nat and tcpip libraries (@yomimono, @talex5, #45, #47). In iperf benchmarks between a client VM and sys-net, this more than doubled the reported bandwidth! - Don't wait for the Qubes GUI daemon to connect before attaching client VMs (@talex5, #38). If the firewall is restarted while AppVMs are connected, qubesd tries to reconnect them before starting the GUI agent. However, the firewall was waiting for the GUI agent to connect before handling the connections. This led to a 10s delay on restart for each client VM. Reported by @xaki23. - Add stub makefile for qubes-builder (@xaki23, #37). - Update build instructions for latest Fedora (@talex5, #36). yum no longer exists. Also, show how to create a symlink for /var/lib/docker on build VMs that aren't standalone. Reported by @xaki23. - Add installation instructions for Qubes 4 (@yomimono, @reynir, @talex5, #27). - Use Ethernet_wire.sizeof_ethernet instead of a magic 14 (@hannesm, #46). Note that the repository has moved from github.com/talex5 to the github.com/mirage organisation, as it's no longer just my personal project. -- 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/727d1b86-a37b-4a65-a167-b128a23c8197%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.4
[ replying to list ] On 21 December 2017 at 11:25, donoban <dono...@riseup.net> wrote: > On 12/21/2017 11:13 AM, Thomas Leonard wrote: >> On Wednesday, December 20, 2017 at 9:05:08 PM UTC, donoban wrote: >>> On 12/19/2017 08:05 PM, Thomas Leonard wrote: >>>> I'd like to announce the release of qubes-mirage-firewall 0.4: >>>> >>>> https://github.com/talex5/qubes-mirage-firewall/releases/tag/v0.4 >>>> >>>> This is a unikernel that can run as a QubesOS ProxyVM, replacing >>>> sys-firewall. It may be useful if you want something smaller or >>>> faster-to-start than the Linux-based sys-firewall, are worried about >>>> possible attacks against Linux's C net-front code, or just like playing >>>> with unikernels. >>>> >>> >>> Hi, >>> >>> I am thinking on testing it but I have no idea about unikernels and OCaml. >>> >>> If I'm not wrong you have to configure the rules for the firewall before >>> building the kernel image? Once you start it you have no way for change >>> rules? >> >> Yes. With Qubes 4, it should be possible to update the rules at runtime from >> QubesDB (see https://github.com/talex5/qubes-mirage-firewall/issues/24), but >> that isn't implemented yet. >> >>> I don't know if I will have success with it and use it but thanks for >>> your effort. >> > > Interesting... > > I had no idea about unikerlels, mirageOS nor OCaml. I was pretty > dissapointed because how to configure it was pretty hard to understand > and some tests report more CPU usage than standard sys-firewall. That's quite possible. I only have a regular (fibre) home broadband connection, so speed of the firewall isn't an issue for me. The default build doesn't enable many compiler optimisations. If you need more performance, you could try building with an "flambda" build of the OCaml compiler - that enables a load of extra optimisations. To do that, replace the FROM line in the Dockerfile with: FROM ocaml/opam:debian-9_ocaml-4.05.0_flambda Then delete the "_build" directory and rebuild. > However > I took two hours or more reading your blog, I realized how interesting > the idea is and I went to sleep thinking on how to do mirage-firewall > configurable. > > First I thought on a configuration file but since there is no hard disk > I realized the rules should be on memory. I don't know pretty anything > about OCaml but I thought there should be something similar to arrays > for storing them in memory. Mirage has block drivers available, so you could read from a disk if you want. As Holger Levsen mentioned, there is also a proof-of-concept version that reads JSON rules from the modules.img file. However, it would seem more sensible to make use of the new rules format in Qubes 4 in the longer term. (and yes, OCaml does have arrays) > I was thinking on do some kind of function for passing the rules via > qrexec or directly the xen console. I want to have compatibility with > the current Qubes 3.2 GUI, so I was thinking on doing some parser which > runs on dom0, reads firewall.xml files and passes it to mirage-firewall. > > I work mainly on C# and C++. I wrote Perl and some Python years ago. I > did something on Lisp on the career but I suppose that I don't remember > anything. Maybe OCaml it's pretty hard but I'm decided to try it. OCaml's syntax often confuses people at first, but it's fairly simple after that. I'm fairly sure it's easier to learn than C++ or Perl, anyway! > I've tested Qubes 4, it worked for me but I felt pretty soon for use it > daily so I switched to Qubes 3.2. I would prefer do mirage-firewall > configurable for Qubes 3.2 but easy to add on Qubes 4. > > This is what I have on mind: > > - Some kind of struct/object for store firewall rules in memory > - A func which parses this rules object for a packet > - A func for add/delete/flush rules (called from qrexec or xen console > or qubesdb) > > What do you think? Sounds reasonable. -- talex5 (GitHub/Twitter)http://roscidus.com/blog/ GPG: 5DD5 8D70 899C 454A 966D 6A51 7513 3C8F 94F6 E0CC -- 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/CAG4opy8_v%2BC3U%3DD%2BBjigH%3Dgu%2BuH9XyA2Z0DRYpp%2B3diS6jQaMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qubes-mirage-firewall 0.4
On Wednesday, December 20, 2017 at 9:05:08 PM UTC, donoban wrote: > On 12/19/2017 08:05 PM, Thomas Leonard wrote: > > I'd like to announce the release of qubes-mirage-firewall 0.4: > > > > https://github.com/talex5/qubes-mirage-firewall/releases/tag/v0.4 > > > > This is a unikernel that can run as a QubesOS ProxyVM, replacing > > sys-firewall. It may be useful if you want something smaller or > > faster-to-start than the Linux-based sys-firewall, are worried about > > possible attacks against Linux's C net-front code, or just like playing > > with unikernels. > > > > Hi, > > I am thinking on testing it but I have no idea about unikernels and OCaml. > > If I'm not wrong you have to configure the rules for the firewall before > building the kernel image? Once you start it you have no way for change > rules? Yes. With Qubes 4, it should be possible to update the rules at runtime from QubesDB (see https://github.com/talex5/qubes-mirage-firewall/issues/24), but that isn't implemented yet. > I don't know if I will have success with it and use it but thanks for > your effort. -- 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/90166ff3-11c3-4445-bb29-401e69c8ba63%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qubes-mirage-firewall 0.4
I'd like to announce the release of qubes-mirage-firewall 0.4: https://github.com/talex5/qubes-mirage-firewall/releases/tag/v0.4 This is a unikernel that can run as a QubesOS ProxyVM, replacing sys-firewall. It may be useful if you want something smaller or faster-to-start than the Linux-based sys-firewall, are worried about possible attacks against Linux's C net-front code, or just like playing with unikernels. Changes since 0.3: - Add support for HVM guests (needed for Qubes 4). I don't use Qubes 4 myself yet, but other people have said it works now for them. Note that the firewall itself must still have virt_mode set to 'pv'. - Add support for disposable VMs. - Drop frames if an interface's queue gets too long. - Show (log) the packet when failing to add a NAT rule. The previous message was just: WRN [firewall] Failed to add NAT rewrite rule: Cannot NAT this packet For installation instructions, see: https://github.com/talex5/qubes-mirage-firewall/blob/master/README.md For a blog post explaining the background for this, with a walk-through of the code, see: http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ -- 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/e43821fd-3027-4a02-8839-110959349527%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Question to Mirage OS firewall users
On Thursday, November 9, 2017 at 4:18:13 AM UTC, Jean-Philippe Ouellet wrote: > On Wed, Nov 8, 2017 at 3:09 PM, Thomas Leonard wrote: > > On Thursday, April 13, 2017 at 1:33:53 PM UTC+1, Thomas Leonard wrote: > >> On Thursday, April 13, 2017 at 11:08:11 AM UTC+1, Foppe de Haan wrote: > >> > On Thursday, April 13, 2017 at 10:00:20 AM UTC+2, Thomas Leonard wrote: > >> > > On Wednesday, April 12, 2017 at 10:32:11 PM UTC+1, Foppe de Haan wrote: > >> > > > Any clue why Windows 7 won't boot when I have MirageOS selected as > >> > > > the firewall? > >> > > > >> > > I've never tried it. Do the mirage-firewall logs show anything > >> > > interesting when you try to boot Windows? > >> > > >> > No, but I do have this log (guest-windows-dm). First log doesn't boot > >> > (MirageOS), 2nd does (sys-firewall). Is that of any use? > >> > >> Oh, that's more useful than I was expecting! Looks like the Windows boot > >> process starts by running MiniOS! It's hanging at > >> > >> close network: backend at /local/domain/4/backend/vif/79/0 > >> > >> I guess it asked the firewall to close the network, and never got a reply > >> (because the firewall doesn't have any code to do that). > > > > OK, I finally got some time to look into this. I think this patch should > > fix it (works for Linux HVM anyway): > > > > https://github.com/mirage/mirage-net-xen/pull/67 > > > > I also made a patch that seems to let the firewall work with disposable VMs: > > > > https://github.com/mirage/mirage-net-xen/pull/68 > > Sweet :) > > > Both are based on guesswork though - is the Xen netback protocol documented > > somewhere? > > In xen src: > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/netif.h;hb=refs/heads/master > > netfront / netback in linux: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netfront.c > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/xen-netback > > And a somewhat outdated but much more approachable introduction in > section 9.2 (starting p.169) of "The Definitive Guide to the Xen > Hypervisor" book in case you have access to it. Thanks. Is there anything about the setup protocol, though? This file seems less well commented: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/xenbus.h;h=927f9db5528798fca00455fdd687662d68b18b2e;hb=refs/heads/master BTW, I've updated the Dockerfile to build with the patches applied now, if anyone wants to test it: https://github.com/talex5/qubes-mirage-firewall/ I've had one report from a Qubes 4.0rc1 user that it now works for them (for HVM Linux). -- 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/e4a1ff93-2c9f-470b-b2da-0cc69f79ba3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Wednesday, April 12, 2017 at 10:32:11 PM UTC+1, Foppe de Haan wrote: > Any clue why Windows 7 won't boot when I have MirageOS selected as the > firewall? I've never tried it. Do the mirage-firewall logs show anything interesting when you try to boot Windows? -- 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/e36e3c71-1c55-41e6-98d4-ad4731809857%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Sunday, March 19, 2017 at 10:11:04 AM UTC, Foppe de Haan wrote: > Stable so far. (Current uptime 12h, it crashed well before that when it > wasn't.) Thanks for testing! I've made a new release of that version now (identical binary): https://github.com/talex5/qubes-mirage-firewall/releases/tag/v0.3 -- 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/8431f68e-7f19-4e5b-9fca-79bf1205d394%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Friday, February 24, 2017 at 1:16:55 PM UTC, Foppe de Haan wrote: > On Tuesday, February 7, 2017 at 6:22:53 PM UTC+1, Thomas Leonard wrote: > > On Tuesday, February 7, 2017 at 4:51:06 PM UTC, Foppe de Haan wrote: > > > On Tuesday, February 7, 2017 at 5:24:58 PM UTC+1, Thomas Leonard wrote: > > > > On Tuesday, February 7, 2017 at 3:55:30 PM UTC, Foppe de Haan wrote: > > > > > Anyone else tried to use MirageOS i.c.w. a torrent client? I've > > > > > allocated 60mb ram, but it crashes within 2-8 hours here, which is > > > > > kind of disappointing. > > > > > > > > Do the logs show an out-of-memory error when that happens? I haven't > > > > seen one for a long time now, but maybe torrents stress it more than > > > > usual. > > > > > > > > If so, it could be https://github.com/yomimono/mirage-nat/issues/17 - > > > > there's a Mirage hackathon next month and I'm hoping to get some time > > > > to work on this there. > > > > > > Yes. "Fatal error: out or memory. Mirage exiting with status 2" > > > > By the way, what version of the firewall are you using? > > If it's not qubes-mirage-firewall v0.2 then try upgrading first - there > > were lots of OOM problems in v0.1. > > > > > That said, 2 minutes earlier the log notes that memory use was still only > > > at 16.7/38.2 MB. > > > > The annoying thing about hashtables is the way they suddenly double in > > size. Since you're allocating 60 MB to the firewall (I only use 20 MB for > > mine), you could try adjusting the thresholds at these two lines: > > > > https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L41 > > https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L47 > > > > Change the 0.9 (allow 90% of memory to be used) to 0.4 in both places. If > > the NAT table is the cause, that should make the problem go away. > > > > > (Most of the log -- 90-95% -- consists of 'Failed to parse frame' > > > messages, btw.) > > > > "Failed to parse frame" probably means it saw an ICMP (not TCP or UDP) > > packet and therefore didn't handle it. Another thing I'm hoping to fix > > soon... https://github.com/yomimono/mirage-nat/issues/15 > > It looks stable now (uptime 3-4 days since last reboot, whereas before it > only lasted ~8h max). Thanks for the report! I've now made some updates to the firewall: - It now uses an LRU-cache to drop old entries, rather than growing until it runs out of memory. - ICMP queries (e.g. ping) and errors (e.g. Host unreachable) now work (they were dropped before). - I've ported it to the new Mirage 3 release. There are quite a lot of changes, so I'd be happy to get reports about whether it works or not (I've just started running the new version on my laptop). -- 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/61f88c78-9442-435a-bed6-5f63e033bb6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Question to Mirage OS firewall users
On Wednesday, February 8, 2017 at 4:59:16 PM UTC, Jean-Philippe Ouellet wrote: > On Sat, Jan 28, 2017 at 9:13 AM, Thomas Leonard wrote: > > I'm not sure why my DispVM is Fedora 23 when my default template is Fedora > > 24, but anyway... > > If fedora24 is indeed your default template, try: > [user@dom0 ~]$ qvm-create-default-dvm --default-template That fixed it - thanks! -- 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/028ab6db-c5e7-4d72-9224-64c2a08d3500%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Tuesday, February 7, 2017 at 5:31:25 PM UTC, Foppe de Haan wrote: > On Tuesday, February 7, 2017 at 6:22:53 PM UTC+1, Thomas Leonard wrote: > > On Tuesday, February 7, 2017 at 4:51:06 PM UTC, Foppe de Haan wrote: > > > On Tuesday, February 7, 2017 at 5:24:58 PM UTC+1, Thomas Leonard wrote: > > > > On Tuesday, February 7, 2017 at 3:55:30 PM UTC, Foppe de Haan wrote: > > > > > Anyone else tried to use MirageOS i.c.w. a torrent client? I've > > > > > allocated 60mb ram, but it crashes within 2-8 hours here, which is > > > > > kind of disappointing. > > > > > > > > Do the logs show an out-of-memory error when that happens? I haven't > > > > seen one for a long time now, but maybe torrents stress it more than > > > > usual. > > > > > > > > If so, it could be https://github.com/yomimono/mirage-nat/issues/17 - > > > > there's a Mirage hackathon next month and I'm hoping to get some time > > > > to work on this there. > > > > > > Yes. "Fatal error: out or memory. Mirage exiting with status 2" > > > > By the way, what version of the firewall are you using? > > If it's not qubes-mirage-firewall v0.2 then try upgrading first - there > > were lots of OOM problems in v0.1. > > > > > That said, 2 minutes earlier the log notes that memory use was still only > > > at 16.7/38.2 MB. > > > > The annoying thing about hashtables is the way they suddenly double in > > size. Since you're allocating 60 MB to the firewall (I only use 20 MB for > > mine), you could try adjusting the thresholds at these two lines: > > > > https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L41 > > https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L47 > > > > Change the 0.9 (allow 90% of memory to be used) to 0.4 in both places. If > > the NAT table is the cause, that should make the problem go away. > > > > > (Most of the log -- 90-95% -- consists of 'Failed to parse frame' > > > messages, btw.) > > > > "Failed to parse frame" probably means it saw an ICMP (not TCP or UDP) > > packet and therefore didn't handle it. Another thing I'm hoping to fix > > soon... https://github.com/yomimono/mirage-nat/issues/15 > > I built it using docker about 2 days ago. Will do the other things you > mentioned, report back when I know more :) Thanks! If that is the cause of the memory problem, it should be easy to fix anyway. -- 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/74503e3d-1fe3-4649-8a8d-fe2051adee64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Tuesday, February 7, 2017 at 4:51:06 PM UTC, Foppe de Haan wrote: > On Tuesday, February 7, 2017 at 5:24:58 PM UTC+1, Thomas Leonard wrote: > > On Tuesday, February 7, 2017 at 3:55:30 PM UTC, Foppe de Haan wrote: > > > Anyone else tried to use MirageOS i.c.w. a torrent client? I've allocated > > > 60mb ram, but it crashes within 2-8 hours here, which is kind of > > > disappointing. > > > > Do the logs show an out-of-memory error when that happens? I haven't seen > > one for a long time now, but maybe torrents stress it more than usual. > > > > If so, it could be https://github.com/yomimono/mirage-nat/issues/17 - > > there's a Mirage hackathon next month and I'm hoping to get some time to > > work on this there. > > Yes. "Fatal error: out or memory. Mirage exiting with status 2" By the way, what version of the firewall are you using? If it's not qubes-mirage-firewall v0.2 then try upgrading first - there were lots of OOM problems in v0.1. > That said, 2 minutes earlier the log notes that memory use was still only at > 16.7/38.2 MB. The annoying thing about hashtables is the way they suddenly double in size. Since you're allocating 60 MB to the firewall (I only use 20 MB for mine), you could try adjusting the thresholds at these two lines: https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L41 https://github.com/talex5/qubes-mirage-firewall/blob/master/memory_pressure.ml#L47 Change the 0.9 (allow 90% of memory to be used) to 0.4 in both places. If the NAT table is the cause, that should make the problem go away. > (Most of the log -- 90-95% -- consists of 'Failed to parse frame' messages, > btw.) "Failed to parse frame" probably means it saw an ICMP (not TCP or UDP) packet and therefore didn't handle it. Another thing I'm hoping to fix soon... https://github.com/yomimono/mirage-nat/issues/15 -- 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/2d9792a2-f1b4-41c8-9ded-7da8e5891122%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Tuesday, February 7, 2017 at 3:55:30 PM UTC, Foppe de Haan wrote: > Anyone else tried to use MirageOS i.c.w. a torrent client? I've allocated > 60mb ram, but it crashes within 2-8 hours here, which is kind of > disappointing. Do the logs show an out-of-memory error when that happens? I haven't seen one for a long time now, but maybe torrents stress it more than usual. If so, it could be https://github.com/yomimono/mirage-nat/issues/17 - there's a Mirage hackathon next month and I'm hoping to get some time to work on this there. -- 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/6f6a43d9-e479-4ea6-bd23-233f13d9b4b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Saturday, December 10, 2016 at 5:36:29 PM UTC, Reg Tiangha wrote: > On Saturday, December 10, 2016 at 6:03:17 AM UTC-7, jkitt wrote: > > What's it like to update - is it relatively simple? Would you say it's more > > secure than Debian or Fedora? > > It's easy. Shut down your Mirage OS Firewall VMs, copy over the new kernel > files to the relevant directory in /var/lib/qubes/vm-kernels in dom0, and > then restart the Mirage firewalls. > [...] > Note that if you're trying to compile the latest mirage firewall code from > github (which isn't reflected on the Release pages yet; there have been some > minor changes since the last one), it might be a bit tricky since if you > follow the default github instructions, the compilation will eventually fail > as mirage-nat tries to pull in older versions of its package dependencies by > default. It seems to work for me. To make things more predictable, I've added a script to build it with Docker: sudo yum install docker sudo systemctl start docker git clone https://github.com/talex5/qubes-mirage-firewall.git cd qubes-mirage-firewall sudo ./build-with-docker.sh The Dockerfile uses a fixed version of opam-repository, so it shouldn't break even if something gets updated. It also prints out the sha256sum of the binary it built and the expected hash (hard-coded in the file), e.g. $ sudo ./build-with-docker.sh [...] SHA2 of build: f0c1a06fc4b02b494c81972dc89419af6cffa73b75839c0e8ee3798d77bf69b3 mir-qubes-firewall.xen SHA2 last known: f0c1a06fc4b02b494c81972dc89419af6cffa73b75839c0e8ee3798d77bf69b3 I'd be interested to know if other people get the same hash (of course, the hash will change if you e.g. modify the rules.ml file to change the policy). -- 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/1c6a4c3d-b03d-4528-8996-eed684ac8eb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Question to Mirage OS firewall users
On Thursday, January 19, 2017 at 12:07:17 AM UTC, Reg Tiangha wrote: > On 2017-01-18 7:30 AM, Антон Чехов wrote: > > Hi! > > > > Is anyone using the mirage firewall in connection with a proxyVM? How do > > you configure it properly? Does it handle qubes-firewall-users-scripts? > > > > I've run a Mirage-based firewall both in front of and behind a > firewallVM and they chain together fine. Mirage Firewall in its current > iteration does *not* respect modifications to firewall rules via Qubes > and has to be inputted manually (there are some instructions on how to > do that on the software author's blog). It isn't to say that Mirage > Firewall couldn't do it one day, but I believe the author of the code is > leaving it up as an exercise for the reader. Maybe he'll get around to > implementing it, or maybe not, but from a purely technical standpoint, > there's no reason why it couldn't be modified to work with Qubes > firewall user scripts, it's just that it hasn't been implemented yet. > > Note that even if you're running the latest code off of GitHub, > currently, Mirage Firewall still doesn't work correctly with DispVMs (or > at least, I haven't been able to get it to work; the DispVM connects to > it, but there's no traffic), even though there were some minimal fixes > applied to try to handle how it handles IP addresses from a different > pool. Works fine with AppVMs, though, as well as TemplateVMs, at least > in my experience. It works for me if I take the interface down and bring it up again in the dispVM, e.g. [user@fedora-23-dvm ~]$ sudo ifconfig eth0 down && sudo ifconfig eth0 up [user@fedora-23-dvm ~]$ sudo route add $(qubesdb-read /qubes-gateway) dev eth0 [user@fedora-23-dvm ~]$ sudo route add default gw $(qubesdb-read /qubes-gateway) [user@fedora-23-dvm ~]$ curl http://www.google.com 302 Moved 302 Moved The document has moved http://www.google.co.uk/?gfe_rd=crei=vKSMWOn7F6vP8Aeg4KeoAQ;>here. The odd thing is that, as far as I can see, reinitialising the interface is something that only affects Linux (no interaction with the firewall). (and I'm not sure why my DispVM is Fedora 23 when my default template is Fedora 24, but anyway...) -- 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/b4e74710-c3c2-4e36-a304-577974e736d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
