0001347: ebtables zone firewall blocks traffic which should not be blocked

Endian Issue Tracker

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0001347

[Endian Firewall] Firewall (iptables)

major

have not tried

2008-09-29 15:19

2009-10-27 13:02

Reporter

peter

View Status

public

Assigned To

peter

Priority

urgent

Resolution

fixed

Status

closed

Product Version

Summary

0001347: ebtables zone firewall blocks traffic which should not be blocked

Description

sometimes it happens that the following rule:

Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
--mark 0x40000/0x40000 -j PHYSDEV

matches, when it should not.

Then the traffic which matches here, will be blocked, because there are no allow rules in the PHYSDEV chain.

The 0x40000 rule should fire only if the physdev bit (11th bit in mark, which is 0x40000) is set. This bit normally will only be set when a zone firewall rule needs to be created which should use a physdev-out device, which can't be done using iptables, but needs to be checked later in the path with ebtables.

Our port forwarding rules need to remember on which interface the traffic comes in in order to put it out through the same device. For this, we have rules in MARKIIF chain in the mangle table, which marks every connection passed through an interface with a respective assigned number

example:
    0 0 CONNMARK all -- eth1 * 0.0.0.0/0 0.0.0.0/0 CONNMARK set 0x800/0x3f800
  503 107K CONNMARK all -- eth2 * 0.0.0.0/0 0.0.0.0/0 CONNMARK set 0x1000/0x3f800

These numbers will be assigned using a ticketing system using the class TicketRegistry(), which writes down to /var/lib/ticketregistry/interfaces. This registry should assign to an interface a unique and persistent number, which is bound to the interface name.

Unfortunately this seems not to happen correctly, since there are big gaps between interface names:

'values': {0: {'bond0': 25,
                'br0': 15,
                'br2': 16,
                'eth0': 1,
                'eth1': 2,
                'eth2': 3,
                'eth3': 4,
                'eth3.222': 31,
                'eth3.4000': 41,
                'eth3.55': 29,
                'eth3.66': 30,
                'ipsec0': 65,
                'ipsec1': 66,
                'ipsec2': 67,
                'ipsec3': 68,
                'tap0': 61,
                'tap1': 62,
                'tap2': 63,
                'tap3': 64,
                'tap4': 59,
                'tun0': 60}}}

Maybe after each start of setinterfacemark.py an id will assigned to no item and thus the counter will be increased. Afterwards assignement to new interface names will get some bigger number and leave the gap. This is to be checked.

The gap becomes a problem, when a number will be assigned which is greater than its 7 bit bandwith which we have assigned for "interface mark".

When this happens, and a greater number will be assigned, the physdev bit is set, because of this overflow.
That causes the error.

Additional Information

Tags

needsfix

Attached Files

Relationships

Notes
(0001651) peter (administrator) 2008-09-29 20:01	missing check in TicketRegistry._removeAssignement(): if id < self.data['lastId']: self.data['lastId'] = id don't know if this is enough.

(0001670) peter (administrator) 2008-10-08 15:37	Quick fix: rm /var/lib/ticketregistry/interfaces reboot

Issue History
Date Modified	Username	Field	Change
2008-09-29 15:19	peter	New Issue
2008-09-29 15:20	peter	Tag Attached: needsfix
2008-09-29 15:20	peter	Tag Attached: heavy
2008-09-29 18:10	peter	Priority	normal => urgent
2008-09-29 18:10	peter	Severity	minor => major
2008-09-29 19:58	peter	Tag Detached: heavy
2008-09-29 20:01	peter	Note Added: 0001651
2008-10-07 16:58	peter	Project	Enterprise => Endian Firewall
2008-10-07 17:01	peter	Status	new => resolved
2008-10-07 17:01	peter	Fixed in Version	=> 2.3
2008-10-07 17:01	peter	Resolution	open => fixed
2008-10-07 17:01	peter	Assigned To	=> peter
2008-10-08 15:37	peter	Note Added: 0001670
2009-10-27 13:02	peter	Status	resolved => closed

Mantis [^]