Guest User!
You are not Sophos Staff.
Hi,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.
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
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.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.
Ian
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.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.
Ian
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.
I have just reviewed both my UTMs. One has native IPv6 over PPPoE and the other a sixxs tunnel.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.
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 posted a question about this on the tunnelbroker forum and here is the reply:At the suggestion of kasperd on the tunnelbroker forum, I also tried telnet and it appears that utm is "NATing" it as well. This is definitely not desirable behavior. I'm wondering if this is happening as a result of something I did when I installed or configured utm 9.080 or whether it's a result of a change in the code. I hope this will be fixed in the final release of 9.1. I'm also wondering if a change was made, if it was done as a result of a bug report.
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?
Currently when I logon to sixxs my IPv6 address is shown as my end of the tunnel.Hi Ian,
When I check using myipv6 it shows my address as my end of the tunnel. Now in the past, before 9.080-10 I am sure the address shown was that of the PC connecting.
Ian
Update. The UTM with native Ipv6 support also show the IPv6 address of the external interface of the UTM.
