Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[olewolf]

I've setup my DIR-868L with an IPv6 address provided via Hurricane Electric. I can ping the router from external networks, and I can access IPv6-enabled sites from within my LAN.

I also have one of my LAN computer providing web access. It's externally accessable via IPv4, and internally it can be accessed via IPv6 as well. However, I can't access the LAN computer from external hosts. The IPv6 firewall on the DIR-868L is disabled, and the LAN computer's firewall allows IPv6 traffic to port 80 (i.e., the web service port) from anywhere.

The IPv6 address of my router is 2001:470:28:20f::1/64, and the IPv6 address of the web server is 2001:470:28:20f::2/64. How do I configure the DIR-868L to allow incoming IPv6 traffic directed at the web server through the DIR-868L router?

(Current DIR-868L FW: 1.02. The router was factory reset after the upgrade.)

[FurryNutz]

Link>Welcome!

• What region are you located?

Internet Service Provider and Modem Configurations

• What ISP Service do you have? Cable or DSL?
• What ISP Modem Mfr. and model # do you have?
• What ISP Modem service link speeds UP and Down do you have?

[Patrick533]

I do not have this router yet but I will give it a go.

I assume you have went to a looking glass somewhere to ping your IPV6 computer?

Does the firmware for the DIR-868L have a check box for simeple IPV6 security? Unchecked?

Once I get home I can try a tracert to your server. I do not have IPV6 at work.

[Patrick533]

No luck.

Hopefully packet tracer will have some insight. I can get to HE then it goes dead.....

[olewolf]

Thanks for your efforts, Patrick533.

I'm using stofanet.dk (Denmark) as an ISP. There's a Thomson TWG870LS cable modem in front of my DIR-868L, enabling speeds of 40 Mbits/s down, 5 Mbits/s up. The TWG870LS is configured to let all traffic through. I don't think the modem is the cause of the problems, because I can ping my DIR-868L from an external computer:

PING 2001:470:28:20f::1(2001:470:28:20f::1) 56 data bytes
64 bytes from 2001:470:28:20f::1: icmp_seq=1 ttl=55 time=127 ms
64 bytes from 2001:470:28:20f::1: icmp_seq=2 ttl=55 time=127 ms

Tracepath also indicates succes to 2001:470:28:20f::1:

tracepath6 2001:470:28:20f::1
 1?: [LOCALHOST]                        0.036ms pmtu 1500
 1:  ???                                                  11.264ms
 2:  ???                                                  11.060ms pmtu 1280
 2:  gw-222.olo-01.de.sixxs.net                           65.878ms
 3:  deolo01.sixxs.net                                    65.827ms asymm  2
 4:  ???                                                  65.988ms asymm  3
 5:  ???                                                  65.456ms
 6:  bbrt-ffm-0-ge-5-1-0-0.ewe-v6.de                      83.109ms
 7:  30gigabitethernet4-3.core1.fra1.he.net               84.821ms asymm  6
 8:  10gigabitethernet1-1.core1.cph1.he.net              105.240ms asymm  7
 9:  10gigabitethernet1-1.core1.sto1.he.net              106.577ms asymm  8
10:  tserv1.sto1.he.net                                  107.118ms asymm  9
11:  ???                                                 130.204ms reached
     Resume: pmtu 1280 hops 11 back 55

It's the 2001:470:28:20f::2 host that sits on the DIR-868L's LAN that I can't reach from the WAN side. The DIR-868L IPv6 firewall is turned off, QoS is turned off, and IPv6 simple security is turned off. I can ping 2001:470:28:20f::2 from the DIR-868L's system check.

Edit: the DIR-868L is connected to the HE tunnel via its built-in IPv6-in-IPv4 support. The DIR-868 can ping the HE IPv6 endpoint.

[Patrick533]

I don't know if it has to do with the 4to6 tunnel or 6rd in my case but my last router that did not have any firewall was not pingable at all either. I was told that the ISP probably has a firewall on the V6 tunnel when I asked last time.

Being you use HE you may want to pose your question over there.

My V6 works perfect but a client has NEVER been pingable on my end. Last time I messed around with this I used several "looking glass" sites trying to get back to my client but I have never had any luck. I guess I just take it for granted it works.

[olewolf]

No, I can ping ipv6.google.com from my DIR-868L, and it can be pinged from the WAN side, so it's definitely not an HE issue, nor is it an issue with the router in-between the DIR-868L and my ISP. The DIR-868L just won't forward any IPv6 traffic to the LAN. IPv4 traffic works fine.

(And, I hate to say it, the wireless range in our home was significantly lowered when the DIR-825 was replaced with the newer DIR-868L. And the DIR-825 could at least be hacked with OpenWRT, enabling it to do virtually anything, as it does now, including IPv6 via SixXS. I'm beginning to regret having purchased the DIR-868L.)

[PacketTracer]

Looks as if the IPv6 default gateway setting of your LAN internal webserver does not point to the LAN interface of your DIR-868L? The IPv6 default gateway of your webserver should be either 2001:470:28:20f::1 (IPv6 LAN address of your DIR-868L), or it might be the link local address (fe80::...) of your router's LAN interface (either configured statically or learned by SLAAC).

But anyway: Could you post a screenshot of your DIR-868L's "IPv6 in IPv4 Tunnel" setup and an IPv6 configuration output (e.g. "ipconfig /all" if Windows) of your webserver's IPv6 configuration?

[olewolf]

True, the default gateway didn't point to the DIR-868L, but reconfiguring it doesn't help. The routing information on the web server (where the eth1 IP is 2001:470:28:20f::2) is now as follows:

~$ ip -6 route show
2001:470:28:20f::/64 dev eth1  metric 1024
2001:16d8:dd00:1a3::/64 dev sixxs  proto kernel  metric 256
2001:16d8:dd00:81a3::/64 dev eth1  proto kernel  metric 256
fe80::/64 dev eth1  proto kernel  metric 256
fe80::/64 dev sixxs  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
default via 2001:470:28:20f::1 dev eth1  metric 100

and

~$ tracepath6 -n ipv6.google.com
 1?: [LOCALHOST]                        0.070ms pmtu 1500
 1:  2001:470:28:20f::1                                    5.464ms
 1:  2001:470:28:20f::1                                    0.520ms
 2:  2001:470:28:20f::1                                    0.352ms pmtu 1480
 2:  no reply
 3:  no reply
 4:  no reply
etc.

shows that the webserver is attempting to reach ipv6.google.com via the DIR-868L but is unsuccessful. The DIR-868L itself can ping ipv6.google.com, and is configured as follows:

IPv6 type	6IN4
Network Status	Connected
WAN IPv6 Address	2001:470:27:20f::2 /64
IPv6 Default Gateway	2001:470:27:20f::1
Primary IPv6 DNS Server	2002:d596:2a92:1:71:53::
Secondary IPv6 DNS Server	2002:5968:c28e::53
LAN IPv6 Link-Local Address	fe80::7a54:2eff:fefb:3660 /64
DHCP-PD	Disabled
IPv6 Network assigned by DHCP-PD	None
LAN IPv6 Address	2001:470:28:20f::1 /64

I haven't defined any IPv6 routes on the DIR-868L.

[PacketTracer]

Your webserver seems to have several interfaces and may be a sixxs tunnel endpoint either? In addition it looks like it has additional IPv6 addresses from the ranges 2001:16d8:dd00:81a3::/64 or 2001:16d8:dd00:1a3::/64? So if it takes a source address from one of these ranges while talking to the IPv6 internet via your DIR-686L, you won't get a reply because your HE tunnel does not route these address ranges. Make sure that your webserver uses the correct IPv6 source address from range 2001:470:28:20f::/64 either by deactivating all other local addresses from ranges 2001:16d8:dd00:81a3::/64 and 2001:16d8:dd00:1a3::/64, binding webservice to 2001:470:28:20f::2 only or by manipulating your policy table for source address selection (see RFC6724).

[olewolf]

I had actually tried that already, and it didn't work. On the other hand, the version with a "bad" address range seemed to work flawlessly with the other address (the 2001:470... one), so I assumed that for some reason it wasn't a problem.

Removing the bad address range works now, though--thanks! According to my system logs, it appears that just while I was making the attempt with just one IPv6 address set, apparently a number of connectivity issues were preventing outside traffic. I guess I was just unlucky at a particularly bad moment.