Print

[mtcstle]

So, here's the setup:
Carrier DSL ---> Bastion
                 (192.168.2.1)- firewall set to DMZ mode
                        \
                        wireless bridge
                        (192.168.2.17)--->IPv6 router
                                                  (192.168.2.100)
                                                  (192.168.1.1)
                                                  (2001:470:7:...::2)
                                                  (2001:470:8:...::1}
                                                     \       
                                                      client(192.168.1.100)
                                                      (2002:470:8:...:100)
The bastion is in DMZ mode and so, should pass everything it sees to the IPv6 router via the wireless bridge. The IPv6 router has accepted properly formed IPv6 addresses for he-ipv6 and br0. The client, 192.168.1.100, can reach the internet. The client, 2001:470:8:...:100, can ping 2001:470:7:...::2 and 2001:470:8:...::1. Yet, I cannot realize a functional tunnel and cannot ping 2001:470:7:...::1 which should be at the other end of said tunnel. Am I missing some fundamental reason why this won't work or am I missing some detail which when corrected, will allow my IPv6 traffic to flow through the tunnel and over the internet making me very happy?

Thanks for  your time
mtcstle

[cholzhauer]

Obfuscating your addresses makes it harder for us to help you.

With that being said, there are many routers who's dmz mode is broken and doesn't actually pass ask traffic..it sounds like yours may be one of those

I assume that you  altered the commands and used your nat address instead of your public address?

[mtcstle]

Thanks for the reply. I saw a post once about using the NAT address instead of the public address of the router but I couldn't work out where or how to do so without generating an error about private addresses from the server. Can you help ,me out with that

I borrowed this from a really excellent article on the wiki:
 # The following commands are straight from HE's website
        ip tunnel add he-ipv6 mode sit remote $SERVER_IP4_ADDR local $WANIP ttl 255
        ip link set he-ipv6 up
        ip addr add $CLIENT_IPV6_ADDR/64 dev he-ipv6
        ip route add ::/0 dev he-ipv6
        ip -f inet6 addr
        TEMP_ADDR=`echo $ROUTED_64_ADDR'1'`
       
        # These commands aren't on HE's website, but they're necessary for the tunnel to work
        ip -6 addr add $TEMP_ADDR/64 dev br0
        ip route add 2000::/3 dev he-ipv6

When $WANIP=192.168.1.100, I got an error in the log file. When $WANIP=70.16.167.17 all is quiet, including 2002:470:7:1ac::1. Maybe you can point me in the right direction?

Regards
mtcstle

[kasperd]

I saw a post once about using the NAT address instead of the public address of the router but I couldn't work out where or how to do so without generating an error about private addresses from the server.

The first you need to do is to get packet dumps (using tcpdump or equivalent) on the outside of the NAT as well as of the internal interface of the tunnel endpoint. Once you compare the traffic on those two interfaces, many problems will become obvious.

As for ways to get a tcpdump on the outside of the NAT, the best is if you can do it directly on the NAT itself. If that is not an option, the easiest way to do it is to connect a hub (not a switch) on the outside of the NAT and connect another computer to that hub to dump the traffic. If you don't have access to a hub, then you can use a computer with two network interfaces in bridging mode.

2002:470:7:1ac::1

What IP is that? I tried to traceroute it and got weird results

Code: [Select]

traceroute to 2002:470:7:1ac::1 (2002:470:7:1ac::1), 30 hops max, 80 byte packets
 1  2001:470:28:940:5d75:c1f4:e0a0:f8ec  0.660 ms  0.856 ms  1.285 ms
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  *
 6  *  *  *
 7  *  *  *
 8  *  *  *

[mtcstle]

Sorry, "that", was a typo. Should have been" 2001:470:7:1ac::1.

Regards
mtcstle

[cholzhauer]

You have to use the nat address if you're behind nat   so since you have a 192.168 address, you have to user that in place of the public address

[mtcstle]

The mists may have begun to clear. I figured out the error I saw before was not from the router's tunnel configuration, rather from where the script updates the IPv4 address on the server. Next time I have access to the NAT router, I'll put it into DMZ mode again and try my modified HE_Startup script. It's designed to work with or without NAT addressing.
Regards
mtcstle

[kasperd]

Sorry, "that", was a typo. Should have been" 2001:470:7:1ac::1.

Sorry. I should have noticed that typo yesterday. The only excuse I have for not noticing is that it was late, and I was getting tired. Being a 6to4 address certainly explains why I didn't even get a response from the tunnel server I was accessing (as my gateway recognize it as a 6to4 address and sends the packet directly to the corresponding IPv4 address, in this case 4.112.0.7).

Right now I did a traceroute to 2001:470:7:1ac::1 and that is currently responding. A traceroute to 2001:470:7:1ac::2 gets no response.

Code: [Select]

traceroute to 2001:470:7:1ac::1 (2001:470:7:1ac::1), 30 hops max, 80 byte packets
 1  2001:470:28:940:5d75:c1f4:e0a0:f8ec  0.788 ms  0.733 ms  1.235 ms
 2  2001:470:27:940::1  31.543 ms  35.883 ms  42.560 ms
 3  2001:470:0:11e::1  50.898 ms  29.573 ms  38.990 ms
 4  2001:470:0:22f::1  63.614 ms  67.991 ms  65.403 ms
 5  2001:470:0:217::2  72.890 ms  65.411 ms  90.462 ms
 6  2001:470:0:128::1  147.061 ms  147.940 ms  141.821 ms
 7  2001:470:0:36::1  158.274 ms  129.940 ms  130.326 ms
 8  2001:470:7:1ac::1  135.063 ms  139.885 ms  142.992 ms

Code: [Select]

traceroute to 2001:470:7:1ac::2 (2001:470:7:1ac::2), 30 hops max, 80 byte packets
 1  2001:470:28:940:5d75:c1f4:e0a0:f8ec  0.697 ms  0.780 ms  1.270 ms
 2  2001:470:27:940::1  100.717 ms  111.971 ms  112.126 ms
 3  2001:470:0:11e::1  112.537 ms  31.350 ms  35.317 ms
 4  2001:470:0:22f::1  56.758 ms  61.164 ms  68.562 ms
 5  2001:470:0:217::2  76.912 ms  77.038 ms  77.842 ms
 6  2001:470:0:128::1  133.507 ms  134.062 ms  130.524 ms
 7  2001:470:0:36::1  142.134 ms  167.848 ms  172.067 ms
 8  2001:470:20::2  180.921 ms  185.435 ms  181.251 ms
 9  *  *  *
10  *  *  *
11  *  *  *
12  2001:470:20::2  154.246 ms !H  *  *
So the tunnel is not up and the tunnel server sometimes reports a no route to host. The no route to host probably indicates some response coming from your NAT. If I knew your IPv4 address, I would be able to find out what the response from the NAT looks like. But for now I'll wait until we hear the result from the changes you want to test.

[mtcstle]

Thanks for the traceroutes. They're helpful. I tried placing the NAT router into DMZ mode but was unsuccessful in establishing a tunnel. I didn't work at it too long because I fear that placing one host into the DMZ,may cut everyone else off from the internet. Or, does DMZ only forward all those packets it hasn't a better destination for? By the way, right now, my IPv4 address is 70.109.71.173. Unfortunately, as you know, it can change at almost any time and with little or no warning.
Regards
mtcstle

[cholzhauer]

Depends on the firewall/router.  Unfortunately, there are a lot of people who have routers in which the DMZ mode seems to be broken in the fact that it doesn't forward all packets.  Like kasperd said, you'll have to run a packet trace and see where things are failing.

[kasperd]

right now, my IPv4 address is 70.109.71.173.

I tried a traceroute to 2002:466d:47ad::2002:466d:47ad, which unfortunately didn't reveal much:

Code: [Select]

traceroute to 2002:466d:47ad::2002:466d:47ad (2002:466d:47ad::2002:466d:47ad), 3
0 hops max, 80 byte packets
 1  2001:470:1f0b:1e45:1f9c:c1d2:c8b6:9008  0.129 ms  0.113 ms  0.138 ms
 2  ::ffff:10.0.0.1  0.397 ms  0.429 ms  0.437 ms
 3  *  *  *
 4  ::ffff:212.10.10.20  31.906 ms  31.946 ms  31.964 ms
 5  *  *  *
 6  ::ffff:194.255.53.29  10.191 ms  10.587 ms  11.083 ms
 7  2001:620:0:c0bf::2  46.963 ms  60.730 ms  61.037 ms
 8  *  *  *
 9  *  *  *
10  *  *  *
11  *  *  *
12  *  *  *
13  *  *  *
14  *  *  *
15  *  *  *
16  *  *  *I compared this with a regular IPv4 traceroute

Code: [Select]

traceroute to 70.109.71.173 (70.109.71.173), 30 hops max, 60 byte packets
 1  * * *
 2  212.10.10.20  8.654 ms  8.719 ms  8.752 ms
 3  212.10.10.1  8.798 ms  8.828 ms  9.001 ms
 4  194.255.53.29  10.202 ms  10.833 ms  11.136 ms
 5  * * *
 6  213.248.66.145  10.902 ms  24.041 ms  24.162 ms
 7  80.91.245.2  17.635 ms 80.91.245.154  17.532 ms 213.155.133.58  16.709 ms
 8  213.248.64.34  109.365 ms 80.91.247.117  168.818 ms  168.442 ms
 9  213.155.131.137  100.961 ms 213.155.130.245  117.091 ms 213.155.131.137  105.868 ms
10  157.130.255.205  104.967 ms  111.123 ms  102.800 ms
11  152.63.20.98  114.279 ms  101.716 ms  105.555 ms
12  152.63.17.86  147.418 ms 152.63.1.42  104.257 ms  104.271 ms
13  130.81.20.75  128.618 ms  126.639 ms  125.801 ms
14  130.81.12.10  113.471 ms  106.208 ms  103.961 ms
15  * * *
16  * * *Running a tcpdump while the traceroute to 2002:466d:47ad::2002:466d:47ad was running revealed that I got both TTL exceeded and network unreachable errors from 130.81.12.10. So the packets didn't even make it all the way to your NAT.

right now, my IPv4 address is 70.109.71.173. Unfortunately, as you know, it can change at almost any time and with little or no warning.

In my experience when you have a dynamic IP address, it rarely changes as long as you just stay online. If you keep your NAT online all the time, and the IP still changes, you should contact your ISP to get a fix for whatever is unstable in the network. It could be the NAT, but it can also be in the ISPs network.

Will you be able to get a packetdump from the connection between the NAT and the ISP?

[mtcstle]

It will be difficult to get packet dumps between NAT and ISP. NAT and IPV6 routers are in different buildings.I did do packet dumps on he-ipv6 and saw packets egressing for 2001:470:7:1ac::1. I'm going to work on my tunnel setup scripts for a while. If I can get them right, I'll turn back to why the tunnel won't come up.
Thanks for your help, I'll be around.
mtcstle