[Firehol-support] Routing between virtual interfaces

[M. O.]

Here we go again...
I did some more testing today. As announced in my last mail, I took the chance to replace all my old switches by new 1GBit ones to make sure the strange problems are not caused by malfunctioning hardware. And here is the "surprise": the problems did not disappear. So I'm pretty sure now they are rooted in the server's configuration... maybe there's also the possibility of a small flaw within firehol?

This is the debug log output appearing when I try to ping a machine (which works) and when I try to access the machines web interface (which most of the times doesn't work):

Feb  6 18:02:47 ds10 kernel: 'DELTA2BRO:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=431 TOS=0x00 PREC=0x00 TTL=63 ID=33347 DF PROTO=TCP SPT=55723 DPT=80 WINDOW=65535 RES=0x00 ACK PSH URGP=0 
Feb  6 18:02:47 ds10 kernel: 'PASS-unknown:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=431 TOS=0x00 PREC=0x00 TTL=63 ID=33347 DF PROTO=TCP SPT=55723 DPT=80 WINDOW=65535 RES=0x00 ACK PSH URGP=0 
Feb  6 18:02:48 ds10 kernel: 'DELTA2BRO:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=431 TOS=0x00 PREC=0x00 TTL=63 ID=30302 DF PROTO=TCP SPT=55722 DPT=80 WINDOW=65535 RES=0x00 ACK PSH FIN URGP=0 
Feb  6 18:02:48 ds10 kernel: 'PASS-unknown:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=431 TOS=0x00 PREC=0x00 TTL=63 ID=30302 DF PROTO=TCP SPT=55722 DPT=80 WINDOW=65535 RES=0x00 ACK PSH FIN URGP=0 
Feb  6 18:02:48 ds10 kernel: 'DELTA2BRO:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=6765 DF PROTO=TCP SPT=55722 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 
Feb  6 18:02:48 ds10 kernel: 'PASS-unknown:'IN=eth0 OUT=eth0 SRC=192.168.0.4 DST=192.168.1.51 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=6765 DF PROTO=TCP SPT=55722 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0

As you can see, there are some contradictory statements: one maps the traffic from 192.168.0.4 to 192.168.1.51 successfully to the rule "DELTA2BRO", and the next line tells the exact opposite (same addresses are mapped to "PASS-unknown"). I'm quite in despair now.

Any ideas, Carlos?


All the best,

Morin 


> Date: Wed, 28 Jan 2009 16:53:12 +0000
> Subject: Re: [Firehol-support] Routing between virtual interfaces
> From: cefrodrigues at gmail.com
> To: mofog at hotmail.com
> CC: firehol-support at lists.sourceforge.net
> 
> On Wed, Jan 28, 2009 at 4:07 PM, M. O. <mofog at hotmail.com> wrote:
> > Still, how could the routing possibly work though the firewall, and
> > therefore the routing, has been shut down?
> 
> Routing is completely independent of the firewall.
> 
> When "/proc/sys/net/ipv4/ip_forward" is enabled, routing is enabled.
> The firewall (iptables) allows you to control what can pass and what
> can't, it does not control routing itself.
> 
> In fact you can do advanced routing configurations without having any
> kind of firewall (just "man ip" and see the "route" section), but I
> don't think that applies to your case.
> 
> Now, when you enable firehol, it enables the stateful part of iptables
> (ip_conntrack). In its most simple aspect, this means when a
> connection is established from A to B, this is memorized by the the
> firewall so that corresponding traffic from B to A can flow. You can
> see the list of memorized connections by catting the
> "/proc/net/ip_conntrack" file.
> 
> If there are no problems when the firewall is down, but when it is up
> sometimes it works and sometimes it doesn't, then it really looks like
> a connection tracking issue. You can add "log" parameters to some
> rules in the firehol configuration and then see what gets blocked. If
> there's stuff (that should be allowed) being blocked by the firewall,
> the logging information should provide some clues as to why.
> 
> Regards,
> 
> -- 
> Carlos Rodrigues

_________________________________________________________________
http://redirect.gimas.net/?n=M0902xSearchVideo
Videosuche - Ganz einfach mit der Live Search
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.firehol.org/pipermail/firehol-support/attachments/20090206/abdcc7e5/attachment-0003.html>