Traffic redirection with Rasperry Pi router

I use a Rasperry Pi (running raspbian) as a wi-fi router. It redirects traffic from the Ethernet wire (eth0 - wire + ppp0 - L2TP connection, lx2tp used for it) to wlan0 (USB wi-fi dongle, hostapd used for the AP functionality).

And the problem is, some sites are loaded really slow or not loaded at all. Take for instance soundcloud .com - the command curl -L soundcloud.com performs in a snap on the router itself but hangs forever on a laptop connected to it via Wi-Fi. It must be traffic redirection issue.

Here is my /etc/network/interfaces:

pi@pi ~ $ cat /etc/network/interfaces
auto lo

iface lo inet loopback
iface eth0 inet dhcp

iface wlan0 inet static
    address 192.168.1.1
    netmask 255.255.255.0

up iptables-restore < /etc/iptables.ipv4.nat

And here are the redirection rules:

pi@pi ~ $ cat 1.sh
sudo iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
sudo iptables -A FORWARD -i ppp0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o ppp0 -j ACCEPT
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

Is there something wrong with this setup?

UPD:

Route table at the Pi:

pi@pi ~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 ppp0
10.89.64.0      *               255.255.248.0   U     0      0        0 eth0
85.21.0.0       10.89.64.1      255.255.255.0   UG    0      0        0 eth0
hdns2.corbina.n 10.89.64.1      255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
hdns1.corbina.n 10.89.64.1      255.255.255.255 UGH   0      0        0 eth0

UPD2:

Turns out is't some SSL issue (that's from vagrant Ubuntu box on the OSX host):

vagrant@precise64:~$ curl -v -L soundcloud.com/pure_virtual
* Hostname was NOT found in DNS cache
*   Trying 93.184.220.127...
* Connected to soundcloud.com (93.184.220.127) port 80 (#0)
> GET /pure_virtual HTTP/1.1
> User-Agent: curl/7.38.0
> Host: soundcloud.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Sat, 04 Apr 2015 17:38:06 GMT
< Location: https://soundcloud.com/pure_virtual
* Server am/2 is not blacklisted
< Server: am/2
< X-Frame-Options: SAMEORIGIN
< Content-Length: 0
< 
* Connection #0 to host soundcloud.com left intact
* Issue another request to this URL: 'https://soundcloud.com/pure_virtual'
* Found bundle for host soundcloud.com: 0x7f73d4f2d0b0
* Hostname was NOT found in DNS cache
*   Trying 93.184.220.127...
* Connected to soundcloud.com (93.184.220.127) port 443 (#1)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):

* Operation timed out after 0 milliseconds with 0 out of 0 bytes received
* Closing connection 1
curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

Solution 1:

Your setup appears to be perfectly standard. Which means that the problem could be any number of things.

The most direct way to find the problem would be to take a look at how the traffic is flowing using Wireshark - a program that will allow you to see how the packets are flowing using a GUI.

First, capture some data on the Raspberry Pi with the following command:

sudo tcpdump -n -w part1.pcap not port 22

(Explanation: The -n flag stops DNS resolving, since we don't care about that. The -w part1.pcap part will write the data to a pcap file so that we can feed it to WireShark later. The not port 22 will filter out the SSH traffic, which we don't care about.)

Now, with that command running, open up a second SSH connection to the Raspberry Pi and do a curl -L soundcloud.com (and other related commands). Once you are finished, go back to the first SSH window and do a "Ctrl + C" to stop the tcpdump. This will create the part1.pcap file.

For round 2, do the same thing but with a different file name, like so:

sudo tcpdump -n -w part2.pcap not port 22

Now, go manually surf to soundcloud.com on your PC. After it finishes loading, end the tcpdump with "Ctrl + C" again.

Finally, download and install Wireshark on your PC, transfer the 2 pcap files, and then use Wireshark to view them. By comparing the two files, you should find a powerful clue about what is happening.