Problem with tunnel

Greg33 · October 26, 2009, 12:52:43 PM

but the routing was not manually set by me, I try to change

Greg33 · October 26, 2009, 01:03:52 PM

routing changed but unfortunately still not works, it is very strange :)

Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0 =>
default gif1 ULS gif1
::1 ::1 UHL lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
2001:470:1f0a:a08::/64 gif1 ULS gif1
2001:470:1f0a:a08::2 link#8 UHL lo0
2001:470:1f0a:a08::3 00:0d:b9:19:23:3c UHL lo0
fe80::/10 ::1 UGRS lo0
fe80::%vr0/64 link#1 UC vr0
fe80::20d:b9ff:fe19:233c%vr0 00:0d:b9:19:23:3c UHL lo0
fe80::%vr1/64 link#2 UC vr1
fe80::20d:b9ff:fe19:233d%vr1 00:0d:b9:19:23:3d UHL lo0
fe80::%vr2/64 link#3 UC vr2
fe80::20d:b9ff:fe19:233e%vr2 00:0d:b9:19:23:3e UHL lo0
fe80::%ath0/64 link#4 UC ath0
fe80::221:27ff:fecc:604f%ath0 00:21:27:cc:60:4f UHL lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#6 UHL lo0
fe80::%gif1/64 link#8 UC gif1
fe80::20d:b9ff:fe19:233c%gif1 link#8 UHL lo0
ff01:1::/32 link#1 UC vr0
ff01:2::/32 link#2 UC vr1
ff01:3::/32 link#3 UC vr2
ff01:4::/32 link#4 UC ath0
ff01:6::/32 ::1 UC lo0
ff01:8::/32 link#8 UC gif1
ff02::/16 ::1 UGRS lo0
ff02::%vr0/32 link#1 UC vr0
ff02::%vr1/32 link#2 UC vr1
ff02::%vr2/32 link#3 UC vr2
ff02::%ath0/32 link#4 UC ath0
ff02::%lo0/32 ::1 UC lo0
ff02::%gif1/32 link#8 UC gif1

jimb · October 26, 2009, 07:19:02 PM

I think your initial problem might have been the fact that you were using the wrong prefix length for your IPv6 tunnel interface, /128 when it should have been /64.

Go over your HE address assignments. They will give you an IPv6 IP for your tunnel interface, and a different one for your routed /64. They are both /64s. Make sure you're putting the right addresses on the right interfaces. Your tunnel interface should get the tunnel address, and the routed /64 can go on your "inside" interface.

Greg33 · October 27, 2009, 01:44:42 AM

I tried already different configurations, and nothing worked. These are allocated addresses from HE could You help me configure it ?

Server IPv4 address:    216.66.80.30
Server IPv6 address:    2001:470:1f0a:a08::1/64
Client IPv4 address:    83.143.43.59
Client IPv6 address:    2001:470:1f0a:a08::2/64
Anycasted IPv6 Caching Nameserver:   2001:470:20::2
Anycasted IPv4 Caching Nameserver:   74.82.42.42
Routed /48:    2001:470:a013::/48
Routed /64:    2001:470:1f0b:a08::/64

jimb · October 27, 2009, 04:47:49 AM

All I can say is to make sure that the address 2001:470:1f0a:a08::2/64 is only on your tunnel interface. In your netstat I see another 2001:470:1f0a:a08::3 of that IPv6 associated with the loopback interface. That shouldn't be. The client tunnel subnet should only be on the tunnel.

Other than that, the only thing I can think of is a firewall or other security feature on your box is blocking the traffic, or your ISP or something else is blocking the 6in4 traffic.

cholzhauer · October 27, 2009, 04:55:16 AM

QuoteIn your netstat I see another 2001:470:1f0a:a08::3 of that IPv6 associated with the loopback interface. That shouldn't be.

Yep, that was my fault. Not sure what I was thinking.

In /etc/rc.conf, replace this line ipv6_prefix_rv0="2001:470:1f0a:a08::3" with this line ipv6_prefix_rv0="2001:470:a013:0000"

Greg33 · October 27, 2009, 09:46:01 AM

Still the same problem, maybe my ISP filtering something :(

ipv6_network_interfaces="vr0 gif1 lo0"
ipv6_gateway_enable="YES"
ipv6_prefix_vr0="2001:470:a013:0000"
gif_interfaces="gif1"
gifconfig_gif1="83.143.43.59 216.66.80.30"
ipv6_ifconfig_gif1="2001:470:1f0a:a08::2/64"
ipv6_defaultrouter="-interface gif1"

Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0 =>
default gif1 ULS gif1
::1 ::1 UHL lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
2001:470:1f0a:a08::/64 link#8 UC gif1
2001:470:1f0a:a08::2 link#8 UHL lo0
2001:470:a013:: 00:0d:b9:19:23:3c UHL lo0 =>
2001:470:a013::/64 link#1 UC vr0
2001:470:a013:0:20d:b9ff:fe19:233c 00:0d:b9:19:23:3c UHL lo0
fe80::/10 ::1 UGRS lo0
fe80::%vr0/64 link#1 UC vr0
fe80::20d:b9ff:fe19:233c%vr0 00:0d:b9:19:23:3c UHL lo0
fe80::%vr1/64 link#2 UC vr1
fe80::20d:b9ff:fe19:233d%vr1 00:0d:b9:19:23:3d UHL lo0
fe80::%vr2/64 link#3 UC vr2
fe80::20d:b9ff:fe19:233e%vr2 00:0d:b9:19:23:3e UHL lo0
fe80::%ath0/64 link#4 UC ath0
fe80::221:27ff:fecc:604f%ath0 00:21:27:cc:60:4f UHL lo0
fe80::%lo0/64 fe80::1%lo0 U lo0
fe80::1%lo0 link#6 UHL lo0
fe80::%gif1/64 link#8 UC gif1
fe80::20d:b9ff:fe19:233c%gif1 link#8 UHL lo0
ff01:1::/32 link#1 UC vr0
ff01:2::/32 link#2 UC vr1
ff01:3::/32 link#3 UC vr2
ff01:4::/32 link#4 UC ath0
ff01:6::/32 ::1 UC lo0
ff01:8::/32 link#8 UC gif1
ff02::/16 ::1 UGRS lo0
ff02::%vr0/32 link#1 UC vr0
ff02::%vr1/32 link#2 UC vr1
ff02::%vr2/32 link#3 UC vr2
ff02::%ath0/32 link#4 UC ath0
ff02::%lo0/32 ::1 UC lo0
ff02::%gif1/32 link#8 UC gif1

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC>
   ether 00:0d:b9:19:23:3c
   inet6 fe80::20d:b9ff:fe19:233c%vr0 prefixlen 64 scopeid 0x1
   inet 83.143.43.59 netmask 0xffffff00 broadcast 83.143.43.255
   inet6 2001:470:a013:0:20d:b9ff:fe19:233c prefixlen 64
   inet6 2001:470:a013:: prefixlen 64 anycast
   media: Ethernet autoselect (100baseTX <full-duplex>)
   status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
   inet 127.0.0.1 netmask 0xff000000
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33204
gif1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
   tunnel inet 83.143.43.59 --> 216.66.80.30
   inet6 fe80::20d:b9ff:fe19:233c%gif1 prefixlen 64 scopeid 0x8
   inet6 2001:470:1f0a:a08::2 prefixlen 64

cholzhauer · October 27, 2009, 10:27:22 AM

Everything looks fine to me.

You're not blocking protocol 41 anywhere? What does tcpdump show?

Greg33 · October 27, 2009, 10:37:58 AM

ping6 2001:470:1f0a:a08::1

tcpdump: WARNING: gif1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif1, link-type NULL (BSD loopback), capture size 96 bytes
18:29:26.335024 IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 0, length 16
18:29:27.335098 IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 1, length 16
18:29:28.334697 IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 2, length 16

tcpdump -ni vr0 host 216.66.80.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr0, link-type EN10MB (Ethernet), capture size 96 bytes
18:29:26.335202 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 0, length 16
18:29:27.335128 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 1, length 16
18:29:28.334729 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:470:1f0a:a08::1: ICMP6, echo request, seq 2, length 16

ping6 ipv6.google.com
tcpdump -ni gif1
tcpdump: WARNING: gif1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif1, link-type NULL (BSD loopback), capture size 96 bytes
18:30:37.998292 IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 0, length 16
18:30:38.998415 IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 1, length 16
18:30:39.998236 IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 2, length 16

tcpdump -ni vr0 host 216.66.80.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr0, link-type EN10MB (Ethernet), capture size 96 bytes
18:30:37.998341 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 0, length 16
18:30:38.998446 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 1, length 16
18:30:39.998266 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:4860:a005::68: ICMP6, echo request, seq 2, length 16

ping my IPv6 2001:470:1f0a:a08::2 from http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php

PING 2001:470:1f0a:a08::2(2001:470:1f0a:a08::2) 32 data bytes
--- 2001:470:1f0a:a08::2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms

tcpdump -ni gif1
tcpdump: WARNING: gif1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gif1, link-type NULL (BSD loopback), capture size 96 bytes
18:31:52.818923 IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 0, length 40
18:31:52.819028 IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 0, length 40
18:31:53.819208 IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 1, length 40
18:31:53.819324 IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 1, length 40
18:31:54.817239 IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 2, length 40
18:31:54.817344 IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 2, length 40
18:31:55.819817 IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 3, length 40
18:31:55.819930 IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 3, length 40

tcpdump -ni vr0 host 216.66.80.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr0, link-type EN10MB (Ethernet), capture size 96 bytes
18:31:52.818886 IP 216.66.80.30 > 83.143.43.59: IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 0, length 40
18:31:52.819056 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 0, length 40
18:31:53.819169 IP 216.66.80.30 > 83.143.43.59: IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 1, length 40
18:31:53.819356 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 1, length 40
18:31:54.817201 IP 216.66.80.30 > 83.143.43.59: IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 2, length 40
18:31:54.817375 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 2, length 40
18:31:55.819780 IP 216.66.80.30 > 83.143.43.59: IP6 2001:1af8:4200:b000:20c:29ff:fe6b:49d2 > 2001:470:1f0a:a08::2: ICMP6, echo request, seq 3, length 40
18:31:55.819957 IP 83.143.43.59 > 216.66.80.30: IP6 2001:470:1f0a:a08::2 > 2001:1af8:4200:b000:20c:29ff:fe6b:49d2: ICMP6, echo reply, seq 3, length 40

And this is very strange becasue there is traffic in and out but the icmp don't reach the target

Greg33 · October 27, 2009, 10:39:31 AM

My pf.rules are clear, is only nat for localnet.

snarked · October 27, 2009, 11:58:16 AM

Did you bother to read reply #7?

Greg33 · October 27, 2009, 12:27:41 PM

Yes, I tried

ifconfig gif1 inet 192.168.4.1 netmask 255.255.255.255
ifconfig: ioctl (SIOCAIFADDR): Destination address required

jimb · October 28, 2009, 04:17:22 AM

Quote from: Greg33 on October 27, 2009, 12:27:41 PM
Yes, I tried

ifconfig gif1 inet 192.168.4.1 netmask 255.255.255.255
ifconfig: ioctl (SIOCAIFADDR): Destination address required

I think he means assign the IPv4 address for your outside interface (83.143.43.59/32) to the gif0 interface also, not just as a tunnel endpoint address, but as an interface address too. Must be some sort of BSD retardation. :P

What's odd is that you can see the traffic from the pings from that web site coming to your 6in4 interface, and the associated 6in4 traffic from the tunnel server. But your outgoing pings generate no 6in4 replies from the tunnel server. It's almost is if outgoing 6in4 traffic is being blocked further down the line.

I'd double and triple check your BSD boxes firewall and other security settings. BSD tends to be pretty "locked down" from the factory. Perhaps IPv6 uses a separate instance of pf than IPv4 (although the tcpdump show the traffic going out). Also, if there are further network firewalls on the path to your ISP, make sure they allow 6in4 (IP proto 41).

EDIT: Perhaps as an experiment, you might want to try setting up a 6in4 tunnel with local computer, perhaps on a different subnet, just to make sure it's not BSD being stupid. Then, try setting one up with a friend outside your ISP. That way you can both monitor the traffic to see if the 6in4 traffic is actually making it out for your BSD box and/or ISP.

cholzhauer · October 28, 2009, 05:01:18 AM

FWIW, I didn't have to assign my public IP address to my gif interface. And yes, there are a different set of PF rules for IPv6 then are used for IPv4. Out of the box, there is no firewall installed on FreeBSD and it didn't take me a whole lot of work to get mine working (once I figured out the correct /etc/rc.conf settings)

Greg33 · October 28, 2009, 11:41:13 AM

Thank you for your help.
I wrote to HE support and got message that they didn't see traffic from my side of the tunnel, so I think the problem is with my ISP.

Greg

News:

Problem with tunnel