I sometimes need to access Google through the w3m text-mode Web browser on my Linode, and I've been having intermittent issues doing so.

I sometimes get the "We're sorry" or "unusual traffic" error when I try to perform a Google search from my Linode with IPv6 enabled. When I force w3m to use IPv4 only (using the -4 parameter), the problem clears up.

There is no suspicious activity whatsoever coming from my server. If there was malware on my server causing this, I would be reading a significant amount of IPv6 network activity on the Linode Manager, and I don't see any sign of trouble there. I have also been monitoring my server using htop and could not find any suspicious processes or activity. The firewall is configured to allow only HTTP and SSH traffic, and SSH is set up to only allow logins using public keys, not passwords. I have not seen any record of an unauthorized login into my server. A ClamAV scan finds no infected files.

Is Google blocking a range of IP addresses? I have read about Rackspace Cloud and other VPS users being affected by this issue. There's a good chance there are several Linodes running automated Google queries, probably to check search engine rankings. I would never be running these sorts of queries. To make it clear, only IPv6 is affected.

--DragonLord

_________________
House of DragonLord, powered by openSUSE

I'm having the same problem. Google appears to be blocking Linode's default ipv6 network.

According to this other post (viewtopic.php?f=20&t=10337) asking for and configuring a /64 pool should resolve the problem.

I've requested and configured an ip from a pool assigned to my linode, but unfortunately it has not resolved the problem. The pool appears to be forwarded to the original ip handed out using dhcp, so Google is still blocking the traffic.

I'm not sure how to resolve at this point. Disabling ipv6 works but that seems like the wrong tactic.

I know very little about IPv6, but according to this thread you may need to futz with your configuration to get your Linode to use a particular address as the source address.

Since the issue appears to be with the default auto-configured Linode block, you might try disabling auto-configuration (net.ipv6.conf.*.autoconf or /proc/sys/net/ipv6/conf/*/autoconf) to ensure you don't pick up an auto-configured address, leaving only the static entry from your personal block.

You'd need to add the relevant setting to sysctl.conf to ensure it was retained across a reboot. Also, disabling autoconf won't (I believe) remove an existing auto-configured address, but you'll be able to delete it manually and not have it come back. Or you can bounce the interface or reboot without picking it up.

Otherwise, you'll have to get into details of source address selection when multiple addresses of the same address family exist on the same interface (RFC3484 is the reference). You could deprecate an address (http://www.davidc.net/networking/ipv6-s ... tion-linux), or in more recent kernels have more control over selection priorities (see "ip addrlabel")

But in this case, since the one you don't want is always the auto-configured one, disabling that seems simplest.

-- David

I don't think that will work, db3l. Your block of IPs is routed through your main IP -- if you disable it, you'll lose IPv6 connectivity.

You can, of course, disable autoconfiguration and configure your main IP -- and route -- statically, but you can't remove it entirely.

_________________
Matt Nordhoff (aka Peng on IRC)

Hmm, are you sure? I just manually deleted the auto-configured address on one of my Linodes, added an address from my local 4096-address pool and it works fine. Though there are some differences between the 4096-address pool and a /56.

The 4096-address pools work through neighbor solicitation, so shouldn't have any dependency on other addresses. That's also why you can assign addresses from those pools arbitrarily to any Linode.

If you've also requested a /56 it does have to be explicitly routed through some other address. So if you chose an auto-configured address for that purpose then yes, it has to remain active, so avoiding it for outbound traffic probably requires the deprecation approach. But what I did for my /56, and what I think is more flexible, is to route the /56 through an address from the 4096-address pool. That way, your /56 will automatically route to whatever Linode you choose to assign that pool address and avoids any hardcoded dependency on a specific Linode.

-- David

After a little bit of work to get the /64 up and running properly, it appears the traffic is now being sourced from the new address. Even though it says the /64 pool is "routed" to the original offending IP, Google doesn't seem to be blocking the traffic.

Note that my IP is crafted in a way that allows neighbor solicitation -- I'm not sure if that helps source the address correctly. You can look here for more details on that little bit of troubleshooting.

Also, if you're having a hard time troubleshooting where the packets are coming from you can use this:

# tcpdump -t -n -i eth0 -s 512 -vv ip6 or proto ipv6

I used it to inspect that packets being sent over the interface to Google were coming from the correct address. It works from the machine or if you're forwarding traffic (using a SOCKS tunnel for instance).

--
edit for tcpdump info

The next hop for the routed /64 is only used for inbound routing back to the /64 (e.g., how the public network reaches your Linode). Roughly, IP routing works with each step saying "I want to get to X, who (Y) should I send this to next" where X is the final address and Y is some intermediate address directly attached to the current box. That keeps happening until someone - your Linode in this case - says "no further, I'm X". So the route set up by Linode for your /64 is what lets that work for the very last hop (from Linode's routers to your personal Linode).

Anyway, that routing configuration is not something a destination site has any visibility to when they receive traffic from your Linode - they'll just see the source address selected for the traffic by your Linode.

-- David