# Configuring iptables to accept outbound connections

## mrclark219

Ok, so I am running gentoo and I wanted to use iptables to build a firewall using the stateful rules.  The problem is that now the machine that I setup the firewall wont allow outbound connections to it.  I run a backup of my other computer that sends it to this machine via ftp, but since I have setup the firewall things went a little haywire.  I can't ping the machine. I am wondering if anyone has any advice on how I can tweak my existing rules to allow this outbound connection that I need.

Here are the rules:

#!/bin/sh

export LAN=eth0

#setup logging

#iptables -N logdrop_I

#iptables -A logdrop_I -j LOG --log-prefix "DROP INPUT PACKET"

#iptables -A logdrop_I -j DROP

iptables --flush

iptables --delete-chain

iptables -A INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

#iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i ! ${LAN} -j ACCEPT

#http

iptables -A INPUT -s ipaddresses-p tcp --dport 80 -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

#samba

iptables -A INPUT -s ipaddresses-p udp -m udp --dport 137 -j ACCEPT

iptables -A INPUT -s ipaddresses-p udp -m udp --dport 138 -j ACCEPT

iptables -A INPUT -s.ipaddresses  -p tcp -m tcp --dport 139 -j ACCEPT

iptables -A INPUT -s ipaddresses-p tcp -m tcp --dport 445 -j ACCEPT

#ftp

iptables -A INPUT -p tcp --dport 20 -j ACCEPT

iptables -A INPUT -p tcp --dport 21  -j ACCEPT

#domain

iptables -A INPUT -p tcp --dport 53 -j ACCEPT

iptables -A INPUT -p udp --sport 53 -j ACCEPT

#ping

iptables -I INPUT -p icmp -j ACCEPT

#output

iptables -A OUTPUT -j ACCEPT

#log

iptables -A INPUT -p tcp -m tcpmulti --dport 22,20,21,53,80,139,445 -j LOG --log-prefix "DROP PACKET:"

iptables -A INPUT -p udp -m udpmulti --dport 137,138 -j LOG --log-prefix "DROP PACKET:"

iptables -A INPUT -p udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A OUTPUT -p tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

#iptables -A OUTPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info

#reject everything else

#iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

/etc/init.d/iptables save

----------

## jomen

If I follow your description and if I see this correctly, the problem is actually inbound connections to that machine?

Your third rule is:

```
iptables -A INPUT DROP
```

after that you only append to the INPUT-chain - which is already set to DROP

You may have meant to set a policy of DROP and then selectively open it?

```
iptables -P INPUT DROP
```

----------

## mrclark219

Ok, so I changed iptables -A INPUT DROP, to use iptables -P INPUT DROP which makes sense, and seemed to solve the ping problems that I was having.  Now, I am having trouble with nmblookup, I run the command: nmblookup -d 5 machine1 which debugs the machine1 should return the machines ip address as well, right?  Well as of now, nmblookup is failing, when it queries machine 1 and returns this message..querying neo1 on 192.168.x.x(brdcastip)......Sending a packet of len 50 to (brdcastip) on port 137

Sending a packet of len 50 to (brdcastip) on port 137

Sending a packet of len 50 to (brdcastip) on port 137

name_query failed to find name machine1

any suggestions on what I could now in this instance.

I appreciate you helping me with this situation!!

Thanks, 

Thomas Clark

----------

## jomen

I'm not proficient - only suggesting.

Not much more I can do - just spotted the glitch in the first post.

If someone knows better - please do correct!

The ports to open would be 137, 138, 139 and 445 - for both UDP and TCP.

I'm not sure if both protocols are really needed or if  eighter one is enough.

You used UDP for 137, 138 and TCP for 139, 445.

Is "brdcastip" allowed in?

 *Quote:*   

> Sending a packet of len 50 to (brdcastip) on port 137 

 

Maybe this can help?

http://troy.jdmz.net/samba/fw/

Just the first hit at google with terms: samba tcp udp ports

----------

## mrclark219

brdcastip is and actual value like 192.168.x.x for example, but yes it is allowed in...

----------

## jomen

broadcast is x.x.x.255 while normal IP's are usually not x.x.x.0 or x.x.x.1 - but everything in between up to x.x.x.254.

Did you allow the whole range like so for example?

```
iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 137 -j ACCEPT
```

With the actual values commented out in the script you posted one cannot be sure about this...

These are local only IP's - don't worry too much about posting them...

BTW: using "-p udp -m udp" is redundant

----------

## mrclark219

yeah those netwrok addresses aren't commented out anymore..And the thing still wont allow me to perform the command nmblookup, which needs to work. From what I have read, I shouldn't be able to ping, if nmblookup isnt working, but I can ping the machines.  Weird to me!

----------

## jomen

 *Quote:*   

> yeah those netwrok addresses aren't commented out anymore.

 

I meant the script you posted - your first post. There are no real adresses in there - just the word "ipaddresses" instead.

...don't know what you mean with:

 *Quote:*   

> From what I have read, I shouldn't be able to ping, if nmblookup isnt working, but I can ping the machines.

 

You have:

```
iptables -I INPUT -p icmp -j ACCEPT
```

in your scripts rules - so ping is allowed.

----------

## mrclark219

#!/bin/sh

export LAN=eth0

#setup logging

#iptables -N logdrop_I

#iptables -A logdrop_I -j LOG --log-prefix "DROP INPUT PACKET"

#iptables -A logdrop_I -j DROP

iptables --flush

iptables --delete-chain

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT ACCEPT

iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i ! ${LAN} -j ACCEPT

#http

iptables -A INPUT -s 192.168.0.0/24  -p tcp --dport 80 -j ACCEPT

#ssh

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

#samba

iptables -A INPUT -p udp -m udp --dport 137 -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 138 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 139 -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 139 -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 445 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 137 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 138 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 445 -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 137 -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 138 -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24  -p tcp -m tcp --dport 139 -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24  -p tcp -m tcp --dport 445 -j ACCEPT

#ftp

iptables -A INPUT -p tcp --dport 20 -j ACCEPT

iptables -A INPUT -p tcp --dport 21  -j ACCEPT

#domain

iptables -A INPUT -p tcp --dport 53 -j ACCEPT

iptables -A INPUT -p udp --sport 53 -j ACCEPT

#ping

iptables -I INPUT -p icmp -j ACCEPT

#output

iptables -A OUTPUT -j ACCEPT

#log

#iptables -A INPUT -p tcp -m tcpmulti --dport 22,20,21,53,80,139,445 -j LOG --log-prefix "DROP PACKET:"

#iptables -A INPUT -p udp -m udpmulti --dport 137,138 -j LOG --log-prefix "DROP PACKET:"

iptables -A INPUT -p udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info

iptables -A OUTPUT -p tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

iptables -A OUTPUT -p udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level info

#iptables -A OUTPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level info

#reject everything else

#iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

/etc/init.d/iptables save

is the script that I have, kind sir!

----------

## jomen

May I suggest to use the "Code" button next time you post code - it looks better and is more readable  :Wink: 

Sorry for saying this but: your script is unneccesarily complicated with a lot of redundancy and unused/commented out things.

I'm suggesting this:

```
#!/bin/sh

export LAN=eth0

iptables -F

# set a policy of DROP

iptables -P INPUT DROP

iptables -P FORWARD DROP

iptables -P OUTPUT DROP

# allow local-only connections

iptables -A INPUT  -i lo -j ACCEPT

# free output on any interface to any ip for any service (equal to -P ACCEPT)

iptables -A OUTPUT ACCEPT

# ACCEPT everything not from the LAN? Whats this for?

iptables -A INPUT -i ! ${LAN} -j ACCEPT

# permit answers on already established connections

# and permit new connections related to established ones (eg active-ftp)

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# http - are you running a webserver? 

# Then port 443 is missing...and ONE specific adress instead of /24 should suffice

# iptables -A INPUT -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -s 192.168.0.0/24 -p tcp -m state --state NEW --dport 80 -j ACCEPT

#ssh

iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# samba

# accept udp and tcp on all its ports - or do it more selectively if needed

iptables -A INPUT -p udp --dport 137:139 -j ACCEPT

iptables -A INPUT -p tcp --dport 137:139 -j ACCEPT

iptables -A INPUT -p udp --dport 445 -j ACCEPT

iptables -A INPUT -p tcp --dport 445 -j ACCEPT

# FTP  if you run a server - can use a wider range in the second line

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 20:21 -j ACCEPT

iptables -A INPUT -p tcp -m multiport --destination-ports 20000:20020 -j ACCEPT

# domain - here I changed -sport (in your script) to -dport in the second line

iptables -A INPUT -p tcp --dport 53 -j ACCEPT

iptables -A INPUT -p udp --dport 53 -j ACCEPT

# ping

iptables -I INPUT -p icmp -j ACCEPT

# Log everything else - before it is getting rejected  by the next rule

# or - if not catched - according to the policy

iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

#reject everything else

iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable

# maybe this too - or is this done by your init-scripts?

# /etc/init.d/iptables save
```

All needed (and some for the task unneeded) ports are open - problems should be not with iptables anymore but rather with samba itself.

----------

## mrclark219

I'm gonna try it out and see what happens.  As far as, apologizing about my code, I wouldn't worry to much about that, as we learn from trial and error.  I will let you know if this helps.  So you are saying that if this doesn't work, then I may have an issue with samba altogether? I surely hope that is not the case, but I guess we shall see, ey?

----------

## jomen

 *Quote:*   

> I wouldn't worry to much about that, as we learn from trial and error

 

right - no need to apologise - I did'nt mean it like that  :Wink: 

If you are not sure whether your samba or your script is not working as it should, why not disable the firewall completely while testing and configuring samba?

Is that not an option?

Then you know it is working and the firewall is preventing something which was working o.k. without.

----------

## mrclark219

Ok, so I tried all of your suggestions, I stopped the firewall altogether, and tried using..

```
nmblookup -d 5 neo1
```

 and the respone returned 

```
querying neo1 on 192.168.0.255

Sending a packet of len 50 to (192.168.0.255) on port 137

Received a packet of len 62 from (192.168.0.1) port 137

nmb packet from 192.168.0.1(137) header: id=622 opcode=Query(0) response=Yes

    header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes

    header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0

    answers: nmb_name=NEO1<00> rr_type=32 rr_class=1 ttl=300000

    answers   0 char ......   hex 0000C0A80001

Got a positive name query response from 192.168.0.1 ( 192.168.0.1 )

192.168.0.1 neo1<00>
```

So, I would say that samba works fine when the firewall is down, after I did that I turned the firewall back up and tried using my nmblookup command and I get the name_query error.  I'm not sure what is going on.  Bear in mind that I am trying to use your suggested script and it is still not working...Any more suggestions? Anyone?

----------

## jomen

wierd - when I ran the script - I could not even ping my Gateway - not even after flushing all the chains (iptables -F)

That clearly shows that I'm in over my head here - but learning myself while at it.

anyway

The samba server runs on the machine with the firewall - yes?

Which machines IP is 192.168.0.1 ?  - it is the Gateway

I may have overlooked something - can you try replacing the "samba" portion first with this :

```
# samba

# accept udp and tcp on all its ports - or do it more selectively if needed

iptables -A INPUT -p udp -m state --state NEW --dport 137:139 -j ACCEPT

iptables -A INPUT -p tcp -m state --state NEW --dport 137:139 -j ACCEPT

iptables -A INPUT -p udp -m state --state NEW --dport 445 -j ACCEPT

iptables -A INPUT -p tcp -m state --state NEW --dport 445 -j ACCEPT
```

and then with this (YOURIP is the outside machine trying to connect)

```
# samba

# accept udp and tcp on all its ports - or do it more selectively if needed

iptables -A INPUT -s YOURIP -p udp -m state --state NEW --dport 137:139 -j ACCEPT

iptables -A INPUT -s YOURIP -p tcp -m state --state NEW --dport 137:139 -j ACCEPT

iptables -A INPUT -s YOURIP -p udp -m state --state NEW --dport 445 -j ACCEPT

iptables -A INPUT -s YOURIP -p tcp -m state --state NEW --dport 445 -j ACCEPT
```

and see if and which one is working

Is there anything in the system-log (/var/log/messages) when the script is active and a connection is tried

(dropped packets _are_ logged before)?

----------

## Hu

Flushing a chain does not clear any associated policy.  Since you are (correctly) using policy to decide the final action for unmatched packets, flushing all chains means the policy applies to all packets.  The simplest path forward would be to lower the firewall, start net-analyzer/tcpdump with the appropriate options, run your desired query, and then examine the resulting packet capture to find exactly which protocols and ports are required.  We can then write rules to permit those.

----------

## jomen

well - Tank you!  :Smile: 

 *Quote:*   

> ...flushing all chains means the policy applies to all packets. 

 

I have my own firewall script here.

If I run it - instead of the one posted here - everything is working again (for me).

...it re - sets the policy as the first thing - just like this one...

tcpdump is a good idea - the logs (the dropped packets according to the script) should provide similar info.

But only the OP can run that diagnosis and I'm not prepared to suggest that to him - because I can't  do much more than a guess ... with the results.

What do you think is causing this script blocking a ping to 192.168.0.1 - or any connection to it/from it.

I don't understand how anything can be left after flushing all the chains.

If I flush all the chains - the policy set at the start still persists?

Why? - Can you provide a reference? (not that I doubt it - it is obviously so... but what info did I miss?)

It appears logical though  :Wink: 

How would I clear/wipe the policy (which is set to DROP everything not allowed)?

set it to ACCEPT

```

iptables -P INPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -P OUTPUT ACCEPT
```

when shutting down the script?

----------

## mrclark219

yea the machine with the firewall is also the machine that has samba on it.  As far as the suggestion go, trying your samba script does work when I run it the machine freezes up and I have to reboot to get in via ssh..I have tried 

```
tcpdump -1 etho host 192.168.0.1
```

 nothing happens it says listening on that, but it just sits there I let it sit for about 30 minutes and nothing happened...I'm so lost at this point, I just need this to work!! I didn't figure how complicated this turned out to be on what should have been relatively simple..

----------

## jomen

The tcpdump-command you posted is no good - and it should have given you an error  - or the usage instructions instead.

"-1" is not a valid switch - if it was "-I" then: no need for that if run as root - which I'd suggest

etho is not valid - it would be eth0 instead

```
tcpdump -ni eth0 ip host 192.168.0.1
```

or

```
tcpdump -ni eth0 ip host 192.168.0.1 -s 0 -A
```

would be working I suppose

 *Quote:*   

> ...trying your samba script does work

 

I think you really mean it doesn't, don't you?  :Wink: 

 *Quote:*   

> ...when I run it the machine freezes up and I have to reboot to get in via ssh..I have tried

 

if it really freezes - it is NOT the fault of the script - if you only can't get in, run:

```
iptables -F
```

plus the three commands from my previous post - it will open up the firewall completely by setting a new policy of ACCEPT everything

[edit] what about the system logs? (/var/log/messages) - on the machine running the firewall

```
watch tail /var/log/messages 
```

should do

or

CTRL+ALT+F12 to get to it (CTRL+ALT+F7 to get back to xour X session)

----------

## Hu

 *jomen wrote:*   

> tcpdump is a good idea - the logs (the dropped packets according to the script) should provide similar info.
> 
> But only the OP can run that diagnosis and I'm not prepared to suggest that to him - because I can't  do much more than a guess ... with the results.

 

I can probably do a useful job with the results of the packet capture.  I suggested tcpdump instead of the logs on the theory that the proposed rules may be overly permissive in some areas, as well as being overly restrictive in others.  The logs will tell us where the rules are overly restrictive, but only the packet capture will let us identify the minimum set of rules required to permit the desired traffic and nothing further.

The original poster's script as posted looks wrong in several areas.  For example, why does it permit all non-LAN traffic right at the start?  Usually a LAN is the trusted area and the WAN is the untrusted area.  Why log the dropped packets multiple times if they are sent to select ports?

 *jomen wrote:*   

> What do you think is causing this script blocking a ping to 192.168.0.1 - or any connection to it/from it.

 

Ping ought to work, as the script explicitly allows ICMP.  It is possible, though not likely, that the machine has been set to ignore all ICMP echo requests, in which case letting them through the firewall would be insufficient.  At this point, I think seeing the output of iptables-save -c would be more helpful than seeing the revised script.  It will show us the rules as actually loaded.

 *jomen wrote:*   

> I don't understand how anything can be left after flushing all the chains.
> 
> If I flush all the chains - the policy set at the start still persists?

 

Nothing is left.  The policy is not a rule, but a default action.

 *jomen wrote:*   

> Why? - Can you provide a reference? (not that I doubt it - it is obviously so... but what info did I miss?)

 

The iptables man page hints at this by its lack of wording to the contrary.  Specifically, it says: This  is  equivalent  to deleting all the rules one by one.  Since the policy is not a rule and cannot be deleted, it is exempt from the flush.

 *jomen wrote:*   

> How would I clear/wipe the policy (which is set to DROP everything not allowed)?
> 
> set it to ACCEPT
> 
> ```
> ...

 You must always have some policy.  Changing the policy to ACCEPT will make the rules be most like they were when you first booted.

Technically, the policy applies to any packet which reaches the end of the chain.  Accepting a packet stops its traversal of the chain.  You can also explicitly DROP or REJECT packets using a rule in the chain, which could be useful in some cases.  Rejecting a packet does not allow it, but does prevent it from reaching the end of the chain where policy would apply.  Suppose you have a subnet of 256 hosts, of which two should be rejected.  All the others should be allowed, and any traffic not from that subnet should be dropped.  The simplest way to write that is with:iptables -P INPUT DROP ; iptables -A INPUT -s badhost1 -j REJECT ; iptables -A INPUT -s badhost2 -j REJECT ; iptables -A -s goodsubnet/24 -j ACCEPT.

----------

## mrclark219

[post=][/post]This is still a problem for me.  I have tried to revise the script several times and it produces the same results the firewall starts up fine, with the exception of the name query issue.  I am not sure what the problem is here but someone said that seeing the output of iptables-save -c would help to find the problem.

 *Quote:*   

>  At this point, I think seeing the output of iptables-save -c would be more helpful than seeing the revised script. It will show us the rules as actually loaded.

 

Here's that info

```
:OUTPUT ACCEPT [2910:330879]

COMMIT

# Completed on Wed Sep  9 11:03:14 2009

# Generated by iptables-save v1.4.2 on Wed Sep  9 11:03:14 2009

*mangle

:PREROUTING ACCEPT [318788:50015830]

:INPUT ACCEPT [318788:50015830]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [219435:432498110]

:POSTROUTING ACCEPT [220907:432827405]

COMMIT

# Completed on Wed Sep  9 11:03:14 2009

# Generated by iptables-save v1.4.2 on Wed Sep  9 11:03:14 2009

*filter

:INPUT DROP [24021:2391169]

:FORWARD ACCEPT [0:0]

:OUTPUT DROP [0:0]

[238:14948] -A INPUT -p icmp -j ACCEPT

[0:0] -A INPUT -i ! eth0 -j ACCEPT

[0:0] -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT

[5207:428542] -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

[5820:467334] -A INPUT -p udp -m udp --dport 137 -j ACCEPT

[2700:636789] -A INPUT -p udp -m udp --dport 138 -j ACCEPT

[41584:6990058] -A INPUT -p tcp -m tcp --dport 139 -j ACCEPT

[0:0] -A INPUT -p udp -m udp --dport 139 -j ACCEPT

[0:0] -A INPUT -p udp -m udp --dport 445 -j ACCEPT

[0:0] -A INPUT -p tcp -m tcp --dport 137 -j ACCEPT

[0:0] -A INPUT -p tcp -m tcp --dport 138 -j ACCEPT

[238945:39054550] -A INPUT -p tcp -m tcp --dport 445 -j ACCEPT

[0:0] -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT

[0:0] -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT

[0:0] -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT

[132:18400] -A INPUT -p udp -m udp --sport 53 -j ACCEPT

[0:0] -A INPUT -p udp -m udp --dport 137:138 -j LOG --log-prefix "DROP PACKET:" --log-level 6

[0:0] -A INPUT -p tcp -m tcp --dport 20:80 -j LOG --log-prefix "DROP PACKET:" --log-level 6

[0:0] -A INPUT -p tcp -m tcp --dport 445 -j LOG --log-prefix "DROP PACKET:" --log-level 6

[9660:555500] -A INPUT -p tcp -j LOG --log-prefix "DROP PACKET:" --log-level 6

[219325:432484126] -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

[0:0] -A OUTPUT -j ACCEPT

[0:0] -A OUTPUT -p tcp -m tcp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6

[0:0] -A OUTPUT -p tcp -m tcp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6

[0:0] -A OUTPUT -p udp -m udp --sport 0:21 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6

[0:0] -A OUTPUT -p udp -m udp --sport 23:5000 -j LOG --log-prefix "DROP OUTPUT PACKET:" --log-level 6

COMMIT

# Completed on Wed Sep  9 11:03:14 2009
```

After seeing this I am still not 100 percent

----------

## mrclark219

any suggestions?

----------

