-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, Mar 12, 2018 at 07:21:51PM -0700, Tom Carroll wrote: > Hello Qubes devs, > > I'm working on a project where I don't want the AppVM to be masqueraded as > the sys-firewall from the perspective of sys-net (I desire to see the ip > address of the appvm). This is necessary for my application, as I desire > sys-net to perform per-appvm task, such as (as an example) modifying the > DSCP code point. > > In summary (the short version), a ping initiated within the sys-firewall > will route onto the network (as observed from tcpdump on the pif in > sys-net), but a ping initiated in the appvm will not (I see appvm traffic on > the vif in sys-net, but not on the pif). > > Here's greater detail. I remove the general MASQUERADE rule from > sys-firewall and clear the raw table in sys-net and sys-firewall. To be > comprehensive, I change the default chain policies to ACCEPT and remove any > drop-all rules. Then, I modify the routes in sys-net, to forward the appvm > back into the sys-firewall. > > When I ping an external IP (say gateway) from the appvm, the packets can be > observed on the vif, put not the pif. If I do the same on the sys-firewall, > I observe traffic both on the vif and pif and at the end device. > > To further support diagnosis, I changed the ip addresses to /31 on the vif > between sys-net and sys-fireall, updating the routes where necessary. > Furthermore, I disabled proxy_arp on the vif in sys-net as this should be > the case of conventional routing. Moreover, I also disabled rp_filter at all > location. Even with these changes, I observe the same behavior in that the > sys-firewall will route out, but the appvm stops at the sys-net. > > Does anyone have insight why this doesn't work? I would assume this to be > straightforward routing. > > I appreciate your help. Thanks in advance.
Make sure you've added appropriate routes for returning packets - for example in sys-net a route to appvm via sys-firewall. Without this, you'll have two problems: 1. Returning packets will be dropped because of lack of route back to the source 2. Outgoing packets will be dropped by reverse path filter (/proc/sys/net/ipv4/conf/all/rp_filter), because it looks like IP spoofing from sys-net perspective. If you're using R4.0, check also nftables, see here: https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world Generally, without MASQUERADE, each node of the network tree needs to know routes to _every_ node in the subtree - not only those directly connected. In your case it might be ok, but in general case it gets even more complicated because you may want some exceptions (Proxy VMs that tunnel the traffic using VPN of some kind, including Tor). And switching netvm require route changes in multiple places. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqhI/sACgkQ24/THMrX 1yxbaAgAibEV4Gevei0p80zgdfY0/pH24Inm0+IrUCHi56fT7MnKM/Caj9ip1FrI 3VGGBrszlOpMP7iTaMos7Jsach0dCSmtLb9R0jtkbuMt5Tm3QgBQIVyqiUViLBUP b0yWdx2IOXgiof9KnMAuI7RXr4t/3I5AGTJuPaSsFIpNB5z3F5JvOi/G8G3KSNz+ U50Ewa9NNOKTxMO27G1PFWSUC9tMZdXEIVk8/ZCVTPaltFeoIlavNzb4SrmmiT/I OsysT6QjNlN1tncw5v/JTeIFqSVlCs6srCVU63Jm8oFpCwE14SqiOV+b7XoYr5rF XIEYet9Mz+1l/FQXBRtMeupGugZz1A== =s7tZ -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180313094142.GU7364%40mail-itl. For more options, visit https://groups.google.com/d/optout.
