Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Sep 2011 10:21:14 -0400
From:      Gary Palmer <gpalmer@freebsd.org>
To:        Matt Smith <matt@xtaz.co.uk>
Cc:        freebsd-net@freebsd.org
Subject:   Re: gif interface not passing IPv6 packets
Message-ID:  <20110926142114.GC57708@in-addr.com>
In-Reply-To: <CAD0n1vFB6h9h%2BBe9DOCwxi9aECBvkTvf8g7C_tsQxXXFv90XKw@mail.gmail.com>
References:  <CAD0n1vG0fvHMkBxxLRq0Y%2Bx9rDt5AXb4WZhq-oxuqpti4mQC7w@mail.gmail.com> <20110926132923.GB57708@in-addr.com> <CAD0n1vFB6h9h%2BBe9DOCwxi9aECBvkTvf8g7C_tsQxXXFv90XKw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 26, 2011 at 02:49:15PM +0100, Matt Smith wrote:
> On 26 September 2011 14:29, Gary Palmer <gpalmer@freebsd.org> wrote:
> > On Mon, Sep 26, 2011 at 10:27:53AM +0100, Matt Smith wrote:
> > Do you have access to any other IPv6 hosts on a separate link? ?If so,
> > I would suggest trying a ping or traceroute back to your IP or
> > IPs across the tunnel and see if the packets are getting back to you.
> > It may be a problem at the other end somewhere. ?Check with tcpdump
> > of both the IPv4 and IPv6 layers to see if the packets are getting
> > to the kernel but not to the gif interface. ?Also see if your router
> > is passing packets. ?If you had a power cut the router may have had
> > some issues and may not be passing the protocol 41 packets.
> >
> > Also, check the sixxs.net docs to make sure you're allowing through
> > necessary packets. ?I use tunnelbroker.net and they require (or say
> > they do) some packets to get through for the tunnel to stay up, e.g.
> > an IPv4 ping.
> >
> 
> The router is configured to just send all incoming traffic to
> 192.168.1.2, DMZ mode. This includes all protocols. I then use ipfw on
> the server to firewall it, though even flushing all rules and
> completely opening the firewall it still doesn't work. I think you're
> missing the main issue I have here, which is that the local side
> doesn't work. If the local side doesn't work then the remote side is
> irrelevant right now.
> 
> Point is try this on any FreeBSD box and it will work (I did this
> earlier today on a friends FreeBSD server to verify):
> 
> ifconfig gif0 create
> ifconfig gif0 tunnel <local_lan_ip> 1.2.3.4
> ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
> ping6 2abc::2
> ifconfig gif0 destroy
> 
> With that config you should be able to talk locally to 2abc::2 because
> that's just a local IP on your box. The rest of the config or the
> state of the internet connection/NAT etc doesn't matter because you're
> talking to a non existent IP anyway.
> 
> On my box this doesn't work since the power cut but worked perfectly
> well before. tcpdump of gif0 shows ping requests but no ping
> responses. It's as if all IPv6 traffic into gif0 is blackholed.
> However if I configure an IPv4 address on it with ifconfig gif0
> 10.1.1.2 10.1.1.1 then I can happily ping 10.1.1.2. So this just
> affects IPv6.

Sorry, I missed that as I didn't look closely enough at the IP
you were pinging and with DNS resolution left on in the tcpdump
I just assumed that sixxs.net has a weird DNS setup.

Smells like a routing table problem or similar configuration problem. 
On my tunnel endpoint, admitedly running 7.4 not 8.x or head, pings
to the LOCAL endpoint of the gif0 tunnel go over lo0, not the external
interface (gif0).  I believe that is true for all IPv4 or IPv6 traffic.

e.g.

# ifconfig gif0 
ifconfig: interface gif0 does not exist
# ifconfig gif0 create
# ifconfig gif0 tunnel 10.10.242.10 1.2.3.4
# ifconfig gif0 inet6 2abc::2 2abc::1 prefixlen 128
# ping6 2abc::2
PING6(56=40+8+8 bytes) 2abc::2 --> 2abc::2
16 bytes from 2abc::2, icmp_seq=0 hlim=64 time=0.290 ms
16 bytes from 2abc::2, icmp_seq=1 hlim=64 time=0.183 ms
^C
--- 2abc::2 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.183/0.236/0.290/0.054 ms

# ifconfig gif0 destroy

In another window on the same host

# tcpdump -n -p -i lo0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
15:18:20.611469 IP6 2abc::2 > 2abc::2: ICMP6, echo request, seq 0, length 16
15:18:20.611524 IP6 2abc::2 > 2abc::2: ICMP6, echo reply, seq 0, length 16
15:18:21.611673 IP6 2abc::2 > 2abc::2: ICMP6, echo request, seq 1, length 16
15:18:21.611752 IP6 2abc::2 > 2abc::2: ICMP6, echo reply, seq 1, length 16
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Regards,

Gary



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110926142114.GC57708>