Skip to contentSkip to conversation

netfilter periodically thinks local traffic is FORWARDed

DISCUSSION Brian J. Murrell 2 participants 3 messages Jul 19, 2011

lore
Share & tools
lore
#0 lore raw

I have a router running 2.6.32.27. It has an ip6 interface on it:

# ifconfig sixxs
sixxs     Link encap:IPv6-in-IPv4  
          inet6 addr: 2001:1234:f:107::2/64 Scope:Global
          inet6 addr: fe80::a08:1/64 Scope:Link
          inet6 addr: fe80::a4b:16fe/64 Scope:Link
          inet6 addr: fe80::ae8a:d6fb/64 Scope:Link
          inet6 addr: fe80::a4b:16c4/64 Scope:Link
          inet6 addr: fe80::43c1:d6f2/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:11962628 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7222926 errors:1393 dropped:0 overruns:0 carrier:1393
          collisions:0 txqueuelen:0
          RX bytes:1568350253 (1.4 GiB)  TX bytes:523325199 (499.0 MiB)

I have ip6tables rules installed (courtesy of Shorewall). It seems occasionally however that netfilter thinks that traffic that is (supposed to be) local is being forwarded:

Jul 19 06:44:41 10.75.22.196 kernel: Shorewall:FORWARD:REJECT:IN=sixxs

OUT=sixxs SRC=2001:1234:000f:0107:0000:0000:0000:0001 DST=2001:1234:000f:0107:0000:0000:0000:0002 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=19746 SEQ=16622

That reject message is being caused by the second to last rule of my FORWARD chain, after which the packet is "reject"ed:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
536K 243M accounting all * * ::/0
::/0
127K 13M dynamic all * * ::/0
::/0 ctstate INVALID,NEW
274K 219M net2loc all sixxs br-lan ::/0
::/0
256K 24M loc_frwd all br-lan * ::/0
::/0
0 0 ACCEPT all * * ::/0
::/0 ctstate RELATED,ESTABLISHED
6559 682K Reject all * * ::/0
::/0
6559 682K LOG all * * ::/0
::/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:'
6559 682K reject all * * ::/0
::/0 [goto]

The question is of course, given that the DST address in that reject log message is a local address of the ip6tables machine, why is the packet being processed by the FORWARD chain?

I have put a "watch" on the interface to see if it's temporarily losing that address while those packets are being logged and rejected and I didn't see any evidence of such.

Any other ideas?

Cheers,
b.

#1 lore raw
Quoted 10 lines · Brian J. Murrell

I have a router running 2.6.32.27. It has an ip6 interface on it:

# ifconfig sixxs
sixxs     Link encap:IPv6-in-IPv4  
         inet6 addr: 2001:1234:f:107::2/64 Scope:Global
         inet6 addr: fe80::a08:1/64 Scope:Link
         inet6 addr: fe80::a4b:16fe/64 Scope:Link
         inet6 addr: fe80::ae8a:d6fb/64 Scope:Link
         inet6 addr: fe80::a4b:16c4/64 Scope:Link
         inet6 addr: fe80::43c1:d6f2/64 Scope:Link

Uh better use ip addr.

Quoted 8 lines

I have ip6tables rules installed (courtesy of Shorewall). It seems occasionally however that netfilter thinks that traffic that is (supposed to be) local is being forwarded:

Jul 19 06:44:41 10.75.22.196 kernel: Shorewall:FORWARD:REJECT:IN=sixxs

OUT=sixxs SRC=2001:1234:000f:0107:0000:0000:0000:0001 DST=2001:1234:000f:0107:0000:0000:0000:0002 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=19746 SEQ=16622

Routing determines whether it is forwarded or not - cf. ip route show table all, not Netfilter or Xtables.

Quoted 3 lines

I have put a "watch" on the interface to see if it's temporarily losing that address while those packets are being logged and rejected and I didn't see any evidence of such.

How do you watch it?

#2 lore raw
Quoted 2 lines · Jan Engelhardt

Uh better use ip addr.

Sure, next time since your hints helped me resolve this issue.

Quoted 2 lines

Routing determines whether it is forwarded or not - cf. ip route show table all, not Netfilter or Xtables.

Makes sense. That drove me to looking closer at the routing tables and it seemed that the scripts that bring up the ipv6 interface didn't plumb a local route so I restarted the interface and it seems to be there now.

Thanx for the friendly poke in the right direction. It was all I needed to figure out the problem.

b.