How to enable Xen VM traffic using nft

How to enable Xen VM traffic using nft

[Leonardo Bruno]

Hi guys.

I am running Xen 4.8.1 and Debian 9 'stretch' as Dom0. I am also
using  
'nft' instead of 'iptables' as Debian is now encouraging the users to  
do.

The 'xen-scripts' shipped with Debian Xen packages add rules to
permit  
(accept) packages to/from virtual interfaces to flow in/out through  
the bridge interface.

But these scripts are not 'nft-ready' and, although it is simple to  
modify it in order to run the correct 'nft' commands, I could not  
translate the original 'iptables' rules to 'nftables' rules.

The 'iptables' commands executed when the VM is started (supposing a  
virtual interface 'vif0') are:

iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in vif0  
-j ACCEPT
iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
vif0  
-j ACCEPT

Almost the same commands are executed when the VM is shutted down:

iptables -D FORWARD -m physdev --physdev-is-bridged --physdev-in vif0  
-j ACCEPT
iptables -D FORWARD -m physdev --physdev-is-bridged --physdev-out
vif0  
-j ACCEPT

Can someone help? Thanks in advance.

Best regards,
Leonardo Lopes

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.

[Fwd: How to enable Xen VM traffic using nft]

[Leonardo Bruno]

Hi guys.

Any clue on this subject?

Hope someone can help.

Leonardo Lopes

-------- Mensagem encaminhada --------
De: Leonardo Bruno <leonardo@cefetmg.br>
Para: netfilter@vger.kernel.org
Assunto: How to enable Xen VM traffic using nft
Data: Fri, 27 Oct 2017 18:55:41 -0200

> Hi guys.
> 
> I am running Xen 4.8.1 and Debian 9 'stretch' as Dom0. I am also
> using  
> 'nft' instead of 'iptables' as Debian is now encouraging the users
> to  
> do.
> 
> The 'xen-scripts' shipped with Debian Xen packages add rules to
> permit  
> (accept) packages to/from virtual interfaces to flow in/out through  
> the bridge interface.
> 
> But these scripts are not 'nft-ready' and, although it is simple to  
> modify it in order to run the correct 'nft' commands, I could not  
> translate the original 'iptables' rules to 'nftables' rules.
> 
> The 'iptables' commands executed when the VM is started (supposing
> a  
> virtual interface 'vif0') are:
> 
> iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in
> vif0  
> -j ACCEPT
> iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
> vif0  
> -j ACCEPT
> 
> Almost the same commands are executed when the VM is shutted down:
> 
> iptables -D FORWARD -m physdev --physdev-is-bridged --physdev-in
> vif0  
> -j ACCEPT
> iptables -D FORWARD -m physdev --physdev-is-bridged --physdev-out
> vif0  
> -j ACCEPT
> 
> Can someone help? Thanks in advance.
> 
> Best regards,
> Leonardo Lopes

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.

Re: [Fwd: How to enable Xen VM traffic using nft]

[Arturo Borrero Gonzalez]

On 8 November 2017 at 23:15, Leonardo Bruno <leonardo@cefetmg.br> wrote:
> Hi guys.
>
> Any clue on this subject?
>
> Hope someone can help.
>

Try using nftables in the bridge family.

I see we lack some information here so I added a new wiki page:

https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families

Re: [Fwd: How to enable Xen VM traffic using nft]

[Pablo Neira Ayuso]

On Thu, Nov 09, 2017 at 12:51:44PM +0100, Arturo Borrero Gonzalez wrote:
> On 8 November 2017 at 23:15, Leonardo Bruno <leonardo@cefetmg.br> wrote:
> > Hi guys.
> >
> > Any clue on this subject?
> >
> > Hope someone can help.
> >
> 
> Try using nftables in the bridge family.
> 
> I see we lack some information here so I added a new wiki page:
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families

There is no physdev support for nftables. Florian has been looking
into native conntrack replacement for bridge that should help us
obsolete the br_netfilter module.

Re: [Fwd: How to enable Xen VM traffic using nft]

[Leonardo Bruno]

Em qui, 2017-11-09 às 12:51 +0100, Arturo Borrero Gonzalez escreveu:
> On 8 November 2017 at 23:15, Leonardo Bruno <leonardo@cefetmg.br>
> wrote:
> > Hi guys.
> > 
> > Any clue on this subject?
> > 
> > Hope someone can help.
> > 
> 
> Try using nftables in the bridge family.
> 
> I see we lack some information here so I added a new wiki page:
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Thank you guys.

I am a little frustrated. I can not match the virtual bridged interface
in any way either using bridge or inet families.

To make myself more clear, I used to configure iptables default chain
policies as 'drop' and then added the exceptions. So considering you
have a virtual interface vif0 bridged 'under' bridge br0, all you have
to do is to accept packages going in and out through vif0 using the
chain FORWARD of table filter.

So all my tries were guided by this objective: to match the virtual
interface and accept the packages. First I used the chains in
inet/filter table, and so I did the same using bridge/filter table

I tried rules like:

table inet tb_filter {
	chain ch_forward {
		type filter hook forward priority 0; policy drop;
		iifname "vif3.0" log prefix "VIF3_FW_IN_" accept
		oifname "vif3.0" log prefix "VIF3_FW_OUT_" accept
	}

	chain ch_input {
		type filter hook input priority 0; policy drop;
		iifname "vif3.0" log prefix "VIF3_IN_" accept
	}

	chain ch_output {
		type filter hook output priority 0; policy drop;
		oifname "vif3.0" log prefix "VIF3_OUT_"  accept
	}
}

I watched syslog to see which rule really matches, but I could only see
broadcast/multicast packages. Sometimes I could see that a rule
matches, but when I switched the chain default policy to drop, it
didn't work.

I tried similar rules using bridge family and prerouting/postrouting
chains and nothing.

Maybe you can spot what I am missing. Thank you so much.

Regards,
Leonardo Lopes

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.