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 Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001347Endian FirewallFirewall (iptables)public2008-09-29 13:192009-10-27 12:02
Reporterpeter-endian 
Assigned Topeter-endian 
PriorityurgentSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version2.3 
Summary0001347: ebtables zone firewall blocks traffic which should not be blocked
Descriptionsometimes 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.
Tagsneedsfix
Attached Files

- Relationships

-  Notes
(0001651)
peter-endian (administrator)
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 (administrator)
2008-10-08 13:37

Quick fix:

rm /var/lib/ticketregistry/interfaces
reboot

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

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker