Ásgeir Ægisson wrote:> Sorry, > the log file messages I got were like: > [root@kjolur log]# grep rfc messages.1|more > Jun 11 09:54:18 kjolur kernel: Shorewall:rfc1918:DROP:IN=eth1 OUT> MAC=00:10:4b:47:c4:b6:00:03:6b:dc:00:69:08:00 SRC=194.144.133.3 > DST=192.168.100.2 LOk -- I still need to see the output of "shorewall status" with ''norfc1918'' enabled. Without connection tracking state match, these messages *should* be generated out of the ''mangle'' table which is traversed before DNAT is applied. I''ve simulated the absense of connection tracking state match on my own firewall and the resulting Netfilter ruleset looked correct. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Ásgeir Ægisson wrote:> I enabled norfc1918 in /etc/shorewall/interfaces. > > Attached file "status_norfc1918" holds the output of shorewall status. > > Attached file "status" shows the status with norfc1918 not included in > /etc/shorewall/interfaces >I don''t understand how the log messages that you reported were created. Here is the ''Mangle'' table (with unrelated parts snipped) from your status_norfc1918 file: Mangle Table Chain PREROUTING (policy ACCEPT 5765K packets, 3339M bytes) pkts bytes target prot opt in out source destination 8 384 man1918 all -- eth1 * 0.0.0.0/0 0.0.0.0/0 state NEW 561 91115 pretos all -- * * 0.0.0.0/0 0.0.0.0/0 Chain man1918 (1 references) pkts bytes target prot opt in out source destination 0 0 rfc1918 all -- * * 0.0.0.0/0 172.16.0.0/12 0 0 rfc1918 all -- * * 0.0.0.0/0 192.168.0.0/16 0 0 rfc1918 all -- * * 0.0.0.0/0 10.0.0.0/8 Chain rfc1918 (3 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:rfc1918:DROP:'' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 NEW connection requests entering on eth1 are sent to the ''man1918'' chain. There, the destination IP is compared against the RFC 1918 ranges and if a match is made the packet is sent to the ''rfc1918'' chain for logging and dispostion (DROP). You were seeing packets logged (and dropped) in this way -- the Mangle table is traversed *before* the NAT table so the destination IP address had not yet been rewritten by any DNAT rules found there. Note that there is also an ''rfc1918'' chain in the filter table; relevant entries are: Chain eth1_fwd (1 references) pkts bytes target prot opt in out source destination 0 0 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 0 0 norfc1918 all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW 1 41 tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0 20 3461 net2loc all -- * eth0 0.0.0.0/0 0.0.0.0/0 Chain norfc1918 (2 references) pkts bytes target prot opt in out source destination 0 0 rfc1918 all -- * * 172.16.0.0/12 0.0.0.0/0 0 0 rfc1918 all -- * * 192.168.0.0/16 0.0.0.0/0 0 0 rfc1918 all -- * * 10.0.0.0/8 0.0.0.0/0 Chain rfc1918 (3 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:rfc1918:DROP:'' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Note that the difference here is that the *source* IP address is checked against the RFC 1918 ranges -- that''s not what we saw in your log messages. Can you still reproduce the problem? If so, I would like to see the output of "shorewall status" after the problem is reproduced so that I can confirm the above analysis. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Ásgeir Ægisson wrote:> Yes I can reproduce the problem > I have attached files: rules, interfaces, messages. > Attached is also status_reproduce for "shorewall status" after > reproduction. >It is happening as my analysis predicted -- this indicates that something is broken in your kernel. Unfortunately, the Redhat errata no longer lists the Redhat Linux series so I''m unable to see if that was a known problem in your 2.4.18-3 kernel or not (My Shorewall 1.2 errata lists one known mangle table problem with early Redhat 2.4.18 kernels but not the one we''re seeing here). I guess that you are either going to have to leave ''norfc1918'' disabled or upgrade your firewall to a more recent (and vendor-supported) release. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Ásgeir Ægisson wrote: >> Yes I can reproduce the problem >> I have attached files: rules, interfaces, messages. >> Attached is also status_reproduce for "shorewall status" after >> reproduction. >> > > It is happening as my analysis predicted -- this indicates that > something is broken in your kernel. Unfortunately, the Redhat errata no > longer lists the Redhat Linux series so I''m unable to see if that was a > known problem in your 2.4.18-3 kernel or not (My Shorewall 1.2 errata > lists one known mangle table problem with early Redhat 2.4.18 kernels > but not the one we''re seeing here). > > I guess that you are either going to have to leave ''norfc1918'' disabled > or upgrade your firewall to a more recent (and vendor-supported) release.He can also upgrade the RedHat 8.0 Kernel to the latest errata kernel from fedoralegacy project. Works fine for me on RedHat 7.3. The release is kernel-2.4.20-30.8.legacy. Simon> > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm > >
Simon Matter wrote:> > He can also upgrade the RedHat 8.0 Kernel to the latest errata kernel from > fedoralegacy project. Works fine for me on RedHat 7.3. The release is > kernel-2.4.20-30.8.legacy. >It would be advisable to upgrade to the latest errata iptables at the same time. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net