Bug 10525

Summary:	BOOTPC/BOOTPS blocked by in OUTGOING Firewall rules
Product:	IPFire	Reporter:	Matthias Fischer <matthias.fischer>
Component:	firewall	Assignee:	Michael Tremer <michael.tremer>
Status:	CLOSED FIXED	QA Contact:
Severity:	Minor Usability
Priority:	- Unknown -	CC:	alexander.marx, stefan.schantl
Version:	2
Hardware:	i686
OS:	Linux
Bug Depends on:
Bug Blocks:	10486

Description Matthias Fischer 2014-04-15 20:06:16 UTC

Setting FORWARD and OUTGOING Firewall default behaviour to BLOCKED leads to "send_packet"-errors in '/var/log/messages'.

Example:
...
DHCPACK to 192.168.100.3 (00:80:5f:eb:90:f3) via green0
send_packet: Operation not permitted
...

Similar entries appear in firewall-log:
...
REJECT_OUTPUT UDP 192.168.100.254 192.168.100.3 67(BOOTPS) 68(BOOTPC)
...

Despite these errors, machine gets a (fixed) IP-address.

Comment 1 Michael Tremer 2014-04-17 12:34:43 UTC

Hey,

could you please check if these changes work for you?

http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=8490e4961886c6fc44bbfcbaa5073484f235208e

Usually, this should not be necessary, because the connection tracking should handle the DHCP replies.

Comment 2 Matthias Fischer 2014-04-17 22:22:43 UTC

Hi Michael,

Seems to be fixed!

...
19:43:47 dhcpd: DHCPINFORM from 192.168.100.1 via green0
19:43:47 dhcpd: DHCPACK to 192.168.100.1 (00:07:e9:40:b8:29) via green0
19:43:47 dhcpd: send_packet: Operation not permitted
...
[Patches applied, restarted 'firewall' and 'dhcp']
...
19:48:20 dhcpd: Wrote 0 deleted host decls to leases file.
19:48:21 dhcpd: Wrote 0 new dynamic host decls to leases file.
19:48:21 dhcpd: Wrote 2 leases to leases file.
...
19:50:36 dhcpd: DHCPREQUEST for 192.168.100.1 from 00:07:e9:40:b8:29 via green0
19:50:36 dhcpd: DHCPACK on 192.168.100.1 to 00:07:e9:40:b8:29 via green0
...
21:50:37 dhcpd: DHCPREQUEST for 192.168.100.1 from 00:07:e9:40:b8:29 via green0
21:50:37 dhcpd: DHCPACK on 192.168.100.1 to 00:07:e9:40:b8:29 via green0

And: no more entries in 'Firewall Logs'.

Thanks!

Regards
Matthias

Comment 3 Michael Tremer 2014-04-18 12:59:01 UTC

Could you please give some insights about your configuration? On my system, it is not required to have these rules because the connection tracking is handling the replies. Any idea why this is not working on your installation?

Comment 4 Matthias Fischer 2014-04-18 14:28:47 UTC

Hi,

Current configuration is as follows:

2.15/RC1, core 76 (now 77)

Proxy:
NON-transparent on 8080 with squidclamav.

URLFilter with Shalla-Blacklist.

No further addons.

DHCP:
Enabled on GREEN (192.168.100.20-25)
13 fixed leases (11 PCs/Laptops 192.168.100.1-16, 2 Printboxes 192.168.100.241 + 242)
Default lease: 60, Max lease: 120

Default behaviour:
FORWARD blocked, OUTGOING blocked

Default policies:
REJECT (all)

FORWARD rules (GREEN -> ANY):
8080
Blizzard group (deactivated)
FTP group (20, 21)
Jabber group (5222 TCP/UDP)
SecureMail group (465, 587, 993, 995)
NTP 123
SSH (22, GIT for Ubuntu Devel)
ICMP

OUTGOING rules (RED -> ANY):
53
80
Blizzard group (deactivated)
43
123
ICMP

Iptables:

Chain OUTGOINGFW (1 references)
pkts 	bytes 	target 	prot 	opt 	in 	out 	source 	destination 	

381 	24221 	ACCEPT 	udp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	udp dpt:53
642 	38520 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:80
62 	3720 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:443
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:43
80 	6080 	ACCEPT 	udp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	udp dpt:123
582 	60116 	ACCEPT 	icmp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:8080
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	multiport dports 995,465,587,993
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:119
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	multiport dports 21,20
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:1935
0 	0 	ACCEPT 	udp 	-- 	* 	* 	0.0.0.0/0 	0.0.0.0/0 	udp dpt:123
0 	0 	ACCEPT 	icmp 	-- 	* 	* 	0.0.0.0/0 	0.0.0.0/0

Chain OUTGOINGFW (1 references)
pkts 	bytes 	target 	prot 	opt 	in 	out 	source 	destination 	

381 	24221 	ACCEPT 	udp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	udp dpt:53
642 	38520 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:80
62 	3720 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:443
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	tcp dpt:43
80 	6080 	ACCEPT 	udp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	udp dpt:123
582 	60116 	ACCEPT 	icmp 	-- 	* 	* 	93.216.62.94 	0.0.0.0/0 	
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:8080
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	multiport dports 995,465,587,993
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:119
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	multiport dports 21,20
0 	0 	ACCEPT 	tcp 	-- 	* 	* 	192.168.100.0/24 	0.0.0.0/0 	tcp dpt:1935
0 	0 	ACCEPT 	udp 	-- 	* 	* 	0.0.0.0/0 	0.0.0.0/0 	udp dpt:123
0 	0 	ACCEPT 	icmp 	-- 	* 	* 	0.0.0.0/0 	0.0.0.0/0

With default behaviour FORWARD=blocked, OUTGOING=ALLOWED, everything was ok.

After I switched OUTGOING to BLOCKED, DHCPACKs resulted in 'send_packet' errors and FW REJECTS, as shown above.

But: PCs were still getting the correct ip address.

HTH
Matthias

Comment 5 Michael Tremer 2014-04-22 10:49:30 UTC

Thanks for testing. I merged the changes into the master tree.

http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8490e4961886c6fc44bbfcbaa5073484f235208e