Puzzling results from Looking Glass and IPv6 Portscan

[dawkco]

Preface:  I'm using WS2008 as a router where the tunnel is installed, i.e., the tunnel is a virtual interface and the physical NIC has an address from the routed /64.  Also, there's currently one other system (WS2003) on the network that has an address from the routed /64 assigned to it, and its default gateway is the WS2008 machine's routed /64 address.  I have Windows firewall set up on the WS2008 machine and configured to block all but public services ports.  Note:  ~::6 is the firewalled WS2008 tunnel/router, and ~::7 is the WS2003 machine.

When I use the IPv6 Portscan to check the routed /64 addresses assigned to the two machines, the odd thing is, the down-level machine shows ports open that are blocked on the router.  See below.

This is the portscan results for the firewalled tunnel/router:
Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-16 03:03 PDT
Interesting ports on ns1.dawkco.com (2001:470:1f05:a85::6):
Not shown: 996 filtered ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
443/tcp  open  https
8080/tcp open  http-proxy

This is the portscan results for the down-level machine:
Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-16 03:08 PDT
Interesting ports on ns2.dawkco.com (2001:470:1f05:a85::7):
Not shown: 995 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
135/tcp  open  msrpc
1025/tcp open  NFS-or-IIS
1026/tcp open  LSA-or-nterm
1028/tcp open  unknown

How is this possible?

Also, the Tracert results from the Looking Glass app are puzzling.  When tracing the tunnel/router machine, the local tunnel endpoint hop appears to have a problem; while a trace of the down-level machine sees the local tunnel endpoint hop fine, but skips the router interface completely.  See below.

The tunnel/router machine:
core1.fmt1.he.net> traceroute ipv6 2001:470:1f05:a85::6
Hop     Packet 1     Packet 2     Packet 3     Hostname
1    <1 ms    <1 ms    <1 ms    gige-g4-8.core1.fmt2.ipv6.he.net (2001:470:0:2d::2)
2    16 ms    5 ms    5 ms    gige-gbge0.tserv3.fmt2.ipv6.he.net (2001:470:0:45::2)
3    *    *    *    ?
4    24 ms    33 ms    16 ms    ns1.dawkco.com (2001:470:1f05:a85::6)

The down-level machine:
core1.fmt1.he.net> traceroute ipv6 2001:470:1f05:a85::7
Hop     Packet 1     Packet 2     Packet 3     Hostname
1    <1 ms    <1 ms    <1 ms    gige-g4-8.core1.fmt2.ipv6.he.net (2001:470:0:2d::2)
2    4 ms    4 ms    14 ms    gige-gbge0.tserv3.fmt2.ipv6.he.net (2001:470:0:45::2)
3    22 ms    32 ms    17 ms    dawkco-1-pt.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:a85::2)
4    22 ms    23 ms    32 ms    ns2.dawkco.com (2001:470:1f05:a85::7)

Notice how the local tunnel endpoint hop is dead in the first trace, while the router interface hop is missing in the second trace.

Weird!

[jimb]

I don't know enough about windows firewall, but it may be that it has a different set of rules (or the rules just don't apply) for when the traffic is being forwarded through the router, and when the traffic is bound to the router itself.

The traceroute is probably just an artifact of how windows treats "internal routing".  When the packet destined to the router reaches the router, maybe even though the TTL reaches zero, it for whatever reason doesn't send an ICMP time exceeded (or whatever the ipv6 equiv is) because it's reached the destination and the route is "internal", where when routing through, it hasn't hit the final destination host yet.  It could also be related to how it applies firewall rules, similar to what I said above.

[dawkco]

I don't know enough about windows firewall, but it may be that it has a different set of rules (or the rules just don't apply) for when the traffic is being forwarded through the router, and when the traffic is bound to the router itself...

It would appear that the Windows implementation of internal routing bypasses the router NIC completely and just forwards the packets directly from the source address (e.g., ~::7) directly to the tunnel gateway (somehow).  I guess that's OK, but now I have to enable Windows Firewall on the other machine(s) as well.  I was hoping to just block everything at the central point of the router machine.

However, I'm troubled by the dead hop #3 when doing a Looking Glass traceroute from HE to the router host (~::6) address.  That's the hop that should be:

dawkco-1-pt.tunnel.tserv3.fmt2.ipv6.he.net (2001:470:1f04:a85::2)

Do you think there is some way to fix that?

[dawkco]

...
However, I'm troubled by the dead hop #3 when doing a Looking Glass traceroute from HE to the router host (~::6) address. ...

I think I've found the answer--quoting from RFC 4213, Basic Transition Mechanisms for IPv6 Hosts and Routers:

"3.3.  Hop Limit

   IPv6-over-IPv4 tunnels are modeled as "single-hop" from the IPv6
   perspective.  The tunnel is opaque to users of the network, and it is
   not detectable by network diagnostic tools such as traceroute."

But, if that's so, then my question becomes, why does the tunnel hop appear in a traceroute to the down-level machine?  It's still puzzling.