5

I'm having a problem connecting to Raspbmc through my NAT firewall... My setup is like this :

raspbmc     <--LAN--> (eth1) router (eth0)  <--WAN--> work
192.168.1.3           192.168.1.2   5.6.7.8           1.2.3.4

I have forwarded the ports, and can confirm via tcpdump that the SYN packets are arriving at the Pi. However userspace never receives them! I have confirmed this using 3 different applications (pyroTorrent, XBMC web interface, and nc), and all give no response to the packet shown in tcpdump.

It works fine from the LAN, and I can get it to work by adding the following to my router's iptables config, but this is really ugly and I would like to get it to work without resorting to such manipulation :

iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 5555 -j MASQUERADE

I checked and the rp_filter is set to 0 for all interfaces on the Pi. Also, iptables is empty and has default policy ACCEPT for everything. Did I miss something specific to Raspbmc/Raspbian?

Thanks in advance for any help/pointers :)

Thomas

Here is the relevant output of iptables-save on the router :

# Generated by iptables-save v1.4.8 on Wed Feb 20 14:20:23 2013
*mangle
:PREROUTING ACCEPT [6829322:4371711949]
:INPUT ACCEPT [11442:1053089]
:FORWARD ACCEPT [6817880:4370658860]
:OUTPUT ACCEPT [7244:653426]
:POSTROUTING ACCEPT [6825030:4371216486]
COMMIT
# Completed on Wed Feb 20 14:20:23 2013
# Generated by iptables-save v1.4.8 on Wed Feb 20 14:20:23 2013
*nat
:PREROUTING ACCEPT [2834:249851]
:POSTROUTING ACCEPT [1124:63804]
:OUTPUT ACCEPT [78:5781]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5555 -j DNAT --to-destination 192.168.1.3:5555
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Wed Feb 20 14:20:23 2013
# Generated by iptables-save v1.4.8 on Wed Feb 20 14:20:23 2013
*filter
:INPUT DROP [3875:330500]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [6557:589075]
-A INPUT -s 127.0.0.1/32 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -m state --state NEW -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1 -o eth0 -j ACCEPT
-A FORWARD -s 1.2.3.4/32 -d 192.168.1.3/32 -i eth0 -o eth1 -p tcp -m tcp --dport 5555 -j ACCEPT
COMMIT

And here is the tcpdump showing no reply from WAN, but successful transaction from LAN :

pi@raspbmc:~/pyrotorrent$ netstat -alpn|grep python
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:5555            0.0.0.0:*               LISTEN      7917/python

pi@raspbmc:~/pyrotorrent$ sudo tcpdump -vv 'port 5555'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:36:56.038955 IP (tos 0x0, ttl 112, id 22881, offset 0, flags [DF], proto TCP (6), length 52)
    1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (correct), seq 83867849, win 8192, options [mss 1340,nop,wscale 8,nop,nop,sackOK], length 0
14:36:56.286900 IP (tos 0x0, ttl 112, id 22895, offset 0, flags [DF], proto TCP (6), length 52)
    1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (correct), seq 534844751, win 8192, options [mss 1340,nop,wscale 8,nop,nop,sackOK], length 0
14:36:59.044256 IP (tos 0x0, ttl 112, id 22922, offset 0, flags [DF], proto TCP (6), length 52)
    1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x038d (correct), seq 83867849, win 8192, options [mss 1340,nop,wscale 8,nop,nop,sackOK], length 0
14:36:59.278972 IP (tos 0x0, ttl 112, id 22923, offset 0, flags [DF], proto TCP (6), length 52)
    1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x4dba (correct), seq 534844751, win 8192, options [mss 1340,nop,wscale 8,nop,nop,sackOK], length 0
14:37:05.040700 IP (tos 0x0, ttl 112, id 22942, offset 0, flags [DF], proto TCP (6), length 48)
    1.2.3.4.26741 > 192.168.1.3.5555: Flags [S], cksum 0x179c (correct), seq 83867849, win 8192, options [mss 1340,nop,nop,sackOK], length 0
14:37:05.280175 IP (tos 0x0, ttl 112, id 22943, offset 0, flags [DF], proto TCP (6), length 48)
    1.2.3.4.42720 > 192.168.1.3.5555: Flags [S], cksum 0x61c9 (correct), seq 534844751, win 8192, options [mss 1340,nop,nop,sackOK], length 0
14:37:12.148221 IP (tos 0x0, ttl 64, id 15015, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.53754 > 192.168.1.3.5555: Flags [S], cksum 0x92c6 (correct), seq 4011566171, win 5840, options [mss 1460,sackOK,TS val 16031484 ecr 0,nop,wscale 5], length 0
14:37:12.148569 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.3.5555 > 192.168.1.2.53754: Flags [S.], cksum 0x8384 (incorrect -> 0xa57e), seq 1622032073, ack 4011566172, win 14480, options [mss 1460,sackOK,TS val 7482252 ecr 16031484,nop,wscale 6], length 0
14:37:12.149062 IP (tos 0x0, ttl 64, id 15016, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.2.53754 > 192.168.1.3.5555: Flags [.], cksum 0x0c23 (correct), seq 1, ack 1, win 183, options [nop,nop,TS val 16031484 ecr7482252], length 0
14:37:12.149450 IP (tos 0x0, ttl 64, id 15017, offset 0, flags [DF], proto TCP (6), length 161)
    192.168.1.2.53754 > 192.168.1.3.5555: Flags [P.], cksum 0x75ee (correct), seq 1:110, ack 1, win 183, options [nop,nop,TS val 16031484 ecr 7482252], length 109
14:37:12.149615 IP (tos 0x0, ttl 64, id 5446, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.3.5555 > 192.168.1.2.53754: Flags [.], cksum 0x837c (incorrect -> 0x0b8a), seq 1, ack 110, win 227, options [nop,nop,TS val 7482252 ecr 16031484], length 0
14:37:12.574406 IP (tos 0x0, ttl 64, id 15018, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.2.53754 > 192.168.1.3.5555: Flags [F.], cksum 0x0b8a (correct), seq 110, ack 1, win 183, options [nop,nop,TS val 16031527ecr 7482252], length 0
14:37:12.604953 IP (tos 0x0, ttl 64, id 5447, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.3.5555 > 192.168.1.2.53754: Flags [.], cksum 0x837c (incorrect -> 0x0b30), seq 1, ack 111, win 227, options [nop,nop,TS val 7482298 ecr 16031527], length 0
14:37:13.080329 IP (tos 0x0, ttl 64, id 5448, offset 0, flags [DF], proto TCP (6), length 69)
    192.168.1.3.5555 > 192.168.1.2.53754: Flags [P.], cksum 0x838d (incorrect -> 0x4b23), seq 1:18, ack 111, win 227, options [nop,nop,TS val 7482345 ecr 16031527], length 17
14:37:13.080861 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.2.53754 > 192.168.1.3.5555: Flags [R], cksum 0xb0f6 (correct), seq 4011566282, win 0, length 0
Improve this question
1
  • Huumm, i am not a network specialist...but i am very interested by any answer. I only can confirm with the final version of Raspbmc i am not able to connect to my nGinx Web Server from Internet. And this was worrking on the RC 4 :(
    – sstassin
    Feb 21, 2013 at 11:05

1 Answer 1

Reset to default
6

Due to people exposing SSH without changing the default password, I added some basic rules that restrict network access to LAN only. In a couple of days there'll be an option to disable these from Raspbmc's XBMC settings plugin, but for now, you can see this thread for advice

http://forum.stmlabs.com/showthread.php?tid=6726

Cheers

Improve this answer
1
  • Ah thanks... I only checked with iptables-save which returned blank, but now with iptables -L I see the rules.
    – Thomas
    Feb 25, 2013 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.