IPV6 + IPV4 through Comcast question + HE IPV6 certification

[garywsmith]

I've setup a tunnel on my home network.  The firewall is a linux box running CentOS 5.x.  It runs nat for the IPV4 stuff.  I added the IPV6 to that box, set it up and everything this fine.  I setup my laptop to work against the internal interface and I'm able to go out via that interface.  Externally, my remote DNS server with IPV6 is able to ping my workstation

When I ping ipv6.google.com or ipv6.he.net, everything is great.  When I go to take the continued certification it keeps saying that I'm on my IPV4 address (even though pinging the same address shows the IPV6).  So, this is leading me to belive either a) I did something wrong or b) that I did something wrong...

Anyone run into this problem with IPV6 tunnel with a similar configuration.

[cholzhauer]

Did you assign an IPv6 address from your routed /64 or /48 to the Local Area Connection (or eth0, whatever)?

[garywsmith]

My home network was much much easier to setup than the office one that I'm having problems with.  It actually went fairly smooth.  It had it up pretty fast.

On the firewall sit1 interface, I setup the server IP 2001:470:1f04:15a2::2/64 (as per the HE script) and then I added one of the public routed IP's 2001:470:1f05:15a2::1/64 on the internal interface.  I then tested that from another external working IPV6 server and was able to access both the server IP and the internal IP just fine.  I then added an IP to my Windows 7 workstation 2001:470:1f05:15a2::6/64.  From my windows workstation I was able to ping out but not receive pings until I tweaked the firewall (on the Windows box itself) to allow incoming IPV6-ICMP. 

From there I was able to ping my Windows box just fine from an external IPV6 machine at a different location.  I was also able to resolve and access ipv6.he.net and ipv6.google.com. 

The workstation now had an IPV4 and IPV6 address.  Going to work further on the certification test over at HE, it says that I'm coming from IPV4 address, even though it's resolving to ipv6.he.net.  Then I removed my IPV4 from the Windows box so I was IPV6 only.  At that time I was unable to resolve DNS (using the IPV6 HE cache server).  Checking my own firewall (the CentOS box) there were no packets being caught by the firewall rules) as everything is logged before rejecting. 

I believe that I'm fairly close to solving this issue.  I think it has more to do with DNS being broken under an IPV6 only implementation on my workstation but I can't put my finger on it just yet.

Anyway, I will play around with the firewall rules a little more tonight in regards to IPV6 and hopefully I can have an IPV6 only workstation running on the network shortly to play with.

[garywsmith]

So far it appears that most of the problems I'm having with this particular issue is that the linux 2.6.18 kernel isn't supporting stareful firewalls correctly which isn't allowing any web browsing from inside this network.

[rwg]

So far it appears that most of the problems I'm having with this particular issue is that the linux 2.6.18 kernel isn't supporting stareful firewalls correctly which isn't allowing any web browsing from inside this network.

As you've already figured out, IPv6 connection tracking is completely broken in RHEL 5 and its clones/rebuilds (like CentOS 5).  Connection tracking works right in RHEL 6, so upgrading to CentOS 6 (whenever it's released) should fix this for you.

[garywsmith]

As you've already figured out, IPv6 connection tracking is completely broken in RHEL 5 and its clones/rebuilds (like CentOS 5).  Connection tracking works right in RHEL 6, so upgrading to CentOS 6 (whenever it's released) should fix this for you.

Yeah, I discovered that after playing.  I have a copy of RH6 and will play with that at home for now and then probably run CentOS when that's released.