As part of getting the IPv6 tunnel functioning, I mentioned I’d had to take out the NetGear VPN. Unfortunately, it’s really needed for the VPN function, so I restored the the full outer-inner router arrangement yesterday.
The VPN wouldn’t come up. Stephen poked at it, but didn’t change anything. Mysteriously, though, a few hours later, not only did the VPN come back up, but the NetGear firewall rules started magically working, meaning we now have a functioning SLO-Appleton IPv6 connection via the IPv4 tunnel.
While I’m able to ping6 SLO from Appleton, the reverse situation is a bit strange, because one of the two firewalls involved is dropping packets. Now that we’ve demonstrated that it’s possible to get this system going, I’m not going to worry about this for the moment. The important part was demonstrating that it’s possible to get IPv6 packets from one place to another over a non-trivial network path.
Here’s a screenshot from a Wireshark session on frith.vsi.dom showing the pinging from Appleton
Appleton pinging SLO
SLO –> Appleton (Chicago POP, actually)
Accessing Google IPv6 site. Big deal? Check out the URL
IMPORTANT NOTE: Unlike IPv4 addresses, which can be used directly as URIs in Firefox and Internet Exploder, IPv6 addresses must be enclosed in square brackets: http://[2001:4860:800b::93]/ (this is one of the resolved addresses for IPv6.google.com). Owing to some of the vagaries of the DNS configuration in Appleton, IPv6 names aren’t resolving correctly, but the packets are coming and going correctly. Here it is from Appleton.
Yay! Two things work! Sure, it’s mysterious that routes that didn’t work yesterday are working now, but I’m not one to punch a gift horse in the mouth – it might bite me.