(Strange situation, doesn't something like the triangle inequality hold for internet routing?)
Anyway, try the following, on A, ssh into B with a -D argument,
ssh -D 1080 address-of-B
which acts as a SOCKS5 proxy on 127.0.0.1:1080, which can be used by anything supporting SOCKS5 proxied connections. Apparently, wget can do this, by using the environment variable
export SOCKS_SERVER=127.0.0.1:1080
wget http://server-C/whatever
Note that sometimes curl is more handy (i.e. I'm not sure if wget can do hostname lookups via SOCKS5; but this is not one of your concerns I suppose); also Firefox is able to work completely through such a SOCKS5 proxy.
Edit I've just now noticed that you're looking for a one-line solution. Well, how about
ssh address-of-B 'wget -O - http://server-C/whatever' >> whatever
i.e. redirection the wget-fetched output to stdout, and redirecting the local output (from ssh running wget remotely) to a file.
This seems to work, the wget output is just a little confusing ("saved to -"), you can get rid of it by adding -q to the wget call.
There is most likely a NAT-firewall between you and the servers showing the symptom. (NAT-firewalls hide a whole network behind a single IP-number).
The problem is that ftp wants to send the data resulting from the command in a new, separate TCP/IP connection and that cannot go through the firewall because it needs to go from the server to you, and you are hidden behind the firewall which has no clue that the data is intended for your machine. When the FTP protocol was designed, many modern devices like the NAT-router (which became necessary when there were more devices than available IP-addresses) had not been invented yet.
Use the pasv command (may be called something different in your client) to change to a passive connection where data connections go from you to the server.
See http://slacksite.com/other/ftp.html for a more detailed explanation.
Best Answer
with curl: