Zone NOT dropping traffic

Hi Everyone,

I have OpenWRT installed on a VM with a trunk interface that branches out to various VLANs on my network and internet. I'm actually pretty impressed at the odhcp implementation that allows me to route the rapidly changing ipv6 /56 prefix to multiple segments instead of the /64 that is only routed to one like all the excuses for firewalls that are available on the market. What's more, it's pretty diabolical that a lot of these firewalls are forks of OpenWRT and ISPs seem to go out of their way to gimp features they don't understand instead of hiring quality engineers.

I've noticed that zones do NOT appear to be DROPPING inbound internet traffic when set to do so. What's worse, LUCI is exposed on port 80/443 and appears to be accepting connections:

Starting Nmap 7.01 ( https://nmap.org ) at 2021-04-20 07:04 AEST
Host is up (0.041s latency).
Not shown: 65527 filtered ports
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
554/tcp open rtsp
1723/tcp open pptp
8554/tcp open unknown

The relevant parts of the configuration are as follows:

config defaults
	option synflood_protect '1'
	option input 'DROP'
	option forward 'DROP'
	option output 'DROP'

config zone
	option name 'net'
	option network 'NET4 NET6'
	option masq '1'
	option output 'ACCEPT'
	option input 'DROP'
	option forward 'DROP'
	option mtu_fix '1'

config rule
	option target 'ACCEPT'
	option name 'ICMP'
	option src '*'
	list proto 'icmp'
	list proto 'igmp'
	list proto 'icmpv6'

config rule
	option src 'net'
	option name 'DHCP6'
	option target 'ACCEPT'
	list proto 'udp'
	option family 'ipv6'
	option dest_port '546'

And the relevant iptables "filter" is as follows:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* !fw3 */
input_rule  all  --  anywhere             anywhere             /* !fw3: Custom input rule chain */
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED /* !fw3 */
syn_flood  tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN /* !fw3 */
ACCEPT     icmp --  anywhere             anywhere             /* !fw3: ICMP */
ACCEPT     igmp --  anywhere             anywhere             /* !fw3: ICMP */
zone_net_input  all  --  anywhere             anywhere             /* !fw3 */

Chain zone_net_input (1 references)
target     prot opt source               destination
input_net_rule  all  --  anywhere             anywhere             /* !fw3: Custom net input rule chain */
ACCEPT     all  --  anywhere             anywhere             ctstate DNAT /* !fw3: Accept port redirections */
zone_net_src_DROP  all  --  anywhere             anywhere             /* !fw3 */

Chain input_net_rule (1 references)
target     prot opt source               destination

Chain zone_net_src_DROP (1 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere             /* !fw3 */

Chain syn_flood (1 references)
target     prot opt source               destination
RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 /* !fw3 */
DROP       all  --  anywhere             anywhere             /* !fw3 */

And "nat" tables:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
prerouting_rule  all  --  anywhere             anywhere             /* !fw3: Custom prerouting rule chain */
zone_net_prerouting  all  --  anywhere             anywhere             /* !fw3 */

Chain prerouting_rule (1 references)
target     prot opt source               destination

Chain zone_net_prerouting (1 references)
target     prot opt source               destination
prerouting_net_rule  all  --  anywhere             anywhere             /* !fw3: Custom net prerouting rule chain */

Chain prerouting_net_rule (1 references)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
postrouting_rule  all  --  anywhere             anywhere             /* !fw3: Custom postrouting rule chain */
zone_net_postrouting  all  --  anywhere             anywhere             /* !fw3 */

Chain postrouting_net_rule (1 references)
target     prot opt source               destination

Chain zone_net_postrouting (1 references)
target     prot opt source               destination
postrouting_net_rule  all  --  anywhere             anywhere             /* !fw3: Custom net postrouting rule chain */
MASQUERADE  all  --  anywhere             anywhere             /* !fw3 */

Chain postrouting_net_rule (1 references)
target     prot opt source               destination

The "mangle" tables only have the MTU fixes:

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN /* !fw3: Zone net MTU fixing */ TCPMSS clamp to PMTU
TCPMSS     tcp  --  anywhere             anywhere             tcp flags:SYN,RST/SYN /* !fw3: Zone net MTU fixing */ TCPMSS clamp to PMTU

I know I can create a rule to block or rebind LUCI, but I'd rather use zones to DROP as this appears to be the intended functionality. Can anybody suggest where I have gone wrong or if this is a bug?

Best Regards,
David Balnaves

In What zone is the device where you run nmap?

1 Like

Hi dlakelan,

I was running nmap on the net zone - on a separate internet connection. Realize there could be rebuffering or transparent proxies BUT I actually confirmed the connections were made and acknowledged using a mirror port.

Ahh, interesting I just did another scan now and I got a different result. I'm not at home now and I'm not sure what is being filtered on this network but now it appears:

Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-20 00:07 UTC
Host is up (0.014s latency).
Not shown: 998 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
53/tcp open  domain

Since my original post I also disabled a whole heap of "helpers" on the net zone. I think I'll need to test this again when I have access to my mirror port

Works for me, in your case the reason should be one of those:

  • The interface is incorrectly assigned to the zone.
  • Scanning is performed from/to/over the wrong host/interface.
2 Likes

Hi Vgaetera,

Don't think it was either.

There was a point where I did see a CONNECT from public addresses (ie: SYN/ACK on mirror port corresponding to the public interface) but I can confirm this is no longer the case and it seems that this was confused by multiple configuration changes and different internet services.

One scenario performed an nmap scan over a mobile (cell network) carrier which are known to run TCP acceleration/proxies in order to help overcome latency and increase TCP window sizes hence showing OPEN in nmap. I was able to confirm this false positive in nmap by the lack of a SYN/ACK from OpenWrt.

I do however have some questions remaining; Where can I find the session tables in OpenWRT (ie: what used to be found under /proc/net/conntrack)? What about the nat tables? Is there any way I can inspect the state of netfilter helper modules?