Forum - PoP IPv6 doesn't ping :: SixXS - IPv6 Deployment & Tunnel Broker

PoP IPv6 doesn't ping

Shadow Hawkins on Sunday, 24 February 2013 20:29:43

I suspect that the issue is trivial, yet I can't find out what's wrong. Could you please help me? Issue: IPv6 PoP address doesn't respond to ping. Setting: tunnel: T117710 PoP: ruled01 OS:

$ uname -sr FreeBSD 9.1-STABLE

interfaces configured:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 91.202.110.44 --> 77.109.111.178 inet6 fe80::201:3ff:fe1e:f5cf%gif0 prefixlen 64 scopeid 0xe inet6 2a02:578:5002:b4::2 --> 2a02:578:5002:b4::1 prefixlen 128 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> options=1<ACCEPT_REV_ETHIP_VER> xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82009<RXCSUM,VLAN_MTU,WOL_MAGIC,LINKSTATE> ether 00:26:18:9a:f8:e0 inet6 2a02:578:5002:80b4::1 prefixlen 64 inet6 fe80::201:3ff:fe1e:f5cf%xl0 prefixlen 64 scopeid 0x4 inet 172.17.128.12 netmask 0xffffff00 broadcast 172.17.128.255 inet 91.202.110.44 netmask 0xffffff00 broadcast 91.202.110.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet 10baseT/UTP status: active

settings in /etc/rc.conf:

## ## IPv6 ## # tunnel gif_interfaces="gif0" gifconfig_gif0="91.202.110.44 77.109.111.178" ifconfig_gif0_ipv6="inet6 2a02:578:5002:b4::2 2a02:578:5002:b4::1 prefixlen 128" ipv6_defaultrouter="2a02:578:5002:b4::1" # gateway ipv6_gateway_enable="YES" rtadvd_enable="YES" rtadvd_interfaces="xl0" ifconfig_xl0_ipv6="inet6 2a02:578:5002:80b4::1 prefixlen 64"

/etc/rtadvd.conf:

xl0:\ :addrs#1:addr="2a02:578:5002:80b4::":prefixlen#64:tc=ether:

pf rules:

##### SixXS tunnel rules ###### pass quick on gif0 inet all pass quick on gif0 inet6 proto icmp6 all pass out quick on gif0 inet6 all # allow heartbeat ping pass in log quick on gif0 inet6 proto { ipv6-icmp } from 2a02:578:5002:b4::1 to # pass tcp, udp, and gif0 out on the ipv6 tunnel interface. pass out log quick on gif0 inet6 proto { tcp udp ipv6-icmp} keep state

inet6 routing table:

netstat -rn -finet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2a02:578:5002:b4::1 UGS gif0 ::1 link#13 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2a02:578:5002:b4::1 link#14 UH gif0 2a02:578:5002:b4::2 link#14 UHS lo0 2a02:578:5002:80b4::/64 link#4 U xl0 2a02:578:5002:80b4::1 link#4 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%xl0/64 link#4 U xl0 fe80::201:3ff:fe1e:f5cf%xl0 link#4 UHS lo0 fe80::%rl0/64 link#5 U rl0 fe80::206:4fff:fe76:854f%rl0 link#5 UHS lo0 fe80::%rl1/64 link#6 U rl1 fe80::2a1:b0ff:fe11:da75%rl1 link#6 UHS lo0 fe80::%rl2/64 link#8 U rl2 fe80::2a1:b0ff:fe11:1ac4%rl2 link#8 UHS lo0 fe80::%lo0/64 link#13 U lo0 fe80::1%lo0 link#13 UHS lo0 fe80::%gif0/64 link#14 U gif0 fe80::201:3ff:fe1e:f5cf%gif0 link#14 UHS lo0 fe80::%wlan0/64 link#15 U wlan0 fe80::56e6:fcff:fec7:ac5%wlan0 link#15 UHS lo0 ff01::%xl0/32 2a02:578:5002:80b4::1 U xl0 ff01::%rl0/32 fe80::206:4fff:fe76:854f%rl0 U rl0 ff01::%rl1/32 fe80::2a1:b0ff:fe11:da75%rl1 U rl1 ff01::%rl2/32 fe80::2a1:b0ff:fe11:1ac4%rl2 U rl2 ff01::%lo0/32 ::1 U lo0 ff01::%gif0/32 fe80::201:3ff:fe1e:f5cf%gif0 U gif0 ff01::%wlan0/32 fe80::56e6:fcff:fec7:ac5%wlan0 U wlan0 ff02::/16 ::1 UGRS lo0 ff02::%xl0/32 2a02:578:5002:80b4::1 U xl0 ff02::%rl0/32 fe80::206:4fff:fe76:854f%rl0 U rl0 ff02::%rl1/32 fe80::2a1:b0ff:fe11:da75%rl1 U rl1 ff02::%rl2/32 fe80::2a1:b0ff:fe11:1ac4%rl2 U rl2 ff02::%lo0/32 ::1 U lo0 ff02::%gif0/32 fe80::201:3ff:fe1e:f5cf%gif0 U gif0 ff02::%wlan0/32 fe80::56e6:fcff:fec7:ac5%wlan0 U wlan0

P.S. I doubt that problem is in pf rules, 'cause even after

pfctl -d

I was not able to ping PoP's IPv6 address.

PoP IPv6 doesn't ping

Jeroen Massar SixXS Staff

on Monday, 25 February 2013 07:58:47

xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

inet 172.17.128.12 netmask 0xffffff00 broadcast 172.17.128.255

inet 91.202.110.44 netmask 0xffffff00 broadcast 91.202.110.255

You have both a public and an RFC1918 address there? is that really correct? IPv6 interfaces/routes look okay from a cursory glance.

pf rules:

##### SixXS tunnel rules ######

Are there any other rules and what is the default policy?

pass quick on gif0 inet all

pass quick on gif0 inet6 proto icmp6 all

pass out quick on gif0 inet6 all

# allow heartbeat ping

Please note that 'heartbeat' in the SixXS context has nothing to do with ICMPv6. It is a separate protocol.

pass in log quick on gif0 inet6 proto { ipv6-icmp } from 2a02:578:5002:b4::1 to

If you explicitly need to allow that ICMP then you are likely blocking other ICMP and you will break things because of that.

# pass tcp, udp, and gif0 out on the ipv6 tunnel interface.

pass out log quick on gif0 inet6 proto { tcp udp ipv6-icmp} keep state

You are keeping state here, thus everything else will be broken.

P.S. I doubt that problem is in pf rules, 'cause even after

pfctl -d

I was not able to ping PoP's IPv6 address.

It completely depends on what your default policy is. Also, nodes in between you and the PoP might also filter. What does a traceroute to the PoP look like? Also check the Live Tunnel Status on the tunnel page, you'll see that the PoP has not received a single proto-41 packet yet.

PoP IPv6 doesn't ping

Shadow Hawkins on Monday, 25 February 2013 18:02:59

You have both a public and an RFC1918 address there? is that really correct?

Not sure; seems like it was something was broken by the time I made that alias (possibly, my understanding of things). Thanks for tip - I'll fix that.

what is the default policy?

Default pf policy:

block all

Already tried to change that to "pass all"; when that didn't help - disabled pf. Didn't help.

Are there any other rules

ehm... ok. But don't laugh to loudly, please) [self-justification]They were written something about 3 years ago. Surely, I tried to bring them to order... to some kind of order, at least.[/self-justification] For now on rules are:

block all antispoof quick for $ext_if block drop in log quick on $ext_if proto tcp from any to any port smtp block quick from <BRUTEFORCERS> pass out all pass in on wlan0 all pass in on rl0 all pass in on rl1 all pass in on rl2 all anchor "ftp-proxy/*" pass in on $ext_if inet proto icmp from any to $ext_if icmp-type $allowed_icmp_types pass inet proto tcp from any to $ext_if port $webports pass inet proto { tcp udp } from any to $ext_if port 17 block in on $ext_if proto { tcp udp } from any to any port { ssh telnet } block in on $int_if proto { tcp udp } from any to any port { ssh telnet } block in on $int_if3 proto { tcp udp } from any to any port { ssh telnet } block in on $int_if4 proto { tcp udp } from any to any port { ssh telnet } block return-rst in log quick proto tcp all flags FP/FP block return-rst in log quick proto tcp all flags SE/SE block return-rst in log quick proto tcp all flags FUP/FUP block quick from any os NMAP ##### SixXS tunnel rules ###### pass in quick proto icmp6 all pass in on $ext_if inet6 proto ipv6-icmp from any to $ext_if icmp6-type {neighbradv, neighbrsol, routersol, echoreq, unreach} pass quick on gif0 inet all pass quick on gif0 inet6 proto icmp6 all pass out quick on gif0 inet6 all

What does a traceroute to the PoP look like?

$ traceroute 77.109.111.178 traceroute to 77.109.111.178 (77.109.111.178), 64 hops max, 40 byte packets 1 * * * 2 maskarad-int.komplex.od.ua (91.202.108.129) 1.097 ms 1.357 ms 0.823 ms 3 mart-1.komplex.od.ua (91.202.108.1) 0.909 ms 1.249 ms 1.653 ms 4 users-gw.sky.od.ua (81.25.225.41) 1.503 ms 1.848 ms 1.828 ms 5 194.44.13.129 (194.44.13.129) 9.064 ms 9.414 ms 13.498 ms 6 core1-dwdm.uar.net (194.44.212.58) 10.246 ms 8.973 ms 10.089 ms 7 dtel-ix.edpnet.net (193.25.180.99) 32.837 ms 32.172 ms 32.245 ms 8 router02.spbbm18.ru.edpnet.net (212.71.11.197) 41.758 ms router02.spbbm18.ru.edpnet.net (212.71.11.118) 43.366 ms router02.spbbm18.ru.edpnet.net (212.71.11.197) 42.375 ms 9 77.109.111.178.static.edpnet.net (77.109.111.178) 43.059 ms 43.533 ms 42.867 ms

Also check the Live Tunnel Status on the tunnel page, you'll see that the PoP has not received a single proto-41 packet yet.

yep(

nodes in between you and the PoP might also filter.

As far as I know, my ISP blocks all ICMP traffic; but I couldn't beat any word about ICMP6 out of them. But according to tcpdump something definitely went wrong. I've got lots entries like that:

19:52:55.577834 IP6 2a02:578:5002:80b4::1 > 2a02:578:5002:80b4:6dc8:f622:6252:6d4c: ICMP6, destination unreachable, unreachable port, 2a01:e34:ee7c:4090:208:c7ff:fe73:db0e udp port 59779, length 194 19:52:55.918187 IP klient-44-110.komplex.od.ua > 77.109.111.178.static.edpnet.net: IP6 cl-181.led-01.ru.sixxs.net > 2a00:bdc0:3:103:1:0:403:902: ICMP6, destination unreachable, unreachable port, 2a02:578:5002:80b4:a198:affa:2840:1c7 tcp port 58427, length 68 19:52:56.257006 IP klient-44-110.komplex.od.ua > 77.109.111.178.static.edpnet.net: IP6 cl-181.led-01.ru.sixxs.net > 2a00:bdc0:3:102:2:0:402:425: ICMP6, destination unreachable, unreachable port, 2a02:578:5002:80b4:8036:638b:bd75:6c43 tcp port 2365, length 68

Not really good in network traffic analysis, but looks like my packets (klient-44-110.komplex.od.ua) were cut somewhere before they reached endpoint (cl-181.led-01.ru.sixxs.net)

PoP IPv6 doesn't ping

Jeroen Massar SixXS Staff

on Monday, 25 February 2013 18:25:23

As far as I know, my ISP blocks all ICMP traffic; but I couldn't beat any word about ICMP6 out of them.

They block all ICMP? That would be really bad, ICMP is there for informing about error and warning conditions, for instance MTU issue. The ICMPv6 would travel inside the tunnel and thus should not be touched upon by the IPv4 layer.

Not really good in network traffic analysis, but looks like my packets (klient-44-110.komplex.od.ua) were cut somewhere before they reached endpoint (cl-181.led-01.ru.sixxs.net)

68 byte packets could be almost sufficient, 20 for IPv4, 40 for IPv6 and a few for ICMP. They would be very short but it can in theory work.

PoP IPv6 doesn't ping

Shadow Hawkins on Monday, 25 February 2013 22:12:52

They block all ICMP?

sorry - I was somewhat inaccurate: I know for sure they block all inbound icmp4 traffic; support couldn't say anything about icmp6 so i don't know if it is blocked by their firewall. They also pretend that all ports are opened by default, if user doesn't block them himself (smtp should be an exception, I guess). By now I've got only one suggestion: packets of uncommon sizes may be cut by their firewall; just trying to make sure I didn't miss something on my side, but for now everything looks sane - even my pf rules. I'd prefer myself to be the one who messed the things up, 'cause in this case I'll be able to fix it... I doubt, they'll change their firewall rules just for me.

PoP IPv6 doesn't ping

Jeroen Massar SixXS Staff

on Tuesday, 26 February 2013 12:30:13

I know for sure they block all inbound icmp4 traffic;

Then they are breaking Path MTU discovery, that must be a horrible Internet experience you are getting.

packets of uncommon sizes may be cut by their firewall;

They drop packets based on size? If that would be true (and I guess not) then none of your connectivity would work reliably. Now, if it is the case that ICMP is blocked though then it might have an effect similar to what you describe as Path MTU does not work. As they are an ISP they should not be firewalling in the first place though.

PoP IPv6 doesn't ping

Shadow Hawkins on Tuesday, 26 February 2013 18:31:58

that must be a horrible Internet experience you are getting.

That's not the worst we have here, actually) Sometimes there are even mysterious ethereal stories - like the one when I payed my ISP for RFC1918 address and tried to make my webserver accessible from the Internet. Have to say, I didn't know how should the things be done; I knew how to configure the webserver and pf, yet didn't suppose I'll need to do something else. As far as I found out, without RFC1918 address aliased to my external interface and special magic in pf, nothing worked. Once again - may be I misunderstood something, but I didn't find any similar problem and my tech support couldn't help me. May be, I've got something like that this time. Well... thanks for help and attention, Jeroen! You tried to help - I appreciate that.

Please note Posting is only allowed when you are logged in.