openwrt
Fw4 not working with VLAN (802.1q) after installing dockerd
Describe the bug
I'v created a few vlans with DSA, firewall is working fine as expected, after installed dockerd, it's not working, with the vlan the package actually come from the actual device, not the vlan bridge, thus the firewall is not working, with the defualt global forward not set to accept, the lan client can't ping to each other eventhough the lan zone has set forward to accept. the cause is that it's not treat the package from the vlan rather from an actual device.
OpenWrt version
r23497-6637af95aa
OpenWrt release
23.05.0
OpenWrt target/subtarget
mediatek/mt7622
Device
Linksys E8450 (UBI)
Image kind
Official downloaded image
Steps to reproduce
With everthing default, create few vlans, set all vlans forward to accept, but global as default reject, vlans internal client can ping right now, install dockerd, then test it again, firewall no working as expect for the vlans.
Actual behaviour
vlans firewall work as before not installing dockerd
Expected behaviour
vlans firewall are as before without dockerd.
Additional info
firewall not treat vlans as vlans, the package actually come from a device. makes it not working without allow global forward, not even with layer 2 communications.
Diffconfig
No response
Terms
- [X] I am reporting an issue for OpenWrt, not an unsupported fork.
Attach:
nft list ruleset
fw4 print
/etc/config/firewall
/etc/config/network
iptables-nft-save
iptables-legacy-save (ideally empty or better not installed)
You should clear out mid parts of MAC addresses and public IPs.
The zone forward is something else, bridge forward filtering is possible but out of context of fw4.
I don't have any special firewall setup, just the default, and the added some vlans, all the client in the vlan can ping each other, after installing docker, it's not working, I think it has something with iptables as docker depends on this.
Can you help with info:
- the "some vlans" as list (i can dig that from config files too)
- the ruleset and the stuff added by iptables-nft from 1st commands
- assurance iptables-legacy is NOT mixed in.
I don't have other rules that's reject or drop, all are accept, everything is default, The client within vlan can't ping to each other, without installing docker, everything is ok. if I set global forward to accept it back to normal, but every vlan can ping each other, I used nft monitor to keep track of trafic, the iiface is like wl1-ap3 is not the br-lan.12 which cause the firewall zone rule not take effect.
It's very easy to replicate the issue, with everything deafult, create some vlans test vlan clients ping, it's ok, now install dockerd, it broke, it's not working, what's working is that if the interface is still bridge, then it's fine, firewall will hornor the config, but if it's vlan with DSA, it borke you can't ping with the lan. it's basically the zone firewall not taking effect, because aforementioned input interface is not comming from the br-lan.12, it's actually comming from the wifi device like wl1-ap3.
You should not use vlan1 with DSA. nor legacy iptables. At present default-forward-drop just drops any nat or masq packet mangled by other tables. nor ever add wifi interface to a bridge port. hostapd does it by itself. Once all misconfigurations above are addressed feel free to install docker again. It is imperative to attach text files, compressing if bigger than a screen.
legacy iptables is a dockerd dependency, I don't think is a misconfiguration, as if I don't install dockerd everything is ok.
You should pre-install iptables-nft and ip6tables-nft o avoid -zz-legacy packages. It was reported at least once in ../packages. https://github.com/openwrt/packages/blob/d8bd171f838a4b1d2a3861ec6138ec1b9e2b3fca/utils/dockerd/Makefile#L39
Please re-configure network by: a. adding network to wifi ap definitions and removing wifi ap-s from bridge membership. b. eliminating vlan ID 1 c. pre-installing ip?tables-nft
backup config for yourself ;-)
Now install docker and if it is broken extract 6 files. fw4 and config/network will contain IPs, just type anything over those.
In principle this should have been reported in packages tracker, but you got wild misconfigurations, to the point it is fairly expected packets are lost in unpredictable places.
After did everything you said, it's still the same, after installing docker the local lan client can't ping each other, I've attached a custom uci-default that can replicate the issues, the vlan 1 I haven't changed it, but I've tested it, still not working, By the way I did should let the hostapd join the bridge, but after fix still not working, Also why vlan1 can't be used, I changed it still does nothing. 99-custom.txt
Note: the image ip 192.168.12.1 is another network, the gateway is 192.168.1.1 but is the same as the zone input is set to accept.
This is the wireshark data packet from the wifi device wl1-ap1 which belongs to 192.168.1.0/24 subnet, the local network should work at the layer 2 right? what can't they ping each other ? they can ping the gateway, but if I set the global forward to accept is working, eventhough the lan zone has forword to accept, but it shouldn't go forward, it's the local network. and should act like a switch right?
Install ip-bridge and check bridge vlan , really "should work" depends on dual racing configurations.
looks normal, it's very odd, after install dockerd, it's not working right, don't know what docker did to make this bug.
vlan30 is both tagged and untagged at br-lan. They are isolated, so depending on luck packets arrive in one or other place at br-lan. It takes editing one out from /etc/config/network and courage to restart/reboot after.
Run
fw4 print > /tmp/fw4.out
and
nft list ruleset > /tmp/nftables.out
then draw diff from them:
diff -w /tmp/fw4.out /tmp/nftables.out
post that as text section ```diff
+2
-3
```
It should show docker additions to nftables rules - more or less NAT from docker0 bridge to wan and incoming "exposed" ports from all ifaces. Question is if "all interfaces" got poisoned with dsa parent and/or something else misfired.
EDIT: you see that default all-untagged VLAN as id 1 on docker bridge ;-)
Find the culprit see the pic below:
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
# disable bridge firewalling by default
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
# enable bridge firewalling for docker
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
You have not yet provided anything resembling firewall rule. dual vlan30 your way guarantees network glitch even plugging cable.
also you need to pre-install arptables-nft and ebtables-nft, for same effect as dual hooks when legacy versions are used.
Actually openwrt's default net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-ip6tables=0 net.bridge.bridge-nf-call-iptables=0 is just not make bridge traffic go through firewall, which defeats the firewall setting of forward(the bridge forward input interface and output interface being the same)
after installing docker it enables the bridge traffic goes through firewall, and thus should make the zone forwrad work but here's the thing, I add a log to forward chain with: sudo nft add rule inet fw4 forward log, The log shows:
It should come from br-lan.valn But it's comming form br-lan !!!!!
Replace picture with text, I am afraid without context packets legitimately sink in your misconfigured bridge.
@brada4 What do you mean by dual vlan 30, I don't have dual vlan 30
valn1 is the mentiond 30.
Frankly no idea why your config is nibbling under the keyboard. Attach config files and lets start from the beginning.
The Image you showed is not two vlan 30, it's lan4 port untaged for vlan 30 Did you test on a fresh install openwrt and create some vlans using DSA and enable net.bridge.bridge-nf-call-ip6tables=1 net.bridge.bridge-nf-call-iptables=1 (just as dockerd did) does it work with any vlan clients that can ping each other? I don't think this is related to my config, if your config as I said, and works, then could be something else, otherwise is a bug that firewall loged input interface is br-lan and not br-lan.vlanid , thus makes it not working right for the luci firewall zone configs.
I dont get net.bridge structure and dockers' creativity runs short. i install 5x ????tables-nft I config 2 vlans I install docker install hello-world nothing in ebtables level.
Install all tables-zz-legacy Install docker System console works, config looks sane but nothing works across br-lan.... After reboot it works quite sporadically, like some lost pings between VM-s at times.
We are not trading about your configs. Your picture shows vlan30 being tagged and untagged at br-lan. One works at any point, so other does not and small state change flips the switch. You show obvious misconfiguration that can isolate bridge hosts on its own, it points fingers off docks.
The issue basically lies down to zone forward, the OpenWrt doc says: FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone. I was originally think that set forwrod to reject or drop would block the bridged interface from comunicating, but it's not the case. This is confusing, because it can't work on bridge or vlan.
It doesn't work on bridges, and it's default net.bridge.bridge-nf-call-arptables=0 net.bridge.bridge-nf-call-ip6tables=0 net.bridge.bridge-nf-call-iptables=0 which is for performance I think.
Some other references: https://netdevconf.info/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf https://openwrt.org/docs/guide-user/firewall/fw3_configurations/bridge
??? any chance to see your nftables ruleset? In all levels of iptables and nftables absence of rules means accept.
table inet fw4 {
chain input {
type filter hook input priority filter; policy drop;
iifname "lo" accept comment "!fw4: Accept traffic from loopback"
ct state established,related accept comment "!fw4: Allow inbound established and related flows"
tcp flags syn / fin,syn,rst,ack jump syn_flood comment "!fw4: Rate limit TCP syn packets"
iifname "br-lan.1" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
iifname { "wan", "wl0-sta0" } jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
iifname "br-lan.10" jump input_mgmt comment "!fw4: Handle mgmt IPv4/IPv6 input traffic"
iifname "br-lan.11" jump input_iot comment "!fw4: Handle iot IPv4/IPv6 input traffic"
iifname "br-lan.12" jump input_kid comment "!fw4: Handle kid IPv4/IPv6 input traffic"
iifname "br-lan.21" jump input_guest comment "!fw4: Handle guest IPv4/IPv6 input traffic"
iifname "br-tailnet" jump input_tailnet comment "!fw4: Handle tailnet IPv4/IPv6 input traffic"
iifname "docker0" jump input_docker comment "!fw4: Handle docker IPv4/IPv6 input traffic"
}
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
iifname "br-lan.1" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
iifname { "wan", "wl0-sta0" } jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
iifname "br-lan.10" jump forward_mgmt comment "!fw4: Handle mgmt IPv4/IPv6 forward traffic"
iifname "br-lan.11" jump forward_iot comment "!fw4: Handle iot IPv4/IPv6 forward traffic"
iifname "br-lan.12" jump forward_kid comment "!fw4: Handle kid IPv4/IPv6 forward traffic"
iifname "br-lan.21" jump forward_guest comment "!fw4: Handle guest IPv4/IPv6 forward traffic"
iifname "br-tailnet" jump forward_tailnet comment "!fw4: Handle tailnet IPv4/IPv6 forward traffic"
iifname "docker0" jump forward_docker comment "!fw4: Handle docker IPv4/IPv6 forward traffic"
}
chain output {
type filter hook output priority filter; policy accept;
oifname "lo" accept comment "!fw4: Accept traffic towards loopback"
ct state established,related accept comment "!fw4: Allow outbound established and related flows"
oifname "br-lan.1" jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
oifname { "wan", "wl0-sta0" } jump output_wan comment "!fw4: Handle wan IPv4/IPv6 output traffic"
oifname "br-lan.10" jump output_mgmt comment "!fw4: Handle mgmt IPv4/IPv6 output traffic"
oifname "br-lan.11" jump output_iot comment "!fw4: Handle iot IPv4/IPv6 output traffic"
oifname "br-lan.12" jump output_kid comment "!fw4: Handle kid IPv4/IPv6 output traffic"
oifname "br-lan.21" jump output_guest comment "!fw4: Handle guest IPv4/IPv6 output traffic"
oifname "br-tailnet" jump output_tailnet comment "!fw4: Handle tailnet IPv4/IPv6 output traffic"
oifname "docker0" jump output_docker comment "!fw4: Handle docker IPv4/IPv6 output traffic"
}
chain prerouting {
type filter hook prerouting priority filter; policy accept;
iifname "br-lan.1" jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment"
iifname "br-lan.10" jump helper_mgmt comment "!fw4: Handle mgmt IPv4/IPv6 helper assignment"
iifname "br-lan.11" jump helper_iot comment "!fw4: Handle iot IPv4/IPv6 helper assignment"
iifname "br-lan.12" jump helper_kid comment "!fw4: Handle kid IPv4/IPv6 helper assignment"
iifname "br-lan.21" jump helper_guest comment "!fw4: Handle guest IPv4/IPv6 helper assignment"
iifname "br-tailnet" jump helper_tailnet comment "!fw4: Handle tailnet IPv4/IPv6 helper assignment"
iifname "docker0" jump helper_docker comment "!fw4: Handle docker IPv4/IPv6 helper assignment"
}
chain handle_reject {
meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic"
reject comment "!fw4: Reject any other traffic"
}
chain syn_flood {
limit rate 25/second burst 50 packets return comment "!fw4: Accept SYN packets below rate-limit"
drop comment "!fw4: Drop excess packets"
}
chain input_lan {
jump accept_from_lan
}
chain output_lan {
jump accept_to_lan
}
chain forward_lan {
jump accept_to_wan comment "!fw4: Accept lan to wan forwarding"
jump accept_to_iot comment "!fw4: Accept lan to iot forwarding"
jump accept_to_tailnet comment "!fw4: Accept lan to tailnet forwarding"
jump accept_to_lan
}
chain helper_lan {
}
chain accept_from_lan {
iifname "br-lan.1" counter packets 1025 bytes 128737 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain accept_to_lan {
oifname "br-lan.1" counter packets 39 bytes 6457 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
}
chain input_wan {
meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
icmp type echo-request counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping"
meta nfproto ipv4 meta l4proto igmp counter packets 10 bytes 320 accept comment "!fw4: Allow-IGMP"
meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . no-route, mld-listener-report . no-route, mld-listener-done . no-route, mld2-listener-report . no-route } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second counter packets 17 bytes 1472 accept comment "!fw4: Allow-ICMPv6-Input"
icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
jump reject_from_wan
}
chain output_wan {
jump accept_to_wan
}
chain forward_wan {
icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP"
udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP"
jump reject_to_wan
}
chain accept_to_wan {
meta nfproto ipv4 oifname { "wan", "wl0-sta0" } ct state invalid counter packets 51 bytes 2448 drop comment "!fw4: Prevent NAT leakage"
oifname { "wan", "wl0-sta0" } counter packets 21849 bytes 1815083 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
}
chain reject_from_wan {
iifname { "wan", "wl0-sta0" } counter packets 816 bytes 157933 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
}
chain reject_to_wan {
oifname { "wan", "wl0-sta0" } counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
}
chain input_mgmt {
jump accept_from_mgmt
}
chain output_mgmt {
jump accept_to_mgmt
}
chain forward_mgmt {
counter packets 1700 bytes 246216 accept comment "!fw4: Allow-Mgmt-All"
jump accept_to_mgmt
}
chain helper_mgmt {
}
chain accept_from_mgmt {
iifname "br-lan.10" counter packets 136 bytes 17107 accept comment "!fw4: accept mgmt IPv4/IPv6 traffic"
}
chain accept_to_mgmt {
oifname "br-lan.10" counter packets 22 bytes 5376 accept comment "!fw4: accept mgmt IPv4/IPv6 traffic"
}
chain input_iot {
jump accept_from_iot
}
chain output_iot {
jump accept_to_iot
}
chain forward_iot {
jump accept_to_wan comment "!fw4: Accept iot to wan forwarding"
jump drop_to_iot
}
chain helper_iot {
}
chain accept_from_iot {
iifname "br-lan.11" counter packets 485 bytes 51969 accept comment "!fw4: accept iot IPv4/IPv6 traffic"
}
chain accept_to_iot {
oifname "br-lan.11" counter packets 30 bytes 7895 accept comment "!fw4: accept iot IPv4/IPv6 traffic"
}
chain drop_to_iot {
oifname "br-lan.11" counter packets 0 bytes 0 drop comment "!fw4: drop iot IPv4/IPv6 traffic"
}
chain input_kid {
jump accept_from_kid
}
chain output_kid {
jump accept_to_kid
}
chain forward_kid {
jump accept_to_wan comment "!fw4: Accept kid to wan forwarding"
jump accept_to_iot comment "!fw4: Accept kid to iot forwarding"
jump accept_to_tailnet comment "!fw4: Accept kid to tailnet forwarding"
jump accept_to_kid
}
chain helper_kid {
}
chain accept_from_kid {
iifname "br-lan.12" counter packets 18 bytes 4329 accept comment "!fw4: accept kid IPv4/IPv6 traffic"
}
chain accept_to_kid {
oifname "br-lan.12" counter packets 18 bytes 4329 accept comment "!fw4: accept kid IPv4/IPv6 traffic"
}
chain input_guest {
ip daddr 192.168.21.1 tcp dport 53 counter packets 0 bytes 0 accept comment "!fw4: Allow-DNS-Guest"
ip daddr 192.168.21.1 udp dport 53 counter packets 0 bytes 0 accept comment "!fw4: Allow-DNS-Guest"
meta nfproto ipv4 udp dport 67 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Guest"
jump drop_from_guest
}
chain output_guest {
jump accept_to_guest
}
chain forward_guest {
jump accept_to_wan comment "!fw4: Accept guest to wan forwarding"
jump drop_to_guest
}
chain helper_guest {
}
chain accept_to_guest {
oifname "br-lan.21" counter packets 0 bytes 0 accept comment "!fw4: accept guest IPv4/IPv6 traffic"
}
chain drop_from_guest {
iifname "br-lan.21" counter packets 0 bytes 0 drop comment "!fw4: drop guest IPv4/IPv6 traffic"
}
chain drop_to_guest {
oifname "br-lan.21" counter packets 0 bytes 0 drop comment "!fw4: drop guest IPv4/IPv6 traffic"
}
chain input_tailnet {
jump accept_from_tailnet
}
chain output_tailnet {
jump accept_to_tailnet
}
chain forward_tailnet {
jump accept_to_wan comment "!fw4: Accept tailnet to wan forwarding"
jump accept_to_tailnet
}
chain helper_tailnet {
}
chain accept_from_tailnet {
iifname "br-tailnet" counter packets 924 bytes 56030 accept comment "!fw4: accept tailnet IPv4/IPv6 traffic"
}
chain accept_to_tailnet {
oifname "br-tailnet" counter packets 1738 bytes 225489 accept comment "!fw4: accept tailnet IPv4/IPv6 traffic"
}
chain input_docker {
jump drop_from_docker
}
chain output_docker {
jump accept_to_docker
}
chain forward_docker {
jump accept_to_wan comment "!fw4: Accept docker to wan forwarding"
jump drop_to_docker
}
chain helper_docker {
}
chain accept_to_docker {
oifname "docker0" counter packets 0 bytes 0 accept comment "!fw4: accept docker IPv4/IPv6 traffic"
}
chain drop_from_docker {
iifname "docker0" counter packets 230 bytes 13000 drop comment "!fw4: drop docker IPv4/IPv6 traffic"
}
chain drop_to_docker {
oifname "docker0" counter packets 0 bytes 0 drop comment "!fw4: drop docker IPv4/IPv6 traffic"
}
chain dstnat {
type nat hook prerouting priority dstnat; policy accept;
}
chain srcnat {
type nat hook postrouting priority srcnat; policy accept;
oifname { "wan", "wl0-sta0" } jump srcnat_wan comment "!fw4: Handle wan IPv4/IPv6 srcnat traffic"
}
chain srcnat_wan {
meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
}
chain raw_prerouting {
type filter hook prerouting priority raw; policy accept;
}
chain raw_output {
type filter hook output priority raw; policy accept;
}
chain mangle_prerouting {
type filter hook prerouting priority mangle; policy accept;
}
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
}
chain mangle_input {
type filter hook input priority mangle; policy accept;
}
chain mangle_output {
type route hook output priority mangle; policy accept;
}
chain mangle_forward {
type filter hook forward priority mangle; policy accept;
iifname { "wan", "wl0-sta0" } tcp flags syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 ingress MTU fixing"
oifname { "wan", "wl0-sta0" } tcp flags syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 egress MTU fixing"
}
}
table ip filter {
chain DOCKER-USER {
iifname "wan" oifname "docker0" counter packets 0 bytes 0 xt target "REJECT"
counter packets 112354 bytes 35803618 return
}
chain DOCKER {
}
chain DOCKER-ISOLATION-STAGE-1 {
iifname "docker0" oifname != "docker0" counter packets 4538 bytes 352987 jump DOCKER-ISOLATION-STAGE-2
iifname "br-tailnet" oifname != "br-tailnet" counter packets 40525 bytes 4866213 jump DOCKER-ISOLATION-STAGE-2
counter packets 112354 bytes 35803618 return
}
chain DOCKER-ISOLATION-STAGE-2 {
oifname "docker0" counter packets 0 bytes 0 drop
oifname "br-tailnet" counter packets 0 bytes 0 drop
counter packets 45063 bytes 5219200 return
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
counter packets 112354 bytes 35803618 jump DOCKER-USER
counter packets 112354 bytes 35803618 jump DOCKER-ISOLATION-STAGE-1
oifname "docker0" xt match "conntrack" counter packets 527 bytes 82574 accept
oifname "docker0" counter packets 0 bytes 0 jump DOCKER
iifname "docker0" oifname != "docker0" counter packets 4538 bytes 352987 accept
iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
oifname "br-tailnet" xt match "conntrack" counter packets 24119 bytes 5591307 accept
oifname "br-tailnet" counter packets 2256 bytes 270280 jump DOCKER
iifname "br-tailnet" oifname != "br-tailnet" counter packets 40525 bytes 4866213 accept
iifname "br-tailnet" oifname "br-tailnet" counter packets 1649 bytes 219523 accept
}
}
table ip nat {
chain DOCKER {
iifname "docker0" counter packets 230 bytes 13000 return
iifname "br-tailnet" counter packets 588 bytes 39770 return
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 394 bytes 27686 xt target "MASQUERADE"
oifname != "br-tailnet" ip saddr 172.20.0.0/24 counter packets 3112 bytes 242743 xt target "MASQUERADE"
}
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
xt match "addrtype" counter packets 1001 bytes 69797 jump DOCKER
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
ip daddr != 127.0.0.0/8 xt match "addrtype" counter packets 0 bytes 0 jump DOCKER
}
}
The clients within a vlan can not ping each other, setting the zone forward to accept does not do anything, because of net.bridge.bridge-nf-call-ip6tables=0 net.bridge.bridge-nf-call-iptables=0 And even after docker turns on it's still not gonna work because the iifname is br-lan and it's not br-lan.vlanid, so makes me thinking that the zone forwrding has no use case, FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone. Not the forwarding which like forward to another zone like wan.
@jow- i am puzzled why xt ct slips into docker table while normal ct is fine in fw4