Date: Tue, 25 Jan 2005 18:11:20 +0100 From: Jeremie Le Hen <jeremie@le-hen.org> To: Nickolay Kritsky <Nickolay.Kritsky@astra-sw.com> Cc: Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: gif(4) and bpf(4) Message-ID: <20050125171120.GH59685@obiwan.tataz.chchile.org> In-Reply-To: <D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com> References: <D86BF562467D944EB435513F725B236A07C122@exchange.stardevelopers4msi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Please do the following:
>
> ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
> netstat -I gif0 -w 1
> and see if any packets are counted.
Weirdly, although I get the ICMP echo-reply, the gif0 interface are
not updated.
%%%
yoda:sys# ping -qc 1 -r -S 192.168.1.1 192.168.4.13
PING 192.168.4.13 (192.168.4.13) from 192.168.1.1: 56 data bytes
--- 192.168.4.13 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 56.012/56.012/56.012/0.000 ms
yoda:sys# ping -r -S 192.168.1.1 192.168.4.13 >/dev/null 2>&1 &
[1] 63114
yoda:sys# netstat -I gif0 -w 1
input (gif0) output
packets errs bytes packets errs bytes colls
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
^C
%%%
> If you are using IPSec, maybe your packets are encrypted before they go
> to gif. See this article:
> http://groups-beta.google.com/group/sol.lists.freebsd.net/browse_frm/thread/de878d5a36d383f1/ffa608ca991d0c3c?q=tcpdump+gif+freebsd&_done=%2Fgroups%3Fq%3Dtcpdump+gif+freebsd%26&_doneTitle=Back+to+Search&&d#ffa608ca991d0c3c
I prefer this one ;-) :
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=236856+0+archive/2001/freebsd-net/20010506.freebsd-net
Ok, you got it !
In fact, I'm aware that using a gif(4) tunnel and IPSec transport mode is
merely the same as IPSec tunnel mode only and that gif(4) with tunnel mode
is useless, but when I set up my IPSec tunnel, we wanted to have it as
quick as possible, my friend insisted to use gif(4)+tunnel mode, so I did
it. I was planning to change this later back to gif(4)+transport mode
because I believed that the IPSec tunnel was *inside* the gif(4) tunnel,
thus consuming too much bandwidth. In fact it appeared that my gif(4)
interface is totally useless in my setup. I'm going to switch to
transport mode ASAP and tell my friend he owes me and you all a beer.
> Can you post your IPSec policy (with sensitive info removed, of course).
Of course, although this is useless now. Here it is anyway:
%%%
yoda:sys# setkey -DP
192.168.4.0/24[any] 192.168.1.0/24[any] any
in ipsec
esp/tunnel/yy.yy.yy.yy-xx.xx.xx.xx/require
spid=7 seq=1 pid=63145
refcnt=1
192.168.1.0/24[any] 192.168.4.0/24[any] any
out ipsec
esp/tunnel/xx.xx.xx.xx-yy.yy.yy.yy/require
spid=8 seq=0 pid=63145
refcnt=1
%%%
> (Google rulez :-) )
I used Google (but not Google Groups) to look for various strings :
"tcpdump gif0", "gif bpf", ... restricting the search to
site:lists.freebsd.org but I didn't found this post. If I did, I
wouldn't have wasted bandwidth for this thread. I'm sorry. At least,
I hope this will be useful later for someone else. This thread is
after all a bunch of concentrated informations about gif(4) debugging
and IPSec.
Many, many thanks to Bruce and Nickolay, as well as Alex who got the
point too.
Best regards,
--
Jeremie Le Hen
jeremie@le-hen.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050125171120.GH59685>