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

0001515: zonefw: --state NEW check blocks communication to clients behind a router due to triangle connection - 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
0001515Endian FirewallFirewall (iptables)public2008-12-17 15:392009-04-14 20:56
Reporterpeter-endian 
Assigned Topeter-endian 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version2.2-rc3 
Target VersionFixed in Version2.3 
Summary0001515: zonefw: --state NEW check blocks communication to clients behind a router due to triangle connection
Descriptionthe following situation causes zonef firewall to block the connection:

192.168.20.10 ---| .20.1 .0.2|-----| .0.1 |------| .0.10

since 192.168.0.10 in order to go to 20.10 passes through it's default gateway: .0.1, but 0.2 can communicate directly with .0.10 because they are in the same subnet, response packets from 20.10 to 0.10 pass directly, without going through .0.1

the zone firewall in .0.1 however blocks because the zone firewall accepts only packets which are NEW. ESTABLISHED packets will be accepted at the beginning of the firewall construct.
since response packets never pass the firewall, the connection never becomes ESTABLISHED and the next request packet is NEW but not SYN, which causes the firewall to block.

this can be solved by removing the stateful check --state NEW from the zone firewall, or, as it has been in 2.1, re-adding
net.ipv4.conf.all.send_redirects = 1

which would cause .0.1 to send redirect icmp's to .0.10 in order to allow .0.10 to directly send packets for .20.0/24 to .0.2

!we removed send_redirects because of routing problems in 2.1!

!!both solutions may cause other problems!!

it's to check what solution is better
Tagsheavy, needsfix
Attached Files

- Relationships
related to 0001768newpeter-endian drop new connections without syn-flag via default-ruleset 
related to 0003081closedchristian-endian Endian Firewall sends icmp redirects 

-  Notes
(0001886)
peter-endian (administrator)
2008-12-17 16:37

shorewall never checks --state NEW, accepts only ESTABLISHED and RELATED before all other rules
(0001889)
peter-endian (administrator)
2008-12-17 17:54

only changing the stateful firewall behaviour causes to fill connection tracking table entries which each need to timeout in order to be removed.

icmp-redirect message would cause to completely circumvent the firewall which will not insert any conntrack entries when the sending host knows how to handle redirects.

probably the best solution would be a combination of both.
i think we had should toggle off only accept_redirects and shared_media, send_redirects maybe is not that disastruous (?)
need more research
(0002143)
mike-f (updater)
2009-04-14 12:52

this could be also resolved by adding 0.2 a bit more routing-input:

for the full network
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.1

just for the 0.10 host:
route add -host 192.168.0.10 gw 192.168.0.1
(0002144)
mike-f (updater)
2009-04-14 13:21

and 192.168.0.2 should have a netmask of 255.255.255.255 (192.168.0.2/32) - if this is the only IP on that net
(0002147)
peter-endian (administrator)
2009-04-14 19:28

it's not always possible to re-configure the router in order to make it send all to the default gateway
and you can't add the route on every single system in green

the diagram is maybe a little bit ambiguous.. here's a better one:

+--------+
| EFW |
+--------+
    | 192.168.0.1
    |
    +---GREEN----+ 192.168.0.10
    | + ...
    | + 192.168.0.20
    |
    | 192.168.0.2
+--------+
| router |
+--------+
    |192.168.20.1
    |
    +-+-GREEN2
      + 192.168.20.10
      + ...
      + 192.168.20.20

traffic from 192.168.0.2 will pass directly to 192.168.0.20 without going through 192.168.0.1

that will cause NEWnotSyn to block
(0002150)
mike-f (updater)
2009-04-14 19:48

thanx for the ascii

indeed - this makes auto-updating of routing tables a bit more complex
(0002151)
peter-endian (administrator)
2009-04-14 20:56

close this bug, since the described issue has been fixed in 2.3

discussion about reintroduction of NewNotSyn please in 0001768

- Issue History
Date Modified Username Field Change
2008-12-17 15:39 peter-endian New Issue
2008-12-17 15:39 peter-endian Assigned To => peter-endian
2008-12-17 15:39 peter-endian Tag Attached: needsfix
2008-12-17 15:39 peter-endian Tag Attached: heavy
2008-12-17 16:37 peter-endian Note Added: 0001886
2008-12-17 17:54 peter-endian Note Added: 0001889
2008-12-23 22:06 peter-endian Status new => resolved
2008-12-23 22:06 peter-endian Fixed in Version => 2.3
2008-12-23 22:06 peter-endian Resolution open => fixed
2009-04-14 12:52 mike-f Note Added: 0002143
2009-04-14 12:52 mike-f Status resolved => feedback
2009-04-14 12:52 mike-f Resolution fixed => reopened
2009-04-14 13:21 mike-f Note Added: 0002144
2009-04-14 19:25 peter-endian Relationship added related to 0001768
2009-04-14 19:28 peter-endian Note Added: 0002147
2009-04-14 19:48 mike-f Note Added: 0002150
2009-04-14 20:56 peter-endian Note Added: 0002151
2009-04-14 20:56 peter-endian Status feedback => closed
2009-04-14 20:56 peter-endian Resolution reopened => fixed
2010-09-17 09:22 christian-endian Relationship added related to 0003081

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


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker