Date: Thu, 03 May 2001 10:12:27 -0700 From: Lars Eggert <larse@ISI.EDU> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Erik Salander <erik@whistle.com>, freebsd-net@FreeBSD.ORG Subject: Re: gifs and tcpdump Message-ID: <3AF1917B.2AC0E900@isi.edu> References: <3AF0B57B.4D789393@whistle.com> <200105031311.f43DB9711069@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] "Louis A. Mamakos" wrote: > > Should I be able to "tcpdump -i gif0"? tcpdump indicates it's listening > > on gif0 but I never capture anything. Yes, you should. If you send traffic over it, but from what Louis wrote, maybe you don't. > Traffic going over an ESP tunnel never actual transits the tunnel > interface. In fact, if you arrange to have the right routes installed, > you don't even need the gif interface at all. From some recent experiments > I've done, the gif interface seems to be used only for: > > - side effect of installed host routes which are needed when > matching the IPSEC policy specification > > - carrying traffic that isn't matching the IPSEC policy specification > (if there is any at all) Gif interfaces are for IPIP tunnels. Using them in parallel with IPsec tunnels to trick routing into sending traffic over an SA is a bad hack IMHO. Also, depending on the order you set up tunnels and SAs, you may see strange effects. > I found this very counter intuitive; however, if you do a tcpdump on the > physical interface carrying the tunnel traffic, you'll see that the IPSEC > traffic isn't in an ipip encapsulation at all. Exactly, it is "IPsec tunnel mode" (type 50 or 51 packet with a type 4 packet inside), which is different from IPIP (type 4 packet with a type 4 packet inside). > Yes, I found this very counter-intuititve. From what I can tell, there's > no easy way to do a tcpdump and see the unencrypted traffic as it exits > the IPSEC tunnel. What I may try next is to specify a transport-mode > IPSEC policy that covers the gif interface tunnel endpoints, but I don't > know if that wll work or not. It works, and makes routing much cleaner, since now the tunnel devices represented in the routing table are the ones that actually carry the traffic. There's an ID that has more information on this: ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-01.txt Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California [-- Attachment #2 --] 0# *H 01 0 + 0 *H 00A#0 *H 01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.160 000824203008Z 010824203008Z0T10 UEggert1 0 U*Lars10U Lars Eggert1 0 *H larse@isi.edu00 *H 0 \p9 H;v r∩6"C?mxfJ f7I[3CF́L I - zHRVA怤2]0-bL)%X>nӅ w0u0*+e!0 00L2uMyffBNUbNJJcdZ2s0U 0 larse@isi.edu0 U 0 0 U #0`fUXF a#Ì0 *H _3 F=%nWY-HXD9UOc6ܰw f@uܶNԄR?Pr} E1֮23 mFhySwM_h|d yR= $P 00} 0 *H 01 0 UZA10U Western Cape10U Cape Town10U Thawte Consulting1(0&U Certification Services Division1$0"UThawte Personal Freemail CA1+0) *H personal-freemail@thawte.com0 990916140140Z 010915140140Z01 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.1600 *H 0 iZ z]!#rLK~r$BRW{azr98e^eyvL>hpu t ,O 1ArƦ]D.Mօ>lx~@эWs0FO 7050U 0 0 U #0rIs4U vr~wƲ0 *H kY1rr`HU{gapm¥7؝(V\uoƑlfq|ko!6- -mƃRt\~ orzg,ks n Νc) ~U10001 0 UZA10U Western Cape10U Durbanville10 U Thawte1 0U Certificate Services1(0&U Personal Freemail RSA 1999.9.16#0 + 0 *H 1 *H 0 *H 1 010503171227Z0# *H 145 'ȊV@ayxn0R *H 1E0C0 *H 0*H 0+0 *H @0 *H (0 *H :Z 3twyى$HM"rg|3}S Xss!o a ]K='@CȶZV +4s`363M&v"Q G #%noEk&*T(ղ=$F
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AF1917B.2AC0E900>