I just switched over to 9.080 from 9.005. As before, I am using a 6in4 tunnel from Hurricane Electric. I am using the same tunnel as I was with 9.005. Now that I switch over to 9.080, utm is allocating ipv6 addresses and they are visible within the network, but when I view the address externally, the address that shows up is the client side of the tunnel, not the address of the host. I looked at the settings and they are all the same. Has anyone else experienced this? I don't think this is correct, because the client side of the tunnel is not intended to be used other than for the tunnel. The addresses allocated to the hosts aren't even in the same /64 subnet as the client end of the tunnel.
Hi, from my experience the client side of the tunnel is the host address. The network address on the LAN side of the UTM should be different to the tunnel and usually in a different range. That is my experience with sixxs and freenet6.
You would have been assigned a /56 range for use within your network?
Hi,
from my experience the client side of the tunnel is the host address. The network address on the LAN side of the UTM should be different to the tunnel and usually in a different range. That is my experience with sixxs and freenet6.
You would have been assigned a /56 range for use within your network?
Ian
I have a /64. (I could get a /48, but I have no need for it.) Before, with utm 9.005, the ip address for each of the hosts in my subnet showed up correctly both outside the network and inside the network. (The gateway is ::1.) Now the hosts all show up with the address of the client side of the tunnel. This address is not pingable like the ipv4 host address is. There is no obvious setting that I can see that would cause this behaviour. In native IPV6, there is no tunnel, so this behaviour is not correct. If someone can suggest why this behaviour would be wanted, I would like to hear it. I can't see what advantage or benefit there would be to have the client side of the tunnel as the externally visible ip address.
The tunnel should be a on a different network to the local PCs. Your tunnel should have either a 2***:1::/64 or an fe80 address and your local network should have a 2***:2::/64 as examples, the masks are not correct just used for demonstration in this case.
The tunnel should be a on a different network to the local PCs. Your tunnel should have either a 2***:1::/64 or an fe80 address and your local network should have a 2***:2::/64 as examples, the masks are not correct just used for demonstration in this case.
Ian
I know how the tunnel works. There are client and server side ipv4 and ipv6 addresses, where the client ipv4 address is the isp supplied gateway address. The tunnel was working fine on 9.005, and it's working fine on 9.080, but before the externally visible ipv6 address was the allocated address from my subset, which is what it should be, but now the it's the address of the client side of the tunnel. What I'm saying is that it doesn't make sense for utm to use the client side address. The client side ipv6 address of the tunnel is not in my subnet. The only reason it exists is so the tunnel will work. It should not be the externally visible ipv6 address of hosts.
I posted a question about this on the tunnelbroker forum and here is the reply:
It sounds like the router started doing NAT66. I don't know of any standard for NAT66, and enabling it by default would be a bug. It could also indicate a transparent proxy is running on the router, not something that should be enabled by default either. A transparent proxy would typically only apply to HTTP, so you'd see different behaviour when using other protocols.
Does utm 9.080 implement NAT66? If so, is there a way to disable it?
I have just reviewed both my UTMs. One has native IPv6 over PPPoE and the other a sixxs tunnel. The one with the sixxs tunnel has a NAT46 for outgoing traffic where as the UTM with native only has a NAT4.
I will search for the UTM with tunnel and see what addresses are returned.
Ian
Checking the IPv6 info for the UTM will be difficult because this box doesn't access to IPv6.
I have just reviewed both my UTMs. One has native IPv6 over PPPoE and the other a sixxs tunnel. The one with the sixxs tunnel has a NAT46 for outgoing traffic where as the UTM with native only has a NAT4.
I will search for the UTM with tunnel and see what addresses are returned.
Ian
Checking the IPv6 info for the UTM will be difficult because this box doesn't access to IPv6.
I have just reviewed both my UTMs. One has native IPv6 over PPPoE and the other a sixxs tunnel. The one with the sixxs tunnel has a NAT46 for outgoing traffic where as the UTM with native only has a NAT4.
I will search for the UTM with tunnel and see what addresses are returned.
Ian
Checking the IPv6 info for the UTM will be difficult because this box doesn't access to IPv6.
I saved the VM with 9.005. I could switch back to it if someone needs any info, but it should be pretty easy to replicate this. I share the opinion of kasperd over at the tunnelbroker forum that this new? behavior is not only undesirable, there is not a logical reason for it. The client side address of tunnel is an artifact of the tunnel. Even if you wanted to obfuscate your internal ipv6 addresses, you would not use the client side tunnel address, you would use your allocated gateway address, which is exactly the same way you would do it if you had native ipv6. However, NAT66 should not be done by default or transparently.
