[nycbug-talk] [Fwd: tunnel help request]

[Okan Demirmen]

On Tue 2007.10.30 at 15:04 -0400, nikolai wrote:
> Added these two to my pf.conf
> Here's updated config:
> 
> ~$ cat /etc/hostname.gif0
> tunnel 67.86.49.123 209.51.161.14
> inet6 2001:470:1f06:ad::2
> !route add -inet6 default 2001:470:1f06:ad::1
> 
> ~$ cat /etc/hostname.re0
> inet 192.168.2.1 255.255.255.0 192.168.2.255 media autoselect
> inet6 2001:470:1f07:ad::1 64

i'd use an alias for inet6: "inet6 alias 2001:470:1f07:ad::1 64"

> re0 - internal, fxp0 - external
> 
> gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
>         groups: gif
>         physical address inet 67.86.49.123 --> 209.51.161.14
>         inet6 fe80::2c0:a8ff:fefd:2a69%gif0 ->  prefixlen 64 scopeid 0x6
>         inet6 2001:470:1f06:ad::2 ->  prefixlen 64
> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         lladdr 00:0e:2e:a9:0d:11
>         media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
>         status: active
>         inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
>         inet6 fe80::20e:2eff:fea9:d11%re0 prefixlen 64 scopeid 0x2
>         inet6 2001:470:1f07:ad::1 prefixlen 64
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         lladdr 00:c0:a8:fd:2a:69
>         groups: egress
>         media: Ethernet autoselect (100baseTX full-duplex)
>         status: active
>         inet6 fe80::2c0:a8ff:fefd:2a69%fxp0 prefixlen 64 scopeid 0x1
>         inet 67.86.49.123 netmask 0xfffff000 broadcast 255.255.255.255

ok...

[snip inet6 route table]

> ~$ ping6  -n 2001:470:1f06:ad::1
> PING6(56=40+8+8 bytes) 2001:470:1f06:ad::2 --> 2001:470:1f06:ad::1
> 
> --- 2001:470:1f06:ad::1 ping6 statistics ---
> 4 packets transmitted, 0 packets received, 100.0% packet loss

for now, re0 is not important, for you should be able to just ping6 the
other end with just the gif0 interface.

for the record, i can ping6 your gateway of 2001:470:1f06:ad::1, so that
bit at least is working on HE's end.

> And here's what I see on the external if:
> 
> Oct 30 14:56:08.858930 00:c0:a8:fd:2a:69 00:05:00:e6:67:db 0800 98:
> 2001:470:1f06:ad::2 > 2001:470:1f06:ad::1: [|icmp6] (encap)
> Oct 30 14:56:11.574816 00:c0:a8:fd:2a:69 00:05:00:e6:67:db 0800 90:
> 2001:470:1f06:ad::2 > 2001:470:1f06:ad::1: icmp6: echo request (encap)
> Oct 30 14:56:12.579103 00:c0:a8:fd:2a:69 00:05:00:e6:67:db 0800 90:
> 2001:470:1f06:ad::2 > 2001:470:1f06:ad::1: icmp6: echo request (encap)
> Oct 30 14:56:13.569088 00:c0:a8:fd:2a:69 00:05:00:e6:67:db 0800 90:
> 2001:470:1f06:ad::2 > 2001:470:1f06:ad::1: icmp6: echo request (encap)

you having a log statement in pf, can you see what is being blocked,
tcpdump -n -i pflog0 ?

not only does one need to let the inet ip6 proto, now you need to allow
actually inet6, in this case icmp6 - check pflog0 to verify.

...but if that's a tcpdump on the outside interface, you should at least
see the encap packet coming back, even though it may be stopped by pf
later...then again, what's pf doing with gif0?  maybe just set skip or
quick it for testing, to make sure it's not in the way...