Modify

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#13422 closed defect (fixed)

Disappearing Firewall rules.

Reported by: John Allen <john@…> Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

I just updated r36419 and ran into a problem.
both the network and firewall seem not to work.
I will concentrate on the firewall problem as it appears to be the more serious.
I added the following two stanza to the firewall rules in order to allow dns and http through from the WAN to the DMZ.

config rule
	option target 'ACCEPT'
	option src 'wan'
	option dest 'dmz'
	option name 'DNS'
	option dest_port '53'

config rule
	option target 'ACCEPT'
	option src 'wan'
	option dest 'dmz'
	option name 'HTTP'
	option dest_port '80

They did not seem to have any effect. When I investigated further I found that while the rules were in the firewall config, the did not show up in iptables -S.
The only way that I could get the servers online was to blanket forward WAN to DMZ.

Attachments (4)

openwrt_iptables.txt (2.8 KB) - added by John Allen <john@…> 5 years ago.
firewall config taken from backup 2013-04-26
openwrt_iptables.2.txt (2.8 KB) - added by John Allen <john@…> 5 years ago.
iptables -S output
firewall (2.7 KB) - added by John Allen <john@…> 5 years ago.
firewall config taken from backup 2013-04-26
config_remarks.txt (376 bytes) - added by John Allen <john@…> 5 years ago.
general remarks on my network/server config

Download all attachments as: .zip

Change History (11)

Changed 5 years ago by John Allen <john@…>

firewall config taken from backup 2013-04-26

Changed 5 years ago by John Allen <john@…>

iptables -S output

Changed 5 years ago by John Allen <john@…>

firewall config taken from backup 2013-04-26

Changed 5 years ago by John Allen <john@…>

general remarks on my network/server config

comment:1 Changed 5 years ago by John Allen <john@…>

Sorry I screwed up and added one of the attachments twice,please ignore the 1st one.

comment:2 Changed 5 years ago by john@…

JOW, advised me to add "option proto 'tcp udp'" to the rules that I was adding.
his solved the firewall problem, but creates another.

I was using LuCi to do the setup/maint on the system -
so why doesn't LUCI output the appropriate line by default.
alternatively, though some what less desirably, why does uci firewall use udp tcp by default. I can see an argument for not doing this (the law of unexpected consequences).

comment:3 follow-up: Changed 5 years ago by anonymous

The LuCI page DOES output that line... The only way to make it not is user-error by selecting custom in the protocol field and then deleting the contents in the field.

It's probably TCP+UDP because a lot of people don't know what they're doing and it will eliminate the "my forwarding isn't working omg a bug!" tickets created. If you are an experienced user you should know what protocol you want to use and be sure to set it how you need it. Say they pick TCP by default and you need to forward UDP you will still need to check that it is set correctly.

comment:4 Changed 5 years ago by John Allen <john@…>

Looks like the same problem as 13386.

comment:5 in reply to: ↑ 3 Changed 5 years ago by anonymous

Replying to anonymous:

The LuCI page DOES output that line... The only way to make it not is user-error by selecting custom in the protocol field and then deleting the contents in the field.

Yes LuCI does display UDP TCP as the default, but that does not result in the generation of the appropriate line in the Firewall config file.
As noted elsewhere if a change is made the protocol field on the LuCI screen then it behaves as expected, however if "udp tcp" is the desired output and no change is made to the Protocol field in LUCI then the "option proto" line is not output/created. This to me is a bug.

It's probably TCP+UDP because a lot of people don't know what they're doing and it will eliminate the "my forwarding isn't working omg a bug!" tickets created. If you are an experienced user you should know what protocol you want to use and be sure to set it how you need it. Say they pick TCP by default and you need to forward UDP you will still need to check that it is set correctly.

In this particular case I wanted both TCP & UDP as the rule was to control access to my DNS which uses UDP as a primary protocol, but will fall back to TCP should the need arise.
In case you are wondering why I do not use the DNS feature of Openwrt, I operate the authoritative DNSes for my partners and my own domains which I do not believe is possible with the DNSMASQ of Openwrt. Further, I have implemented DNSSEC on all the DNS's under my control, again something I believe is beyond the current capabilities of Openwrt.

comment:6 Changed 5 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

r36521 aligns firewall3 behaviour with the old implementation - means rules are implicitly set to "tcp+udp" if no proto is specified.

comment:7 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.