[pve-devel] nftables 0.4 and kernel 3.19, still problem with physdevin|out

Alexandre DERUMIER aderumier at odiso.com
Mon Jul 27 15:22:06 CEST 2015


>>Yes I think you can match almost everything in pretty much every table. 
>>Provided they have implemented it ;-) so we'll have to wait for ct to 
>>land in bridge tables before considering switching to nft. 
Yes, we should wait.
Currently I'm just testing it, time to time, to see how it's evolving.)

>>Or does nft provide any other advantage already that would be worth the 
>>effort? 
The vmap feature is really the big change for me. 
(No need to test each tap chain, that make a big difference with a lot of vms)


Also, I'm not sure that all nat/masquerade features are already implemented.




Here a working test : (don't known why, but if need to user oifname && iifname, obriport && ibriport not working)


nft list ruleset
nft flush table bridge filter
nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 200 \; }
nft add chain bridge filter input { type filter hook input priority 200 \; } 
nft add chain bridge filter output { type filter hook output priority 200 \; }  
nft add chain bridge filter tap150i0-OUT
nft add chain bridge filter tap150i1-OUT
nft add chain bridge filter tap150i0-IN
nft add chain bridge filter tap150i1-IN
nft add rule bridge filter forward meta oifname vmap { tap150i0: jump tap150i0-OUT,  tap150i1: jump tap150i1-OUT }
nft add rule bridge filter forward meta iifname vmap { tap150i0: jump tap150i0-IN,  tap150i1: jump tap150i1-IN }
nft add rule bridge filter tap150i0-OUT log prefix \"tap150i0-OUT: \" accept
nft add rule bridge filter tap150i0-IN log prefix \"tap150i0-IN: \" accept
nft add rule bridge filter tap150i1-OUT log prefix \"tap150i1-OUT: \" accept
nft add rule bridge filter tap150i1-IN log prefix \"tap150i1-IN: \" accept
nft add rule bridge filter tap150i0-IN ether type ip tcp dport 80 drop



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 27 Juillet 2015 15:11:18
Objet: Re: [pve-devel] nftables 0.4 and kernel 3.19, still problem with physdevin|out

On Mon, Jul 27, 2015 at 03:01:30PM +0200, Alexandre DERUMIER wrote: 
> Oh, I speak too fast, 
> seem that for tcp traffic in bridge chain, I can see PROTO and port. 
> 
> forward: IN=tap150i0 OUT=fwln150i0 MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240 DST=192.168.100.76 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=42868 DF PROTO=TCP SPT=22 DPT=49876 WINDOW=291 RES=0x00 ACK PSH URGP=0 MARK=0x7b 
> 
> So, it's really only missing conntrack here. 

Yes I think you can match almost everything in pretty much every table. 
Provided they have implemented it ;-) so we'll have to wait for ct to 
land in bridge tables before considering switching to nft. 
Or does nft provide any other advantage already that would be worth the 
effort? 



More information about the pve-devel mailing list