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
MantisBT - Endian Firewall
View Issue Details
0001515Endian FirewallFirewall (iptables)public2008-12-17 15:392009-04-14 20:56
peter-endian 
peter-endian 
normalmajorsometimes
closedfixed 
2.2-rc3 
2.3 
0001515: zonefw: --state NEW check blocks communication to clients behind a router due to triangle connection
the 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
heavy, needsfix
related to 0001768new peter-endian drop new connections without syn-flag via default-ruleset 
related to 0003081closed christian-endian Endian Firewall sends icmp redirects 
Issue History
2008-12-17 15:39peter-endianNew Issue
2008-12-17 15:39peter-endianAssigned To => peter-endian
2008-12-17 15:39peter-endianTag Attached: needsfix
2008-12-17 15:39peter-endianTag Attached: heavy
2008-12-17 16:37peter-endianNote Added: 0001886
2008-12-17 17:54peter-endianNote Added: 0001889
2008-12-23 22:06peter-endianStatusnew => resolved
2008-12-23 22:06peter-endianFixed in Version => 2.3
2008-12-23 22:06peter-endianResolutionopen => fixed
2009-04-14 12:52mike-fNote Added: 0002143
2009-04-14 12:52mike-fStatusresolved => feedback
2009-04-14 12:52mike-fResolutionfixed => reopened
2009-04-14 13:21mike-fNote Added: 0002144
2009-04-14 19:25peter-endianRelationship addedrelated to 0001768
2009-04-14 19:28peter-endianNote Added: 0002147
2009-04-14 19:48mike-fNote Added: 0002150
2009-04-14 20:56peter-endianNote Added: 0002151
2009-04-14 20:56peter-endianStatusfeedback => closed
2009-04-14 20:56peter-endianResolutionreopened => fixed
2010-09-17 09:22christian-endianRelationship addedrelated to 0003081

Notes
(0001886)
peter-endian   
2008-12-17 16:37   
shorewall never checks --state NEW, accepts only ESTABLISHED and RELATED before all other rules
(0001889)
peter-endian   
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   
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   
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   
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   
2009-04-14 19:48   
thanx for the ascii

indeed - this makes auto-updating of routing tables a bit more complex
(0002151)
peter-endian   
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