# Increased latency while webbrowsing with iptables loaded...

## moot_point

I don't have alot of experience with iptables. In fact, I've just recently attempted to configure this firewall script after not using iptables for roughly a year. I'm having severe latency issues while web browsing with the firewall up. Soon as I turn it off surfing the same pages loses the increased latency issue and then I'm back on an actual dsl line. Can someone take a look at this script and tell me what they think might be causing this issue? 

```
#!/bin/sh

#

# Written by gw

# Basic script to allow certain ports in, log and drop the rest. And all 

# while keeping loopback fully opened to traffic. Also only allows

# ping reply and traceroute ICMP packets.

# set a few variables

export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

iptables="/sbin/iptables"

 

# adjust /proc

if [ -e /proc/sys/net/ipv4/tcp_syncookies ]; then echo 1 > /proc/sys/net/ipv4/tcp_syncookies; fi

if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter; fi

 

# flush any existing chains and set default policies

$iptables -F INPUT

$iptables -F OUTPUT

$iptables -P INPUT DROP

$iptables -P OUTPUT ACCEPT

 

# allow all packets on the loopback interface

$iptables -A INPUT -i lo -j ACCEPT

$iptables -A OUTPUT -o lo -j ACCEPT

 

# allow established and related packets back in

$iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

 

# tcp

$iptables -A INPUT -p tcp --dport 2106:2706 -j ACCEPT 

$iptables -A INPUT -p tcp --dport 6881:6999 -j ACCEPT

$iptables -A OUTPUT -p tcp --sport 21 -j ACCEPT

# icmp

$iptables -A OUTPUT -p icmp -m state --state NEW -j ACCEPT

$iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

$iptables -A INPUT -p icmp --icmp-type echo-request -i eth0 -j DROP

 

# logging

$iptables -A INPUT -i eth0 -p tcp -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "

$iptables -A INPUT -i eth0 -p udp -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "udp connection: "

# drop all other packets

$iptables -A INPUT -i eth0 -p tcp --dport 0:65535 -j DROP

```

----------

## vaguy02

I new to IPTABLES as well but it looks to me like you are dropping or attempting to drop port 80 and 443 if they aren't related or established. This could be causing your problems with webbrowsing since they are the web browsing ports to begin with. Just a though, probably wrong about that though.

----------

## moot_point

I would have thought since I made the outbound request to the webserver that the incoming packets would be interpreted as ESTABLISHED or RELATED.. although this might be a reason for my issue. Can anyone verify this? I appreciate the response btw and plan on looking into it. I assume that I would need an open OUTBOUND port of 80 then? Or? Appreciate any helpful responses to this.

----------

## vaguy02

Well normally http is 80 and https is 443. I completely understand your logic about the INPUT being already established but it was the only thing that I could think of at the time that might be causing it. Try opening those ports on the incoming and outgoing and see if it makes a difference. If it doesn't then I'm wrong and I will go stand in the corner and be quiet.

----------

## moot_point

Appreciate the feedback before and now. Apparently sometimes logic doesn't make all that much sense either. And never stand in the corner and be quiet when you have an opinon to voice! Especially in this case. I opened up OUTPUT ports 80,443 and now I recieve 0 latency time on _any_ websites with the firewall up this is great. But INPUT is only if you were being connected to hence I've left those closed.

Can someone link me to somewhere or explain to me why the ESTABLISHED, RELATED states didn't already do this for me? I know I'm a bit nieve on the way packets traverse thru the net but logically to me it would seem that once I initiate the connection the packets back would be covered by such a rule. ;/

----------

## splooge

I've removed the redundancy in your script and eliminated the unneeded, try this:

 *Quote:*   

> # flush any existing chains and set default policies
> 
> $iptables -F INPUT
> 
> $iptables -F OUTPUT
> ...

 

----------

## moot_point

Thank you for the cleanup. I notice this also works. I'm extremely curious to how but I don't expect anyone to spoon feed me although cleaning it up and having it still work is somewhat along those lines.  :Wink: )) Anyways, I'll take a jab why this works and perhaps someone can correct me if I'm wrong? I'd love to learn from my mistake. 

I noticed you removed the line that drops all remaining packets. I can only assume that without this line I'll recieve _all_ requests whether input/output/etc. As I don't see where they are being dropped. But I'll test this first. If this is not the reason this "new" script works than why does it? Aside from the cleanup it looks to be the same, in terms of function, as how I had it.

Perhaps it was misunderstood why I had it log the remaining packets and then drop them after? Does putting the log line automatically take the packet out of the loop and just log it? Would having the drop rule afterwards never be reached? A little confused about that.

----------

## vaguy02

Maybe I can help a little bit. The log does not remove it from further consideration by IPTABLES it simply adds that attempt to the log file on your computer to allow you to see those attempts and you can also include a comment infront of it to tell you what that line in the log is refering to. It is a very good idea to look at your log files frequently because this way you can see possible breakin attempts if configured like that and also helps you find problems with programs and with the kernel.

I'm not sure about your other question, maybe someone else can answer that one.  :Very Happy: 

----------

## swanson

 *Quote:*   

> 
> 
> $iptables -A INPUT -i eth0 -p tcp -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "
> 
> $iptables -A INPUT -i eth0 -p udp -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "udp connection: " 
> ...

 

These two are wrong. Although rate limited, they are still matching against every single packet, not just new connections. As UDP is stateless you can't match NEW connections and you'll get heartly sick of these being logged... Trust me, ignore UDP.

So for the TCP you probably just want to match all new packets which would include sneaky port scans;

```

$iptables -A INPUT -i eth0 -p tcp -m --state NEW -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "

```

Or just match TCP syn packets used to open connections and would be infinitesimally quicker than the using state match above;

```

$iptables -A INPUT -i eth0 -p tcp -m tcp --syn -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "

```

----------

## DaveArb

 *moot_point wrote:*   

> Perhaps it was misunderstood why I had it log the remaining packets and then drop them after? Does putting the log line automatically take the packet out of the loop and just log it? Would having the drop rule afterwards never be reached? A little confused about that.

 

Your INPUT chain's policy (line 4 of Splooge's cleanup) is DROP. Anything on input that hits the bottom is dropped for this reason.

Dave

----------

## moot_point

I just wanted to say thanks for the help guys. Learned a few things about iptables today. Just understanding the things you guess showed me and thinking of ways to add onto that was alot but I've been digging thru the iptables site all afternoon lol.  :Smile:  Btw, just in case anyone cares I decided on cutting the udp log, logging tcp syn packets, and I've added a few extra ports I needed for services. Have a few other ideas in mind but they can wait til after the weekend.

 -moot

----------

## magic919

Looks like this has all gone well.  I find the output of 

```
iptables -L -n -v 
```

 easier to fathom than the iptables set-up scripts.

----------

## neuron

sitting here reading this thread, because I've had a bit of latency on my web browsing running it through my server too, and I'm really confused what he did wrong.

he's defaulting the output chain to accept, why is that related to ports in his input chain?

----------

## magic919

I don't think I follow some of the arguments put forward either.  I'd say keep the firewall as simple as possible.  I run the Output chain as Accept and with no rules.  I accept lo and LAN at the top of input, then Established, Related.  Then I run the traffic via a Thru chain to Accept wanted incoming ports.  I run Input with Drop as default.  www.pettingers.org helped me.

Post your iptables -L -n -v.

----------

## neuron

http://hollowtube.mine.nu/iptables

----------

## moot_point

Hey all. I'm not sure I understand some of the concerns about previously relayed information and perhaps it's just not clear what I decided to go with. I do agree though with the thoughts of the input of 'iptables -v -n -L' being easier to read. Wish I had this command before. Anyways I'm still having a slight issue. It seems that somehow I have a log in their for udp which obviously isn't in my iptables script. Check it out..

```
Chain INPUT (policy DROP 73 packets, 12938 bytes)

 pkts bytes target     prot opt in     out     source               destination         

 278K   14M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           

  41M   19G ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

5062K  255M ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpts:2106:2706 

    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

19217 1767K DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 8 

69149 4537K LOG        tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 5 tcp LOG flags 0 level 4 prefix `tcp connection: ' 

20333 7627K LOG        udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           limit: avg 1/sec burst 5 udp LOG flags 0 level 4 prefix `udp connection: ' 

76611 5048K DROP       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp 

22491 7854K DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 47M packets, 7291M bytes)

 pkts bytes target     prot opt in     out     source               destination         

 278K   14M ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           

  238 19992 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW 

```

And the firewall script I currently use is...

```
# flush any existing chains and set default policies 

$iptables -F INPUT 

$iptables -F OUTPUT 

$iptables -P INPUT DROP 

#Allow all input on all interfaces EXCEPT the internet interface 

$iptables -A INPUT ! eth0 -j ACCEPT 

# allow established and related packets back in 

$iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT 

# tcp 

$iptables -A INPUT -p tcp --dport 2106:2706 -j ACCEPT 

$iptables -A INPUT -p tcp --dport 6881:6999 -j ACCEPT 

# icmp 

$iptables -A INPUT -p icmp --icmp-type echo-request -i eth0 -j DROP 

# logging 

$iptables -A INPUT -i eth0 -p tcp -m tcp --syn -m limit --limit 15/s --dport 0:65535 -j LOG --log-prefix "tcp connection: "
```

I've restarted the script a few times with '/etc/init.d/iptables restart' but it still shows up as logging udp packets and the table just doesn't look right to me. ;/

----------

## magic919

Got to watch things here.  Change the IPTable then run /etc/init.d/iptables save.  Or you can just end up saving and restoring the old table.

----------

