Rudd-O's Network Server supports PVM. It needs to support HVM

[tlaurion]

Qubes OS version:

R3.2, R4.0

Affected TemplateVMs:

---

Steps to reproduce the behavior:

Only PVM is supported

Expected behavior:

HVM support is needed

Actual behavior:

General notes:

---

Related issues:

Rudd-O/qubes-network-server#4

[andrewdavidwong]

FYI @Rudd-O.

[andrewdavidwong]

FYI @Rudd-O.

[tlaurion]

From : https://groups.google.com/forum/m/#!msg/qubes-users/sNjucuuiCcQ/UyNAnHKjAAAJ

Thank you for opening the ticket. It may be difficult for me to adapt
to 4.0, so I kindly request anyone with the required skillset to send a
pull request adapting it to 4.0.

--
Rudd-O
http://rudd-o.com/

[tlaurion]

From : https://groups.google.com/forum/m/#!msg/qubes-users/sNjucuuiCcQ/UyNAnHKjAAAJ

Thank you for opening the ticket. It may be difficult for me to adapt
to 4.0, so I kindly request anyone with the required skillset to send a
pull request adapting it to 4.0.

--
Rudd-O
http://rudd-o.com/

[tlaurion]

@jpouellet @andrewdavidwong @marmarek @Rudd-O

What part changed in Qubes so that the theory of application is invalid in Qubes4 and HVM?

Theory of operation
Qubes OS relies on layer 3 (IP) routing. VMs in its networked tree send traffic through their default route interfaces, which upstream VMs receive and masquerade out of their own default route interfaces.

Qubes network server slightly changes this when a networked VM — a VM which has had its static_ip attribute set with qvm-static-ip — exists on the networked tree. As soon as a networked VM boots up, Qubes network server:

sets a static /32 route on every upstream VM to the networked VM's static IP, directing the upstream VMs to route traffic for that IP to their VIFs where they may find the networked VM
enables ARP neighbor proxying for the static IP on every upstream VM, such that every upstream VM announces itself to their own upstream VMs (and LAN, in the case of NetVMs) as the networked VM
sets firewall rules on every upstream VM that allow normal non-masquerading forwarding to and from the IP of the networked VM
(depending on the Qubes firewall policy of the networked VM) sets rules on every upstream ProxyVM that allow for certain classes of inbound traffic
(depending on the Qubes firewall policy of the networked VM) sets rules directly on the networked VM that allow for certain classes of inbound traffic

[tlaurion]

@jpouellet @andrewdavidwong @marmarek @Rudd-O

What part changed in Qubes so that the theory of application is invalid in Qubes4 and HVM?

Theory of operation
Qubes OS relies on layer 3 (IP) routing. VMs in its networked tree send traffic through their default route interfaces, which upstream VMs receive and masquerade out of their own default route interfaces.

Qubes network server slightly changes this when a networked VM — a VM which has had its static_ip attribute set with qvm-static-ip — exists on the networked tree. As soon as a networked VM boots up, Qubes network server:

sets a static /32 route on every upstream VM to the networked VM's static IP, directing the upstream VMs to route traffic for that IP to their VIFs where they may find the networked VM
enables ARP neighbor proxying for the static IP on every upstream VM, such that every upstream VM announces itself to their own upstream VMs (and LAN, in the case of NetVMs) as the networked VM
sets firewall rules on every upstream VM that allow normal non-masquerading forwarding to and from the IP of the networked VM
(depending on the Qubes firewall policy of the networked VM) sets rules on every upstream ProxyVM that allow for certain classes of inbound traffic
(depending on the Qubes firewall policy of the networked VM) sets rules directly on the networked VM that allow for certain classes of inbound traffic

[tlaurion]

@marmarek @Rudd-O @andrewdavidwong @jpouellet @lamuse: Any documentation pointing to how to recreate a proper development environment to develop tools destined for dom0? I can't believe that the only solution in porting to the new qubesadmin api is to repackage and deploy!?

[tlaurion]

@marmarek @Rudd-O @andrewdavidwong @jpouellet @lamuse: Any documentation pointing to how to recreate a proper development environment to develop tools destined for dom0? I can't believe that the only solution in porting to the new qubesadmin api is to repackage and deploy!?

[tlaurion]

Found it.

https://www.qubes-os.org/doc/development-workflow/

[tlaurion]

Found it.

https://www.qubes-os.org/doc/development-workflow/