[OpenWrt-Devel] MT7621 and bridge firewalling
Etienne Champetier
champetier.etienne at gmail.com
Sun Apr 26 16:43:52 EDT 2020
Le dim. 26 avr. 2020 à 10:57, Etienne Champetier
<champetier.etienne at gmail.com> a écrit :
>
> Hi All,
>
> Le sam. 11 avr. 2020 à 12:48, Etienne Champetier
> <champetier.etienne at gmail.com> a écrit :
> >
> > Hello OpenWrt hackers,
> >
> > I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and
> > would like to do hardware accelerated statefull bridge firewalling. My
> > end goal is to learn and make PhanTap
> > (https://github.com/nccgroup/phantap) work at line rate.
> >
> > MT7621 supports flow offload, so the high level idea would be to:
> > - create a linux bridge with 2 ports (say lan4/lan5)
> > - disable normal switch offload (do not forward just based on mac
> > dest) and have the packets go through netfilter
>
> Big thanks to Qingfang for the tip, for this part I just disabled MAC leaning
>
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -1319,6 +1319,9 @@ mt7530_setup(struct dsa_switch *ds)
> /* Enable consistent egress tag */
> mt7530_rmw(priv, MT7530_PVC_P(i), PVC_EG_TAG_MASK,
> PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
> +
> + /* hack */
> + mt7530_set(priv, MT7530_PSC_P(i), SA_DIS);
> }
>
> /* Setup port 5 */
>
> > - have netfilter create/install flow offload rules for most
> > connections like we do for the routing case.
Just trying to have software flow offloading for bridge working on
RB750Gr3 (Linux 5.4)
sysctl -w net.bridge.bridge-nf-call-iptables=1
In iptables I see the FLOWOFFLOAD rule
# iptables-save
...
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain"
-j forwarding_rule
-A FORWARD -m comment --comment "!fw3: Traffic offloading" -m
conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
...
In conntrack I see [OFFLOAD] connections
# cat /proc/net/nf_conntrack
ipv4 2 tcp 6 src=192.168.1.2 dst=192.168.1.15 sport=56018
dport=22 packets=29858 bytes=1609629 src=192.168.1.15 dst=192.168.1.2
sport=22 dport=56018 packets=57155 bytes=20636422 [OFFLOAD] mark=0
zone=0 use=3
But if I add an iptables LOG rule
# iptables -A forwarding_rule -j LOG --log-prefix "ipt forward: " --log-level 4
# logread -f
...
Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.430466] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=lan5 PHYSOUT=lan2
MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15
DST=192.168.1.2 LEN=148 TOS=0x10 PREC=0x00 TTL=64 ID=57031 DF
PROTO=TCP SPT=22 DPT=56018 WINDOW=2687 RES=0x00 ACK PSH URGP=0
Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.454055] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=lan2 PHYSOUT=lan5
MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2
DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=40139 DF
PROTO=TCP SPT=56018 DPT=22 WINDOW=1316 RES=0x00 ACK URGP=0
...
Same test with 2 separate interfaces (GL-AR150 / Linux 4.19):
# logread -f
Sat Apr 25 22:04:40 2020 kern.warn kernel: [ 968.671777] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=eth1 PHYSOUT=eth0
MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15
DST=192.168.1.2 LEN=116 TOS=0x10 PREC=0x00 TTL=64 ID=48741 DF
PROTO=TCP SPT=22 DPT=58094 WINDOW=2165 RES=0x00 ACK PSH URGP=0
Sat Apr 25 22:04:40 2020 kern.warn kernel: [ 968.698088] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=eth0 PHYSOUT=eth1
MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2
DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=31502 DF
PROTO=TCP SPT=58094 DPT=22 WINDOW=83 RES=0x00 ACK URGP=0
# grep 192.168.1.15 /proc/net/nf_conntrack
ipv4 2 tcp 6 src=192.168.1.2 dst=192.168.1.15 sport=58094
dport=22 packets=461 bytes=40449 src=192.168.1.15 dst=192.168.1.2
sport=22 dport=58094 packets=252 bytes=35034 [OFFLOAD] mark=0 zone=0
use=3
So software flow offload seems broken with bridge :(
(I'll do some more tests with classic distros and latest Linux version)
> > - enjoy
> >
> > My questions are:
> > - will the hardware let me do that (any restrictions on the flow
> > offload rules or ...) ?
> > - is it already possible with OpenWrt master (I was not able to have a
> > bridge without offload yet) ?
> > - any pointer to ongoing work in that area (while writing this email I
> > just found NF_CONNTRACK_BRIDGE)
> >
> > Thanks
> > Etienne
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list