

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
the following situation causes zonef firewall to block the connection: ---| .20.1 .0.2|-----| .0.1 |------| .0.10

since 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

2008-12-17 16:37   
shorewall never checks --state NEW, accepts only ESTABLISHED and RELATED before all other rules
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
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 netmask gw

just for the 0.10 host:
route add -host gw
2009-04-14 13:21   
and should have a netmask of ( - if this is the only IP on that net
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 |
    | + ...
    | +
| router |
      + ...

traffic from will pass directly to without going through

that will cause NEWnotSyn to block
2009-04-14 19:48   
thanx for the ascii

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