NetBSD Problem Report #25796

Received: (qmail 6185 invoked by uid 605); 3 Jun 2004 10:45:56 -0000
Message-Id: <20040603104553.DDA6C11152@narn.netbsd.org>
Date: Thu,  3 Jun 2004 10:45:53 +0000 (UTC)
From: arto@selonen.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: arto@selonen.org
To: gnats-bugs@gnats.NetBSD.org
Subject: tcpdump does not show all packets on gif(4)
X-Send-Pr-Version: www-1.0

>Number:         25796
>Category:       bin
>Synopsis:       tcpdump does not show all packets on gif(4)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 03 10:46:01 +0000 2004
>Closed-Date:    
>Last-Modified:  Sun Apr 26 19:51:36 +0000 2009
>Originator:     Arto Selonen
>Release:        NetBSD-current w/ sources ca. May 31st 2004
>Organization:
>Environment:
NetBSD blah 2.0F NetBSD 2.0F (BLAH) #40: Tue Jun  1 11:57:37 EEST 2004  blah@blah:/obj/sys/arch/i386/compile/BLAH i386

>Description:
While capturing packet traces for another problem (kern/25087) I noticed
that tcpdump output of a gif interface was not showing the same amount
of packets that I was expecting to see. Specifically, there is a
transport mode IPSEC tunnel between the problem system and another one:

   W<->(fxp1)GWD(fxp0)->(gif0)<==IPSEC==>(gif0)<-(ep0)GWS(ex0)<->CL

The problem system is GWD, and the problem traffic is CL making
a HTTP request to W. tcpdump is run on GWD for both fxp0 and gif0.

This is how gif0 is defined on GWD
# cat /etc/ifconfig.gif0
create
tunnel <ip-of-fxp0> <ip-of-ep0>
10.0.0.1 10.0.0.2 netmask 0xfffffffc

This is what /etc/ifconfig.fxp0 looks like on GWD:
<ip-of-fxp0> netmask 255.255.255.240 media auto
link0

# tcpdump -vvvi fxp0 -s 1500
                                                                                11:25:00.283368 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e56):                   ESP(spi=0x00000994,seq=0x14d4e56) (ttl 19, id 30042, len 132)                   
11:25:00.283820 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192a):             
ESP(spi=0x00000992,seq=0x192a) (ttl 30, id 47924, len 132)                      
11:25:00.291760 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e57):          
ESP(spi=0x00000994,seq=0x14d4e57) (ttl 19, id 30044, len 116)                   
11:25:00.333793 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e58):          
ESP(spi=0x00000994,seq=0x14d4e58) (ttl 19, id 30046, len 1364)                  
11:25:00.526469 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192b):             
ESP(spi=0x00000992,seq=0x192b) (ttl 30, id 47935, len 116)                      
11:25:00.542197 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e59):          
ESP(spi=0x00000994,seq=0x14d4e59) (ttl 19, id 30053, len 1364)                  
11:25:00.542409 GWS > GWD: AH(spi=0x00000995,sumlen=16,seq=0x14d4e5a):          
ESP(spi=0x00000994,seq=0x14d4e5a) (ttl 19, id 30054, len 532)                   
11:25:00.542837 GWD > GWS: AH(spi=0x00000993,sumlen=16,seq=0x192c):             
ESP(spi=0x00000992,seq=0x192c) (ttl 30, id 47936, len 116)                      

Due to checksum issues the HTTP transaction is not complete; the above
is as far as it gets before being stuck (that is kern/25087).

The problem with tcpdump is that since all the above packets go through
gif0, and this is the tcpdump output:

# tcpdump -vvvi gif0 -s 1500                                                    
                                                                                11:25:00.283764 W.www > 10.0.0.2.52192: S [tcp sum ok] 1255747952:1255747952(0) ack 306725568 win 61440 <mss 1460,nop,wscale 0> (ttl 59, id 3466, len 48)       
11:25:00.526408 W.www > 10.0.0.2.52192: . [tcp sum ok] 1:1(0) ack 1241 win 61440 (ttl 59, id 3558, len 40)                                                 
11:25:00.542808 W.www > 10.0.0.2.52192: . [tcp sum ok] 1:1(0) ack 2889 win 61440 (ttl 59, id 3565, len 40)                                                 

It only shows responses from W back to CL (which appears as 10.0.0.2,
since it is mapped by NAT in GWS to be from GWS; should not affect
tcpdump on GWD).

Why are there no packets from 10.0.0.2 in the gif0 tcpdump output?
Is tcpdump choosing not to show them for some reason, or is it the kernel hiding them?
>How-To-Repeat:
I have not tested with other systems whether this is simply related
to tcpdump/gif, or if there are other factors present (both systems run
ipfilter, both systems have internal systems behind them, there is
some NAT present on both ends to hide some internal systems, etc).

>Fix:

>Release-Note:
>Audit-Trail:

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:  
Subject: re: bin/25796
Date: Tue, 20 Jul 2004 14:12:30 +0300 (EEST)

 Hi!

 'netstat -i' only reports output packets for the gif(4) interface (at both
 ends of the connection). Furthermore, this seems to be related to just
 the gif interface used for the IPSEC transport mode tunnel setup,
 ie. other IPv4 gif-based tunnels seem to work OK.

 Maybe this is a kernel bug? Traffic seems to flow both ways just fine,
 but it is only accounted one way (output).


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:  
Subject: re: bin/25796
Date: Tue, 20 Jul 2004 14:06:06 +0300 (EEST)

 Hi!

 Box upgraded to 2.0G with anoncvs-fi mirror sources from ~20040719.
 No change; tcpdump only shows one direction of the gif(4) traffic.


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: tech-net@netbsd.org
Subject: Re: kern/25796 (IPSEC traffic is not for the receiver to see)
Date: Wed, 18 Aug 2004 12:31:36 +0300 (EEST)

 Hi!

 I've been trying to look at the source code to see why kern/25796
 occurs, and even with my *very limited* understanding of the inner
 workings of the IP stack, I think tcpdump (and friends) is not allowed
 to see any traffic that used to be IPSEC encapsulated.

 The part of code that I've been looking at is src/sys/netinet/ip_input.c,
 specifically this part:

 #ifdef PFIL_HOOKS
         /*
          * Run through list of hooks for input packets.  If there are any
          * filters which require that additional packets in the flow are
          * not fast-forwarded, they must clear the M_CANFASTFWD flag.
          * Note that filters must _never_ set this flag, as another filter
          * in the list may have previously cleared it.
          */
         /*
          * let ipfilter look at packet on the wire,
          * not the decapsulated packet.
          */
 #ifdef IPSEC
         if (!ipsec_getnhist(m))
 #elif defined(FAST_IPSEC)
         if (!ipsec_indone(m))
 #else
         if (1)
 #endif

 which was introduced on revision 1.127 on January 24th, 2001, so it is
 not new. It may be related to threads 'ipsec after nat', 'ipsec/tunnel for
 private spaces' on tech-net on January 2001. Message by itojun on
 tech-net announced it in 'ipsec/ipf interaction change'. I also
 understand, that the change was done to fix some real problem, so I'm not
 too keen to try to locally reverse that, either. What could I expect to
 break if I tried it the old way?

 I then read the following web page, that confirmed my interpretation
 at least partially:
 http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction

 So, since the traffic was at some point IPSEC-protected, it may not
 be shown to tcpdump, and friends? Sounds weird, but it explains
 this PR, so I guess this is not a bug, and this PR could be changed
 to a feature request. I think one should be able to see the traffic
 one receives. :)

 Personally, I can't figure out why ipf should not be allowed to mess
 with decapsulated data, provided that it shows up on another interface,
 like gif. That would allow one to write rules to filter the traffic
 properly, yet it would also guarantee that the packet was not spoofed,
 since to make it to gif, it would have had to be properly processed
 by the IPSEC stage (provided that the gif tunnel was properly configured).
 Or am I just missing something obvious?

 Of course, it would be much better if ipfilter (and friends) were
 ipsec-aware, so they could be allowed access to the packets just as
 they were prior to January 24th, 2001. Or, something like
 http://mail-index.netbsd.org/tech-net/2001/01/13/0008.html might
 take place?

 A totally separate issue is the gif interface incoming statistics.
 I can't understand why they don't get updated. Should that be filed
 as a separate PR, or is it related to the same design that caused
 kern/25796 ?


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: bin/25796 (no change after upgrade)
Date: Thu, 30 Sep 2004 13:19:59 +0300 (EEST)

 Hi!

 Box upgraded on 20040929 from whatever sources anoncvs-fi mirror gave
 at the time. Quick testing with the new tcpdump version still shows
 only outgoing traffic on the IPSEC-used gif-interface.

 In other words: still does not work.


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.
From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/25796 (still there)
Date: Thu, 25 Nov 2004 10:03:58 +0200 (EET)

 Hi!

 Box upgraded on 20041123 with whatever sources anoncvs-fi mirror gave.
 tcpdump still shows only outgoing traffic on the gif interface.
 'netstat -I gif0' only shows non-zero counters for outgoing traffic.


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/25796 (problem remains)
Date: Wed, 2 Feb 2005 09:33:29 +0200 (EET)

 Hi!

 All NetBSD-current systems related to producing the problem in this PR
 have been upgraded to 2.99.1x, yet the problem remains. No incoming 
 traffic is seen with tcpdump, no incoming traffic counters are incremented
 for the gif interface.


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/25796 (still there)
Date: Tue, 26 Apr 2005 13:02:37 +0300 (EEST)

 Hi!

 Box upgraded with whatever sources anoncvs-us2 mirror gave on 20050421.
 Tcpdump still shows only outgoing traffic on the gif interface.
 'netstat -I gif0' only shows non-zero counters for outgoing traffic.
 So, no change here.


 Artsi

 PS. It would be nice to have a user-feedback-request, so that eventually
      there was also some feedback from the other end as well, and not just
      from the reporting user. It's been ~10 months now, and nobody has
      acknowledge this in any way.
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FIN-02600 Espoo        arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

From: Arto Selonen <arto@selonen.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/25796 (still there)
Date: Tue, 25 Apr 2006 09:44:08 +0300 (EEST)

 Hi!

 Box upgraded with whatever sources anoncvs.netbsd.org gave on 
 20060420. Tcpdump still shows only outgoing traffic on the gif interface.
 'netstat -I gif0' only shows non-zero counters for outgoing traffic.
 So, no change here.


 Artsi
 -- 
 #######======------  http://www.selonen.org/arto/  --------========########
 Everstinkuja 5 B 35                               Don't mind doing it.
 FI-02600 Espoo         arto@selonen.org         Don't mind not doing it.
 Finland              tel +358 50 560 4826     Don't know anything about it.

Responsible-Changed-From-To: bin-bug-people->pavel
Responsible-Changed-By: pavel@netbsd.org
Responsible-Changed-When: Sun, 02 Jul 2006 11:01:06 +0000
Responsible-Changed-Why:
I would like to look at it one day.


Responsible-Changed-From-To: pavel->bin-bug-people
Responsible-Changed-By: spz@NetBSD.org
Responsible-Changed-When: Sun, 26 Apr 2009 19:51:36 +0000
Responsible-Changed-Why:
pavel resigned, reassign back to default


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.