Hi all
I know this has been asked before and I've read as many of the posts on here and articles on the internet but i think i'm starting to get blinded by the trees.
I'm using a WNDR3700v4 build 26849, the tunnel is configured on the router. The website I'm trying to test with is on my macbook, running MAMP PRO.
I'm trying to get past the explorer stages of this certification, I've got the tunnel configured on HEs site, got the config done my DD-WRT router. I'm getting 10/10 on the test-ipv6.com site and 18/20 on ipv6-test.com, (it's seeing no reverse DNS and not using IPV6 as default).
The certification test gets as far as grabbing the test file with "Could not grab the file via IPv6 HTTP"
I can use WGET -6 to get the file from my within my local network:
blagdon@blagdon-Parallels-Virtual-Platform ~/Desktop $ wget -6 blaggers.cf/uaa9hiqwu3.txt
--2015-05-10 14:23:43-- http://blaggers.cf/uaa9hiqwu3.txt
Resolving blaggers.cf (blaggers.cf)... 2001:470:1f09:b83:3ca6:5352:f1fc:79a2
Connecting to blaggers.cf (blaggers.cf)|2001:470:1f09:b83:3ca6:5352:f1fc:79a2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4 [text/plain]
Saving to: 'uaa9hiqwu3.txt.5'
100%[======================================>] 4 --.-K/s in 0s
2015-05-10 14:23:44 (648 KB/s) - 'uaa9hiqwu3.txt.5' saved [4/4]
It seems port 80 is blocked, no reachable after doing this test on http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-port-scanner.php
Checked port 80 on Host/IP blaggers.cf...
The checked port (80, service http) is offline/unreachable
Reason: Connection timed out (110)
Portscan ran for 8.0736 seconds
I'm guessing it's my firewall rules but as I understand it they are allowing port 80 and 443, see the ip6tables and iptables below:
root@DD-WRT:~# ip6tables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 0 anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmpv6 anywhere anywhere
ACCEPT 0 fe80::/64 anywhere
ACCEPT udp anywhere anywhere udp dpt:546
DROP 0 anywhere anywhere
ACCEPT tcp anywhere anywhere tcp dpt:www
ACCEPT tcp anywhere anywhere tcp dpt:https
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT 0 anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmpv6 anywhere anywhere ipv6-icmp echo-request
ACCEPT 0 anywhere anywhere
DROP 0 anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@DD-WRT:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- tserv1.lon1.he.net anywhere
ACCEPT icmp -- arc.he.net anywhere
ACCEPT ipv6 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:1723
ACCEPT tcp -- anywhere anywhere tcp dpt:1723
ACCEPT gre -- anywhere anywhere
DROP udp -- anywhere anywhere udp dpt:route
DROP udp -- anywhere anywhere udp dpt:route
ACCEPT udp -- anywhere anywhere udp dpt:route
ACCEPT ipv6 -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
DROP igmp -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state NEW
ACCEPT 0 -- anywhere anywhere state NEW
DROP 0 -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT gre -- 192.168.1.0/24 anywhere
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:1723
lan2wan 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere
ACCEPT tcp -- anywhere MacBook-Pro tcp dpt:www
ACCEPT udp -- anywhere MacBook-Pro udp dpt:www
ACCEPT tcp -- anywhere MacBook-Pro tcp dpt:https
ACCEPT udp -- anywhere MacBook-Pro udp dpt:https
TRIGGER 0 -- anywhere anywhere TRIGGER type:in match:0 relate:0
trigger_out 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state NEW
DROP 0 -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain advgrp_1 (0 references)
target prot opt source destination
Chain advgrp_10 (0 references)
target prot opt source destination
Chain advgrp_2 (0 references)
target prot opt source destination
Chain advgrp_3 (0 references)
target prot opt source destination
Chain advgrp_4 (0 references)
target prot opt source destination
Chain advgrp_5 (0 references)
target prot opt source destination
Chain advgrp_6 (0 references)
target prot opt source destination
Chain advgrp_7 (0 references)
target prot opt source destination
Chain advgrp_8 (0 references)
target prot opt source destination
Chain advgrp_9 (0 references)
target prot opt source destination
Chain grp_1 (0 references)
target prot opt source destination
Chain grp_10 (0 references)
target prot opt source destination
Chain grp_2 (0 references)
target prot opt source destination
Chain grp_3 (0 references)
target prot opt source destination
Chain grp_4 (0 references)
target prot opt source destination
Chain grp_5 (0 references)
target prot opt source destination
Chain grp_6 (0 references)
target prot opt source destination
Chain grp_7 (0 references)
target prot opt source destination
Chain grp_8 (0 references)
target prot opt source destination
Chain grp_9 (0 references)
target prot opt source destination
Chain lan2wan (1 references)
target prot opt source destination
Chain logaccept (0 references)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere
Chain logdrop (0 references)
target prot opt source destination
DROP 0 -- anywhere anywhere
Chain logreject (0 references)
target prot opt source destination
REJECT tcp -- anywhere anywhere reject-with tcp-reset
Chain trigger_out (1 references)
target prot opt source destination
root@DD-WRT:~#
Any help, advise would be massively appreciated. I've been stuck on this for days and it's really starting to annoy me. :-)
Cheers
Shaun
That page loads fine for me.
Which page, blaggers.cf? It loads fine during the Enthusiast test but the test file "/uaa9hiqwu3.txt" won't load with the error "Could not grab the file via IPv6 HTTP"
I can load http://blaggers.cf/uaa9hiqwu3.txt without issue. You should see my IP in your logs just now
Is there a stale DNS entry on HE's side?
Hi
Great you can both see the file, means I'm not totally stupid ;-)
Here's the DNS entries from HE
Name Type TTL Priority Data DDNS Delete
blaggers.cf SOA 86400 - ns1.he.net. hostmaster.he.net. 2015051106 10800 1800 604800 86400 locked
blaggers.cf NS 86400 - ns2.he.net
blaggers.cf NS 86400 - ns3.he.net
blaggers.cf NS 86400 - ns5.he.net
blaggers.cf NS 86400 - ns4.he.net
blaggers.cf A 300 - 5.198.114.229
blaggers.cf AAAA 300 - 2001:470:1f09:b83:fc86:797f:11d7:1584
blaggers.cf MX 300 1 blaggers.cf
blaggers.cf PTR 300 - blaggers.cf
I've no idea how to spot a stale entry. Maybe if I delete and recreate the who thing from tunnel up?
Thanks for all this guys
The test cache information expires after one hour, regardless of the record's TTL.
That's what the reply from HE said. I've waited an hour, still not working. Any more ideas?
From the testing server:
# telnet -6 2001:470:1f09:b83:fc86:797f:11d7:1584 80
Trying 2001:470:1f09:b83:fc86:797f:11d7:1584...
telnet: Unable to connect to remote host: Connection timed out
Same from HE colo native IPv6:
ipvsixme:~$ telnet blaggers.cf 80
Trying 2001:470:1f09:b83:fc86:797f:11d7:1584...
Trying 5.198.114.229...
Connected to blaggers.cf.
Escape character is '^]'.
Thanks guys. I'm guessing it's the firewall config then or the router can't transit protocol 51??? My ip6tables are below, they still look like they'll accept ports 80 and 443?
root@DD-WRT:~# ip6tables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 0 anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmpv6 anywhere anywhere
ACCEPT 0 fe80::/64 anywhere
ACCEPT udp anywhere anywhere udp dpt:546
DROP 0 anywhere anywhere
ACCEPT tcp anywhere anywhere tcp dpt:www
ACCEPT tcp anywhere anywhere tcp dpt:https
Chain FORWARD (policy ACCEPT)
target prot opt source destination
TCPMSS tcp anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT 0 anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmpv6 anywhere anywhere ipv6-icmp echo-request
ACCEPT 0 anywhere anywhere
DROP 0 anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@DD-WRT:~#
Try removing ip6tables completely, and making certain the daemon is listening on that ip, and that people can connect externally. Try popping into #ipv6 on freenode for experienced IPv6 people to maybe help you in realtime (assuming anyone is there and active when you join).
Brilliant, that cracked it! I flushed the ip6tables with ip6tables -f and now it's working fine. Thanks you very much!
For IPv6, look at where your "drop everything" rule was. It wasn't at the end.... (Rules after it are never reached.)
Also, your input and output rules (for both IPv4 and IPv6) should probably have an "-j ACCEPT -i lo" (or -o lo) so that packets from and to yourself can pass through the firewall. I always put them first so that I can ignore looped-back traffic from counters measuring external traffic.
TCPMSS targets do not belong in the filter table. Read the docs for the target and you will find they belong elsewhere (I forget offhand if the correct placement is the "raw" table or in the "mangle" table), but the filter table is definitely wrong. It also makes no sense to have it in a forward rule set. You need to add it at the host which is trying to generate the overly large packet. ICMP will deal with forwarding packets too large.
Lastly, I note that your rules allow new TCP traffic (i.e. SYN flag), and established TCP sessions, but are you allowing for replies to TCP SYN packets where the virtual connection is not fully established?
It looks like the OP is basically using the default dd-wrt iptables & ip6tables rulesets. Since he did not run -vnL the IFs are not shown. That being said the first of the duplicate IPv4 input chain "accept state new" would be for lo the second for br0. As for IPv6 it may be prudent to add lo but honestly it does absolutely nothing. I have 0 packets from lo over IPv6.
For IPv4 tcpmss clamping would be found in the mangle table by default with ddwrt. For IPv6 the module ip6table_mangle is not loaded by default and if I remember correctly was not included in the ddwrt builds until recently (ish). If he were to move tcpmss to mangle he would have to insmod ip6tables_mangle.ko himself. As for it being in the filter forward table I believe it would be kind of difficult to outright state that it is not acceptable when the netfilter documentation itself shows it in the filter forward table. FYI it works just fine where it is by default.
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-4.html
Obviously incorrect. If the first entry were for the loopback device, the ONLY condition would be -i lo or -o lo. There would be no -m state option given.
From the manual page for ip[6]tables:
QuoteTCPMSS
This target .... Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.
It will not work in the filter table.