SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0001347: ebtables zone firewall blocks traffic which should not be blocked - MantisBT
MantisBT - Endian Firewall
View Issue Details
0001347Endian FirewallFirewall (iptables)public2008-09-29 13:192009-10-27 12:02
peter-endian 
peter-endian 
urgentmajorhave not tried
closedfixed 
 
2.3 
0001347: ebtables zone firewall blocks traffic which should not be blocked
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.
needsfix
Issue History
2008-09-29 13:19peter-endianNew Issue
2008-09-29 13:20peter-endianTag Attached: needsfix
2008-09-29 13:20peter-endianTag Attached: heavy
2008-09-29 16:10peter-endianPrioritynormal => urgent
2008-09-29 16:10peter-endianSeverityminor => major
2008-09-29 17:58peter-endianTag Detached: heavy
2008-09-29 18:01peter-endianNote Added: 0001651
2008-10-07 14:58peter-endianProjectEnterprise => Endian Firewall
2008-10-07 15:01peter-endianStatusnew => resolved
2008-10-07 15:01peter-endianFixed in Version => 2.3
2008-10-07 15:01peter-endianResolutionopen => fixed
2008-10-07 15:01peter-endianAssigned To => peter-endian
2008-10-08 13:37peter-endianNote Added: 0001670
2009-10-27 12:02peter-endianStatusresolved => closed

Notes
(0001651)
peter-endian   
2008-09-29 18:01   
missing check in TicketRegistry._removeAssignement():
if id < self.data['lastId']:
    self.data['lastId'] = id

don't know if this is enough.
(0001670)
peter-endian   
2008-10-08 13:37   
Quick fix:

rm /var/lib/ticketregistry/interfaces
reboot