iptables and Torrents

I wish to download Torrent files to one of my computers which is
behind a Linux firewall. uTorrent is configured to use port 31234 for
incoming connections but the uTorrent Port Checker states:
Error! Port 31234 does not appear to be open.

iptables -L -v shows the counters increasing for TCP and UDP packets
to this dport but my download speed is VERY slow so I presume that the
uTorrent Port Checker is correct and detected a problem that I am not
seeing.

Can someone point out the error in my iptables config? Here are the
relevant lines:

global=xx.xx.xx.xx
bob1=192.168.0.2
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
--to $bob1
iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
--to $bob1

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT

Bittorrent client by default uses tcp 6881 to 6889 ports, you need to
open these ports on firewall. Or what ever ports that you have
configured ...

iptables -A INPUT -p tcp --destination-port 6881:6999 -j ACCEPT
iptables -A OUTPUT -p tcp --source-port 6881:6999 -j ACCEPT

if you are behind a firewall (hardware or software) you need to enable
port forwarding to internal systems....which you may have already
done ...

On Tue, 10 Jun 2008 11:07:36 -0700 (PDT), Shibu C Varughese
<(E-Mail Removed)> wrote:

>Bittorrent client by default uses tcp 6881 to 6889 ports, you need to
>open these ports on firewall. Or what ever ports that you have
>configured ...
>
>iptables -A INPUT -p tcp --destination-port 6881:6999 -j ACCEPT
>iptables -A OUTPUT -p tcp --source-port 6881:6999 -j ACCEPT
>
>if you are behind a firewall (hardware or software) you need to enable
>port forwarding to internal systems....which you may have already
>done ...

Thanks for the reply.

uTorrent is configured to use port 31234 for incoming connections. As
I understand it, this overrides the default ports 6881-6889. The
message from the uTorrent Port Checker seems to confirm this.

New packets originating from the inside network are not having a
problem getting out.

I believe that the following commands should enable port forwarding
but I admit that a mistake here could well be the source of my
problem:

iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
--to $bob1
iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
--to $bob1

Bob Simon wrote:
> I wish to download Torrent files to one of my computers which is
> behind a Linux firewall. uTorrent is configured to use port 31234 for
> incoming connections but the uTorrent Port Checker states:
> Error! Port 31234 does not appear to be open.
>
> iptables -L -v shows the counters increasing for TCP and UDP packets
> to this dport but my download speed is VERY slow so I presume that the
> uTorrent Port Checker is correct and detected a problem that I am not
> seeing.
>
> Can someone point out the error in my iptables config? Here are the
> relevant lines:
>
> global=xx.xx.xx.xx
> bob1=192.168.0.2
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
> --to $bob1
> iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
> --to $bob1
>
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
> iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
>
>

If the counters look OK maybe it's a/the windows firewall that is
blocking them. You could tcpdump on the lan facing nic to double check
they are getting through, or see what utorrent is doing to test it.

A first look the rules seem OK - but when appending you need to know
what rules are already there. I assume the default for forward has been
set to drop or everything will be ACCEPTed anyway.

If eth0 is wan and a different nic is lan you should really add -i eth0
to the DNAT rules.

It would also be better to use -m state --state NEW on the forward rules.

Andy.

Andy Furniss wrote:
> Bob Simon wrote:
>> I wish to download Torrent files to one of my computers which is
>> behind a Linux firewall. uTorrent is configured to use port 31234 for
>> incoming connections but the uTorrent Port Checker states:
>> Error! Port 31234 does not appear to be open.
>>
>> iptables -L -v shows the counters increasing for TCP and UDP packets
>> to this dport but my download speed is VERY slow so I presume that the
>> uTorrent Port Checker is correct and detected a problem that I am not
>> seeing.
>> Can someone point out the error in my iptables config? Here are the
>> relevant lines:
>>
>> global=xx.xx.xx.xx
>> bob1=192.168.0.2
>> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>> iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
>> --to $bob1
>> iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
>> --to $bob1
>>
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
>>
>>
>
> If the counters look OK maybe it's a/the windows firewall that is
> blocking them. You could tcpdump on the lan facing nic to double check
> they are getting through, or see what utorrent is doing to test it.
>
> A first look the rules seem OK - but when appending you need to know
> what rules are already there. I assume the default for forward has been
> set to drop or everything will be ACCEPTed anyway.
>
> If eth0 is wan and a different nic is lan you should really add -i eth0
> to the DNAT rules.
>
> It would also be better to use -m state --state NEW on the forward rules.
>

If the default on forward wasn't DROP and you change it you will need to
add -i eth0 to the RELATED,ESTABLISHED rule as well - unless you have
other rules to allow new connections that are not shown.

It's hard to guess what will happen without seeing the full picture when
it comes to iptables rules.

Andy.

Andy Furniss wrote:

>
> If the default on forward wasn't DROP and you change it you will need to
> add -i eth0 to the RELATED,ESTABLISHED rule as well - unless you have
> other rules to allow new connections that are not shown.

Oops I really shouldn't post at 2am.
That wouldn't work, what you would need is an ACCEPT rule for state NEW
for traffic not from the wan interface ! -i eth0.

>
> It's hard to guess what will happen without seeing the full picture when
> it comes to iptables rules.
>
> Andy.
>

On Wed, 11 Jun 2008 02:19:10 +0100, Andy Furniss
<(E-Mail Removed)> wrote:

>Bob Simon wrote:
>> I wish to download Torrent files to one of my computers which is
>> behind a Linux firewall. uTorrent is configured to use port 31234 for
>> incoming connections but the uTorrent Port Checker states:
>> Error! Port 31234 does not appear to be open.
>>
>> iptables -L -v shows the counters increasing for TCP and UDP packets
>> to this dport but my download speed is VERY slow so I presume that the
>> uTorrent Port Checker is correct and detected a problem that I am not
>> seeing.
>>
>> Can someone point out the error in my iptables config? Here are the
>> relevant lines:
>>
>> global=xx.xx.xx.xx
>> bob1=192.168.0.2
>> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>> iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
>> --to $bob1
>> iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
>> --to $bob1
>>
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
>>
>>
>
>If the counters look OK maybe it's a/the windows firewall that is
>blocking them. You could tcpdump on the lan facing nic to double check
>they are getting through, or see what utorrent is doing to test it.
>
>A first look the rules seem OK - but when appending you need to know
>what rules are already there. I assume the default for forward has been
>set to drop or everything will be ACCEPTed anyway.
>
>If eth0 is wan and a different nic is lan you should really add -i eth0
>to the DNAT rules.
>
>It would also be better to use -m state --state NEW on the forward rules.
>
>Andy.

Andy,
Thank you for your comments. The Windows Firewall setting is off for
this interface. Later today I will try to find an old ethernet hub
(repeater) and use wireshark to capture and decode traffic. As you
suggested, this should help isolate the problem.

In the mean time, I'm very interested in learning if my firewall rules
are keeping uTorrent from making the required connections -- not for
this uTorrent issue, but because I want to be sure I know how to
manage my firewall. So I've included the whole (sanitized) firewall
config file below. I welcome any suggestions you might make.

eth0 is the outside interface and eth1 is inside. The machine running
uTorrent is $bob1. 192.168.1.0 is my wireless network. 6881-6889 are
the default torrent ports but the counts on these are zero so these
statements are apparently useless -- I will remove them after I get
uTorrent working properly. Perhaps I should also mention that I'm
running an old version of linux and iptables -V shows "iptables
v1.2.7a".

Finally, please explain why you say:
>If eth0 is wan and a different nic is lan you should really add -i eth0
>to the DNAT rules.
Won't stateful inspection handle the translation of return packets
automatically?

Here's the entire config:

global=xx.xx.xx.xx
bob1=192.168.0.2
bob2=192.168.1.9

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -d $global --dport 6881:6889 -j
DNAT --to $bob1
iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
--to $bob1
iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
--to $bob1

iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob1 -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob2 -j ACCEPT
iptables -A INPUT -p icmp -i eth1 -j ACCEPT
# Remove following comment to allow return packets (normal operation)
# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -m limit --limit-burst 2 --limit
2/day -j LOG --log-prefix "Invalid SSH "

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix
"Bad IP "
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "Bad IP
"
iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -i ! eth0 -j ACCEPT
# following commands are for uTorrent
iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
iptables -A FORWARD -d $bob1 -p tcp --dport 6881:6889 -j ACCEPT
iptables -A FORWARD -m limit --limit-burst 2 --limit 4/day -j LOG
--log-prefix "New Pkt "

# iptables -I OUTPUT -j LOG --log-prefix "Out "

# Syn-flood protection
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
#Furtive port scanner
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
--limit 1/s -j ACCEPT
#Ping of death
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
1/s -j ACCEPT

Bob Simon wrote:

> Andy,
> Thank you for your comments. The Windows Firewall setting is off for
> this interface. Later today I will try to find an old ethernet hub
> (repeater) and use wireshark to capture and decode traffic. As you
> suggested, this should help isolate the problem.

tcpdump on eth1 should see what has already made it through lan bound as
it sees the traffic closer to the wire than iptables.

>
> In the mean time, I'm very interested in learning if my firewall rules
> are keeping uTorrent from making the required connections -- not for
> this uTorrent issue, but because I want to be sure I know how to
> manage my firewall. So I've included the whole (sanitized) firewall
> config file below. I welcome any suggestions you might make.

I may not be the best person to comment - my firewall is very simple,
based on Rusty Russels example in a doc on the netfilter site.

>
> eth0 is the outside interface and eth1 is inside. The machine running
> uTorrent is $bob1. 192.168.1.0 is my wireless network. 6881-6889 are
> the default torrent ports but the counts on these are zero so these
> statements are apparently useless -- I will remove them after I get
> uTorrent working properly. Perhaps I should also mention that I'm
> running an old version of linux and iptables -V shows "iptables
> v1.2.7a".
>
> Finally, please explain why you say:
>> If eth0 is wan and a different nic is lan you should really add -i eth0
>> to the DNAT rules.
> Won't stateful inspection handle the translation of return packets
> automatically?

Nothing to do with return packets, it's just being more specific. If you
wanted to, you should be able to access your box from the lan side using
the wan ip address (addresses are not really bound to nics, but owned by
the box) and that would be broken.

>
> Here's the entire config:
>
> global=xx.xx.xx.xx
> bob1=192.168.0.2
> bob2=192.168.1.9
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> iptables -t nat -A PREROUTING -p tcp -d $global --dport 6881:6889 -j
> DNAT --to $bob1
> iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
> --to $bob1
> iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
> --to $bob1
>
> iptables -P INPUT DROP
> iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob1 -j ACCEPT
> iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob2 -j ACCEPT
> iptables -A INPUT -p icmp -i eth1 -j ACCEPT
> # Remove following comment to allow return packets (normal operation)
> # iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
> iptables -A INPUT -p tcp --dport ssh -m limit --limit-burst 2 --limit
> 2/day -j LOG --log-prefix "Invalid SSH "
>
> iptables -P FORWARD DROP
> iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix
> "Bad IP "
> iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
> iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "Bad IP
> "
> iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -m state --state NEW -i ! eth0 -j ACCEPT
> # following commands are for uTorrent
> iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
> iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
> iptables -A FORWARD -d $bob1 -p tcp --dport 6881:6889 -j ACCEPT

I can't spot anything that should stop utorrent up to here. I suppose
its connectivity test may use ICMP or something so it shows a fail
because that gets blocked or maybe it expects upnp to be working. I've
never used it, but do manage to use Linux torrent/p2p with rules the
similar to these. The difference being I use -m state --state NEW as well.


> iptables -A FORWARD -m limit --limit-burst 2 --limit 4/day -j LOG
> --log-prefix "New Pkt "
>
> # iptables -I OUTPUT -j LOG --log-prefix "Out "
>
> # Syn-flood protection
> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
> #Furtive port scanner
> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
> --limit 1/s -j ACCEPT
> #Ping of death
> iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
> 1/s -j ACCEPT
>

Given you are doing nat I don't think much will make it to here, but if
it did/does the really low limit,lack of burst on the syn-flood would
mess things up for you.

Andy.

On Thu, 12 Jun 2008 12:56:40 +0100, Andy Furniss
<(E-Mail Removed)> wrote:

>Bob Simon wrote:
>
>> Andy,
>> Thank you for your comments. The Windows Firewall setting is off for
>> this interface. Later today I will try to find an old ethernet hub
>> (repeater) and use wireshark to capture and decode traffic. As you
>> suggested, this should help isolate the problem.
>
>tcpdump on eth1 should see what has already made it through lan bound as
>it sees the traffic closer to the wire than iptables.
>
>>
>> In the mean time, I'm very interested in learning if my firewall rules
>> are keeping uTorrent from making the required connections -- not for
>> this uTorrent issue, but because I want to be sure I know how to
>> manage my firewall. So I've included the whole (sanitized) firewall
>> config file below. I welcome any suggestions you might make.
>
>I may not be the best person to comment - my firewall is very simple,
>based on Rusty Russels example in a doc on the netfilter site.
>

Mine too.

>>
>> eth0 is the outside interface and eth1 is inside. The machine running
>> uTorrent is $bob1. 192.168.1.0 is my wireless network. 6881-6889 are
>> the default torrent ports but the counts on these are zero so these
>> statements are apparently useless -- I will remove them after I get
>> uTorrent working properly. Perhaps I should also mention that I'm
>> running an old version of linux and iptables -V shows "iptables
>> v1.2.7a".
>>
>> Finally, please explain why you say:
>>> If eth0 is wan and a different nic is lan you should really add -i eth0
>>> to the DNAT rules.
>> Won't stateful inspection handle the translation of return packets
>> automatically?
>
>Nothing to do with return packets, it's just being more specific. If you
>wanted to, you should be able to access your box from the lan side using
>the wan ip address (addresses are not really bound to nics, but owned by
>the box) and that would be broken.

I did not know that the address was not bound to the interface. The
reverse is true for all the routers that I've worked with.

I'm still a little hazy regarding adding eth0 to the DNAT rules. It
may help me understand your point if you posted this entire rule. Are
you saying that this would enable packets whose destination IP address
is eth0 to be NATed and forwarded to the inside? If I understand
this correctly, it seems that it would open up all the inside machines
to potential attack.

>
>>
>> Here's the entire config:
>>
>> global=xx.xx.xx.xx
>> bob1=192.168.0.2
>> bob2=192.168.1.9
>>
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>> iptables -t nat -A PREROUTING -p tcp -d $global --dport 6881:6889 -j
>> DNAT --to $bob1
>> iptables -t nat -A PREROUTING -p tcp -d $global --dport 31234 -j DNAT
>> --to $bob1
>> iptables -t nat -A PREROUTING -p udp -d $global --dport 31234 -j DNAT
>> --to $bob1
>>
>> iptables -P INPUT DROP
>> iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob1 -j ACCEPT
>> iptables -A INPUT -p tcp --dport ssh -i eth1 -s $bob2 -j ACCEPT
>> iptables -A INPUT -p icmp -i eth1 -j ACCEPT
>> # Remove following comment to allow return packets (normal operation)
>> # iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
>> iptables -A INPUT -p tcp --dport ssh -m limit --limit-burst 2 --limit
>> 2/day -j LOG --log-prefix "Invalid SSH "
>>
>> iptables -P FORWARD DROP
>> iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix
>> "Bad IP "
>> iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
>> iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "Bad IP
>> "
>> iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP
>> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>> iptables -A FORWARD -m state --state NEW -i ! eth0 -j ACCEPT
>> # following commands are for uTorrent
>> iptables -A FORWARD -d $bob1 -p tcp --dport 31234 -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p udp --dport 31234 -j ACCEPT
>> iptables -A FORWARD -d $bob1 -p tcp --dport 6881:6889 -j ACCEPT
>
>I can't spot anything that should stop utorrent up to here. I suppose
>its connectivity test may use ICMP or something so it shows a fail
>because that gets blocked or maybe it expects upnp to be working. I've
>never used it, but do manage to use Linux torrent/p2p with rules the
>similar to these. The difference being I use -m state --state NEW as well.

Good points. Thanks.

>> iptables -A FORWARD -m limit --limit-burst 2 --limit 4/day -j LOG
>> --log-prefix "New Pkt "
>>
>> # iptables -I OUTPUT -j LOG --log-prefix "Out "
>>
>> # Syn-flood protection
>> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
>> #Furtive port scanner
>> iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit
>> --limit 1/s -j ACCEPT
>> #Ping of death
>> iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
>> 1/s -j ACCEPT
>>
>
>Given you are doing nat I don't think much will make it to here, but if
>it did/does the really low limit,lack of burst on the syn-flood would
>mess things up for you.

Thanks for your comments. I will fix this.

>Andy.
Bob

Bob Simon wrote:

>> Nothing to do with return packets, it's just being more specific. If you
>> wanted to, you should be able to access your box from the lan side using
>> the wan ip address (addresses are not really bound to nics, but owned by
>> the box) and that would be broken.
>
> I did not know that the address was not bound to the interface. The
> reverse is true for all the routers that I've worked with.

Maybe - I've only really used Linux for routing and that is the default
situation.

>
> I'm still a little hazy regarding adding eth0 to the DNAT rules. It
> may help me understand your point if you posted this entire rule. Are
> you saying that this would enable packets whose destination IP address
> is eth0 to be NATed and forwarded to the inside? If I understand
> this correctly, it seems that it would open up all the inside machines
> to potential attack.

I assume your wan ip address $global is on eth0.
I mean adding -i eth0 to the DNAT rules so that they only apply to
packets that came in on eth0. Packets that come in from the lan on eth1
that are headed for $global should not be DNATed but your current rule
will do that.

iptables -t nat -A PREROUTING -i eth0 -p tcp -d $global --dport 31234 -j
DNAT --to $bob1