# iptable vpn rules not correct.[/SOLVED]

## dustfinger

Below are my current iptable rules.  I would like to be able to establish a vpn connection from behind my router to <DESTINATION-IP/>.  With my current rules I am unable to make the connection.  I am not certain why I am unable to make this connection.  Does anyone see anything wrong with my current rules?

```

IPTABLES='/sbin/iptables'

#set interface values

EXTIF='eth1'

INTIF='eth0'

#enable ip forwarding in the kernel

/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

#flush rules and delete chains

$IPTABLES -F

$IPTABLES -X

$IPTABLES -F FORWARD

$IPTABLES -P FORWARD DROP

# Drop Internet traffic from private IP ranges

$IPTABLES -A FORWARD -i $EXTIF -s 10.0.0.0/8 -j DROP

$IPTABLES -A FORWARD -i $EXTIF -s 172.16.0.0/12 -j DROP

$IPTABLES -A FORWARD -i $EXTIF -s 192.168.0.0/16 -j DROP

# Drop traffic which should stay in the local network

$IPTABLES -A FORWARD -i $INTIF -d 192.168.1.0/16 -j DROP

# Drop traffic which is trying to leave the local network, but appears

# not to have originated locally

$IPTABLES -A FORWARD -i $INTIF -s ! 192.168.1.0/24 -j DROP

# Drop traffic which the kernel thinks is INVALID

$IPTABLES -A FORWARD -m state --state INVALID -j DROP

# Allow traffic for existing connections to pass

# Note: requires stateful match support in the kernel

$IPTABLES -A FORWARD -i $EXTIF -p tcp -m state --state ESTABLISHED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTIF -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow internal hosts to use TCP and UDP freely

$IPTABLES -A FORWARD -i $INTIF -p tcp -j ACCEPT

$IPTABLES -A FORWARD -i $INTIF -p udp -j ACCEPT

#echo -e "--> enable masquerading to allow LAN internet access"

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

#echo -e "--> forward LAN traffic from $INTIF to Internet interface $EXTIF"

$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -m state --state NEW,ESTABLISHED -j ACCEPT

#echo -e "       - Allowing access to VPN"

$IPTABLES -A PREROUTING -t nat -p gre -i $INTIF -j DNAT --to-destination <DESTINATION-IP/>

$IPTABLES -A PREROUTING -t nat -p tcp --dport 1723 -i $INTIF -j DNAT --to-destination <DESTINATION-IP/>:1723

##block out all other Internet access on $EXTIF

$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,INVALID -j DROP

$IPTABLES -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP

```

** EDIT #1 **

I thought that the output from iptables-save -c might be helpful.

Note: I replaced the actual destination ip with <DESTINATION-IP/> and the actual firewall ip with <FIREWALL-IP/>

```

# iptables-save -c

*filter

:INPUT ACCEPT [1467011:501780312]

:FORWARD DROP [95:6495]

:OUTPUT ACCEPT [1717793:455125028]

[411:27276] -A INPUT -i eth1 -m state --state INVALID,NEW -j DROP 

[0:0] -A FORWARD -s 10.0.0.0/255.0.0.0 -i eth1 -j DROP 

[0:0] -A FORWARD -s 172.16.0.0/255.240.0.0 -i eth1 -j DROP 

[0:0] -A FORWARD -s 192.168.0.0/255.255.0.0 -i eth1 -j DROP 

[3:144] -A FORWARD -d 192.168.0.0/255.255.0.0 -i eth0 -j DROP 

[0:0] -A FORWARD -s ! 192.168.1.0/255.255.255.0 -i eth0 -j DROP 

[0:0] -A FORWARD -m state --state INVALID -j DROP 

[1611:1213551] -A FORWARD -i eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT 

[25:1900] -A FORWARD -i eth1 -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT 

[1670:255712] -A FORWARD -i eth0 -p tcp -j ACCEPT 

[28:2128] -A FORWARD -i eth0 -p udp -j ACCEPT 

[48:2731] -A FORWARD -i eth0 -o eth1 -m state --state NEW,ESTABLISHED -j ACCEPT 

[0:0] -A FORWARD -i eth1 -m state --state INVALID,NEW -j DROP 

COMMIT

# Completed on Sun Oct 14 11:43:43 2007

# Generated by iptables-save v1.3.8 on Sun Oct 14 11:43:43 2007

*nat

:PREROUTING ACCEPT [55215:3940008]

:POSTROUTING ACCEPT [177:45264]

:OUTPUT ACCEPT [2705:214624]

[0:0] -A PREROUTING -i eth1 -p gre -j DNAT --to-destination <DESTINATION-IP/>

[0:0] -A PREROUTING -i eth1 -p tcp -m tcp --dport 1723 -j DNAT --to-destination <DESTINATION-IP/>:1723 

[0:0] -A PREROUTING -i eth1 -p gre -j DNAT --to-destination  <DESTINATION-IP/>

[0:0] -A PREROUTING -i eth1 -p tcp -m tcp --dport 1723 -j DNAT --to-destination <DESTINATION-IP/>:1723 

[1:57] -A PREROUTING -i eth0 -p gre -j DNAT --to-destination <DESTINATION-IP/>

[6:288] -A PREROUTING -i eth0 -p tcp -m tcp --dport 1723 -j DNAT --to-destination <DESTINATION-IP/>:1723 

[0:0] -A PREROUTING -d <FIREWALL-IP/> -p gre -j DNAT --to-destination <DESTINATION-IP/>

[0:0] -A PREROUTING -d <FIREWALL-IP/> -p tcp -m tcp --dport 1723 -j DNAT --to-destination <DESTINATION-IP/>:1723 

[27021:1536055] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

[0:0] -A POSTROUTING -o eth1 -j MASQUERADE 

COMMIT

```

************

** EDIT #2 **

I have a windows box on the network now and using the microsoft vpn connection I can get as far as verifying username and password, but then it times out.  If I remove my router then I am successfully authorized and connect to the network via vpn just fine.  It is only when I am behind my router that I timeout on while my username and password is being verified.  This tells me that I must have established a connection with the vpn server, but something was being blocked by my router to prevent the authorization.  Any ideas what might be happening in this case?

************

Thank you in advance to anyone that has suggestions.

dustfinger.

----------

## rhavens

 *dustfinger wrote:*   

> Below are my current iptable rules.  I would like to be able to establish a vpn connection from behind my router to <DESTINATION-IP/>.  With my current rules I am unable to make the connection.  I am not certain why I am unable to make this connection.  Does anyone see anything wrong with my current rules?

 

Have you tried SNAT instead of MASQUERADE?  If your IP address is relatively stable, it may work out better.  I use:

```

$IPTABLES -A POSTROUTING -t nat -o $WAN_INT -j SNAT --to-source $WAN_IP

$IPTABLES -t nat --policy POSTROUTING ACCEPT

$IPTABLES -t nat --policy PREROUTING ACCEPT

```

I don't have any other -t nat lines (other than inbound bittorrent/WoW forwarding) and I have no problems using the cisco vpn client from an internal machine. 

Also, your default policies on your chains are Input:Accept, Output:Accept, and Forward:Drop.  Remember that Input and Output are packets destined for or originating from the router, and that Forward is for packets that are for and from another host.  If your script errs out while executing, the router itself will be defenseless.  Consider making the policy on Input be Drop, and instead of adding a Drop New/Invalid rule at the end, add an Accept Established.

----------

## dustfinger

To rhavens,

My IP is not that stable, so I think that I will stick with MASQUERADE.  I have not been able to work on this since I last posted.  Tonight I decided that I needed to change a few of my iptable rules.  My goal is to deny everything and then start accepting only the connections that I require.

Here are my new rules:

```

IPTABLES='/sbin/iptables'

#set interface values

EXTIF='eth1'

INTIF='eth0'

#enable ip forwarding in the kernel

/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

#flush rules and delete chains

$IPTABLES -F

$IPTABLES -X

#by default lets drop everything

$IPTABLES -P INPUT DROP

$IPTABLES -P OUTPUT DROP

$IPTABLES -F FORWARD

$IPTABLES -P FORWARD DROP

$IPTABLES -t nat -F

# Allow traffic for existing connections to pass

# Note: requires stateful match support in the kernel

$IPTABLES -A FORWARD -i $EXTIF -p tcp -m state --state ESTABLISHED -j ACCEPT

$IPTABLES -A FORWARD -i $EXTIF -p udp -m state --state RELATED,ESTABLISHED -j ACCEPT

#Accept all input from inside of the LAN

$IPTABLES -A INPUT -i $INTIF -j ACCEPT

$IPTABLES -A OUTPUT -o $INTIF -j ACCEPT

# Allow internal hosts to use TCP and UDP freely

$IPTABLES -A FORWARD -i $INTIF -p tcp -j ACCEPT

$IPTABLES -A FORWARD -i $INTIF -p udp -j ACCEPT

#echo -e "--> enable masquerading to allow LAN internet access"

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

#echo -e "--> forward LAN traffic from $INTIF to Internet interface $EXTIF"

$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -m state --state NEW,ESTABLISHED -j ACCEPT

#echo -e "       - Allowing access to the SSH server"

$IPTABLES -A INPUT --protocol tcp --dport 22 -j ACCEPT

$IPTABLES -A INPUT -i $INTIF --protocol tcp --dport 22 -j ACCEPT

```

This allows me to connect to my server/router via ssh, but I am unable to access the internet from any computer inside of the LAN.  Do you know what is wrong with my MASQUERADE Rule?  Once I get this working then I will 

go back to trying to get a vpn connection established.

Thank you for your help so far rhavens.

dustfinger

----------

## Hu

 *dustfinger wrote:*   

> 
> 
> This allows me to connect to my server/router via ssh, but I am unable to access the internet from any computer inside of the LAN.  Do you know what is wrong with my MASQUERADE Rule?

 

A cursory glance shows nothing obviously incorrect.  Please emerge net-analyzer/tcpdump and run tcpdump -i eth1 -n -p -v to observe outbound traffic, then make a connection from inside the LAN.  The goal is to determine whether traffic is being dropped by the Gentoo system, or whether responses are not returned to the internal hosts.  This could happen if the outbound message has a bad source address, or if the Gentoo system refuses to pass returned traffic.  If you see nothing from the tcpdump, try tcpdump -i eth0 -n -p -v and post that instead, so we can confirm that the internal hosts are definitely sending traffic to the Gentoo system.

----------

## dustfinger

Things are just getting worse.  I restarted my server/router today and I was not able to ssh to it.  I had intended to emerge net-analyzer/tcpdump as Hu requested.  I hooked up a keyboard to my router and tried pinging my desktop, google, and even localhost.  This is what I was seeing.

```
# ping localhost 

PING localhost (127.0.0.1) 56(84) bytes of data. 

ping: sendmsg: Operation not permitted 

ping: sendmsg: Operation not permitted 

ping: sendmsg: Operation not permitted 

--- localhost ping statistics --- 

3 packets transmitted, 0 received, 100% packet loss, time 2011ms
```

So then I decided to change my firewall rules to something simple:

```
IPTABLES='/sbin/iptables' 

#set interface values 

EXTIF='eth1' 

INTIF='eth0' 

#enable ip forwarding in the kernel 

/bin/echo 1 > /proc/sys/net/ipv4/ip_forward 

#flush rules and delete chains 

$IPTABLES -F 

$IPTABLES -X

#echo -e "--> enable masquerading to allow LAN internet access" 

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE 

#echo -e "--> forward LAN traffic from $INTIF to Internet interface $EXTIF" 

$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -m state --state NEW,ESTABLISHED -j ACCEPT 

#ALLOW ACCESS TO SSH SERVER

$IPTABLES -A INPUT --protocol tcp --dport 22 -j ACCEPT

##block out all other Internet access on $EXTIF 

$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,INVALID -j DROP 

$IPTABLES -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP
```

After running the script followed by:

/etc/init.d/iptables save

/etc/init.d/iptables restart

/etc/init.d/net.eth0 restart

/etc/init.d/net.eth1 restart

I had the same problem.

Here is the output of iptables-save -C

```
:INPUT DROP [7:511]

:FORWARD DROP [0:0]

:OUTPUT DROP [205:14484]

-A INPUT -P tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth1 -m state --state INVALID,NEW -j DROP

-A FORWARD -i eth0 -o eth1 -m state --state NEW,ESTABLISHED -j ACCEPT

-A FORWARD -i eth1 -m state --state INVALID,NEW -j DROP

COMMIT

:PREROUTING ACCEPT [1176:287357]

:POSTROUTING ACCEPT [45:8248]

:OUTPUT ACCEPT [1839:153774]

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

-A POSTROUTING -o eth1 -j MASQUERADE

COMMIT
```

Note:I had to type that out since my router currently cannot access the WAN or the LAN.  I don't think I made any typo's, but I may have.

I don't understand why this suddenly happend.  I had been able to use my router and successfully browse the internet from within my LAN, but now I cannot.  Does anyone have any clue as to what is going on here?  Thank you very much to those that have already tried to help me.

Sincerely,

dustfinger.

----------

## Hu

I see a few problems with the reduced script.  The big problem is that it does not set the policy (-P) on any of the chains, so whatever policy was in effect before you ran the script persists afterward.  This means that your OUTPUT chain kept its DROP policy, even though you never added any rules to it.  This is prohibiting all outbound traffic.  This means that not only can you not connect out, but no traffic is allowed in response to inbound connections.  So even if the SYN for your sshd is not dropped, the SYN|ACK that should be sent in response will be dropped by the OUTPUT chain.

You are no longer flushing the nat table, so your POSTROUTING rules are building up every time you run the script.  This is harmless for now, but should be fixed.

I suggest you start with the below script, and add rules to it as needed.  It handles initial cleanup and configures the system as a typical workstation (i.e. no inbound connections).

```
#!/bin/bash

WAN_IFACE='eth1'

LAN_IFACE='eth0'

IPTABLES='/sbin/iptables'

# Silently discard incoming traffic which does not match any rule.

${IPTABLES} -P INPUT DROP

# Silently refuse to forward traffic which does not match any rule.

${IPTABLES} -P FORWARD DROP

${IPTABLES} -P OUTPUT ACCEPT

# Flush the tables.

for table in $(< /proc/net/ip_tables_names ) ; do

   ${IPTABLES} -t "${table}" -F

   ${IPTABLES} -t "${table}" -X

done

# Reset all the chains to a known policy.

if grep -q nat /proc/net/ip_tables_names ; then

   for chain in PREROUTING POSTROUTING OUTPUT; do

      ${IPTABLES} -t nat -P "${chain}" ACCEPT

   done

fi

if grep -q mangle /proc/net/ip_tables_names ; then

   for chain in PREROUTING INPUT FORWARD OUTPUT POSTROUTING; do

      ${IPTABLES} -t mangle -P "${chain}" ACCEPT

   done

fi

# Accept loopback traffic.  Necessary to keep IP-over-localhost working.

# *** Do not remove unless you know _EXACTLY_ what you are doing. ***

${IPTABLES} -A INPUT -i lo -j ACCEPT

# Accept traffic from connections which already existed.  Without any

# rules to permit incoming connections, this rule requires that this

# machine initiate all connections.

# Requires NETFILTER_XT_STATE_MATCH

${IPTABLES} -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# LAN users have unrestricted access to services on this machine.

#${IPTABLES} -A INPUT -i "${LAN_IFACE}" -j ACCEPT

# Log any traffic which gets here, but use a limit modifier so that the

# logs do not fill with every single incoming dropped packet.  This is a

# non-terminating target, so traffic which matches it will continue on.

${IPTABLES} -A INPUT -m limit -j LOG --log-tcp-options --log-ip-options 

# If you are serving as a gateway for other hosts, uncomment the FORWARD

# rules.

#${IPTABLES} -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# LAN users have unrestricted access outbound.

#${IPTABLES} -A FORWARD -i "${LAN_IFACE}" -j ACCEPT

# Traffic sent to the WAN should be masqueraded so that private range IP

# addresses are not sent to the public Internet.

#${IPTABLES} -t nat -A POSTROUTING -o "${WAN_IFACE}" -j MASQUERADE

exit 0

# Optional features (comment out the exit to run them)

# Accept incoming connections to TCP port 12345.  This is needed if you

# want to run a TCP server on port 12345 and have someone connect to it.

${IPTABLES} -A INPUT -p tcp -m tcp --dport 12345 -j ACCEPT

# Accept incoming packets on UDP port 12345.  This is needed if you

# want to run a UDP server on port 12345 and have someone connect to it.

${IPTABLES} -A INPUT -p udp -m udp --dport 12345 -j ACCEPT

```

[Edit: improved the template script again.]

[Edit: fixed copy&paste mistake in rule for permitting new incoming TCP connections.]Last edited by Hu on Mon Nov 05, 2007 2:22 am; edited 2 times in total

----------

## dustfinger

Hu,

Thank you very much for your script.  I ran the script and then ran 

/etc/init.d/iptables save

/etc/init.d/iptables restart.

I was then able to ssh from my desktop to my router.  I was also able to ping google from my router, so that was a huge improvment.  I was not able to browse the internet from my desktop however.  The next thing I did was rebooted both my desktop and my router.  Once booted back up my desktop was unable to obtain an IP address from my router.  My router is running dnsmasq.  I tried running the script again, but my desktop was still unable to obtain an IP address from my router.  My router can still ping google.  One thing that I have not mentioned up to this point is that I am using a DLink router as an accesspoint.  This may be causing me problems.  My network looks something like this.

[WAN]-->[ROUTER running gentoo linux and IPTABLES]-->[DLINK AcessPoint - DHCP and DNS Relay Disabled]-->[Desktop]

My router is a D-Link WBR-1310.  I am not using the WAN Port on the D-Link.  I am wondering if I require xross over cables if I wish to use my router as an access point?  I was hoping to get away with not buying a switch.  Sorry for any spelling mistakes in this post, but I am very over tired right now.

Thank you very much for your help up to this point Hu.

-- EDIT --

Note that my DLink has the IP 192.168.0.1

My gentoo router eth0 has the IP 192.168.1.1

I clicked DHCP release on the DLink router after disabling DHCP so that it could be used as a switch.

-----------

Sincerely,

dustfinger.

----------

## Hu

 *dustfinger wrote:*   

> I was not able to browse the internet from my desktop however.  The next thing I did was rebooted both my desktop and my router.  Once booted back up my desktop was unable to obtain an IP address from my router.  My router is running dnsmasq.  I tried running the script again, but my desktop was still unable to obtain an IP address from my router.  My router can still ping google.  One thing that I have not mentioned up to this point is that I am using a DLink router as an accesspoint.

 

The template script includes some lines to support an IP forwarding setup, but they are commented out by default.  Also, the script does not include any directives that grant internal hosts (the desktop) permission to access services on the router.  Now that I look at it, the template script does not set you up for NAT.  The combination of these limitations means:

1) The router is not passing traffic from your desktop to the Internet.

2) The router is not allowing your desktop to communicate with dnsmasq.

3) Even if the router did pass traffic, the traffic would not be masqueraded, so no responses would be returned.

Point 1 can be addressed by uncommenting the FORWARD rules that I included as a sample.  I have edited the script to include commented rules to address point 2 and point 3.  As a caution, this script is loosely derived from the rules that I use on my routing systems, but does not exactly reflect any configuration that I use in production.  Thus, the script may not be fully functional as written.  However, it should get you close.  Feel free to ask questions if there are any lines that do not make sense, or if there is some action that you cannot achieve with the provided rules.

----------

## dustfinger

Hu,

Thank you very much for your script.  I can now browse the web, connect to a vpn and play online games.  I just have one question for you.  Near the top of the script you set the default output policy to accept:

```
${IPTABLES} -P OUTPUT ACCEPT
```

Then further down you set a rule to accept traffic from connections that already exist:

```
${IPTABLES} -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
```

1. So does that mean that I can initiate any connection I want to the internet from within my LAN, but a machine elsewhere on the internet cannot initiate a connection with my router.  So I can ssh to somebox@someservice.com, but blowjoe@hackerz.net can't ssh to my router for instance.

2. If I wanted to have a default policy

${IPTABLES} -P OUTPUT DROP

then it should be a simple matter of making a white list of what I wish to allow out of my router, along with a white list of what I want to accept inbound to my router.  For example:

```
${IPTABLES} -A OUTPUT -p tcp -m udp --dport 12345 -j ACCEPT

${IPTABLES} -A INPUT -p tcp -m udp --dport 12345 -j ACCEPT
```

Is that a correct assumption?

Thank you again for all of your help.  I really appreciate it.

Sincerely,

dustfinger.

----------

## Hu

For 1: yes, that is correct.  I chose a default policy of ACCEPT for OUTPUT because the script is supposed to be general enough that it can be used on a workstation and will produce a functional packet filter that is secure against outside intrusion.  In my opinion, you only need to restrict OUTPUT if you expect that software running on the router will behave in a manner not consistent with your personal / organizational security policy.  If a system has reached the point that it needs OUTPUT filtering, any rules for OUTPUT would need to be customized to the particular security policy anyway.  :Smile: 

For 2: that is a correct assumption, but note that you copied one of my mistakes.  :Wink:  (which is now fixed).  When adding rules to handle traffic in both directions, be cautious about source port versus destination port, since the source port for an OUTPUT rule is the destination port for an INPUT rule and vice versa.

If you decide to restrict traffic further, feel free to post back if you need guidance on how to achieve what you want.

----------

## dustfinger

To Hu,

The iptables script that you posted has been working well for my needs.  Thank you very much for this, I really appreciate it.  I may create a white list of ports that computers inside my LAN may use to access outside my LAN.  I would do this just to restrict access so that if I ever get a virus it may prevent it from spreading.

Thanks again.

Sincerely,

dustfinger.

----------

