# Problem with network cards

## zeuz

To start with, i'm a novice at linux in general but would like to learn more!  :Smile:  I have used a couple of different distros before and this isn't the first time I run Gentoo. 

I have a machine that I want to run as a server (route the traffic, firewall, apache with php and mysql). The main problem is that I need to install my two network cards (both was found during the installation, but not after), and don't have a clue on how. One of the cards is a Netgear FA310TX REV-D2 and the other one, well...  two cards and would like to use the one thats easiest to install.  :Razz: 

http://img65.exs.cx/my.php?loc=img65&image=DSC00928.jpg

I have a connection that uses pppoe and installed the RP-PPPoE thingy during install. I would like the server to use that connection and split it or something like that heh... (I hope you know what i mean, my english sucks)

Any help/guides/mans is very appriciated! 

Thanks, zeuz

Edit: Did some searching. Rebooted with the livecd and typed lsmod:

```

8139too

mil

tulip

serial

sbp2

usb-storage

hid

usb-ohc1

ehc1-hcd

usbcore

```

I used the Netgear card and the 'MPX' one. I know, as a beginner, I should have used genkernel to configure my kernel, but i wanted to learn as much as i could....  :Sad: Last edited by zeuz on Tue Aug 17, 2004 7:45 pm; edited 1 time in total

----------

## NeddySeagoon

zeuz,

Your two network cards use the 8139too and tulip modules.

In turn, 8139too uses the mii module.

What happens if you 

```
modprobe tulip
```

 and 

```
modprobe 8139too
```

Does ifconfig show you eth0 and eth1 now?

The first loaded module will become eth0.

To make it automatic, add the module names to /etc/modules.autoload./kernel-<ver> for your kernel.

----------

## zeuz

It works now, thanks!  :Smile: 

The next question is, how do i make the machine to route the traffic? I'm really bad at explaining so i'll just show you like this:

```

                                                                        

      ______        __________         _________    

     |      |      |          |       |         |----------------

-----| ADSL |------|  Gentoo  |-------| Switch  |------------------

     |______|      |    box   |       |_________|-----------

                   |__________|                                     

```

This is how i want my network to be... it's just that i don't know how to get the  Gentoo box to route the traffic...

Edit: Gah, I really should search more before posting!

I'm not sure if this is what you need to help me but anyway, my /etc/conf.d/net looks like this:

```
iface_eth0="192.168.1.1 broadcast 192.168.1.255 netmask 255.255.255.0"

iface_eth1="up"

gateway="eth0/192.168.1.1"

```

And i configured adsl-setup like this:

```
Ethernet interface: eth1

User name: xx@xx.com

Activate-on-demand: no

DNS adresses: Supplied by ISP's server

Firewalling: MASQUERADE

```

Then i started it with adsl-start, wich said it connected sucessfully, however I couldn't ping anything, not even some IP....

----------

## srlinuxx

One thing I see is your gateway.  I think you're gonna need to put your isp's gateway there for the server.  The rest of the network you'll use the server's ip.

In addition, I've found that none of mine work if I leave the eth0/ part in the gateway options.  

Also, you're gonna need to look into iptables to accomplish what you want for your network.  

One more thing, I assign my public ip to my eth0 and local ip to my eth1.  Not sure about that "up" option you're using on eth1.  But your main concern is the nic you're connecting to the internet with for now.  I'm pretty sure it's gonna need a public ip to work.

hope some of this helps,

-s

----------

## NeddySeagoon

zeuz,

There are two steps to this.

1. Making the network cards work

2. Getting Masquerading working.

I don't thing you need any ADSL commands because your network is all ethernet.

Step 1. You need a script in /etc/init.d to bring up your eth1. You already have a /etc/init.d/net.eth0 and the new one needs to be identical. Don't copy it things will break when it gets updated. Make a symbolic link like this

```

ln -s  /etc/init.d/net.eth0 /etc/init.d/net.eth1
```

Do your eth0 and eth1 setups in /etc/conf.d/net. Its commented for eth0 bit if you change the eth0 to eth1 (or add in extra eth1 entries) it works for both.

Following the comments in the file, set up your ADSL facing ethernet to use DHCP and your switch facing ethernet to use a static address. You do know which is which don't you?

To try it out do 

```
/etc/init.d/net.eth0 restart

/etc/init.d/net.eth1 restart
```

If you have got it right, you should now be able to surf the net and talk to other PCs connected to the switch. These PCs will not yet be connected to the net.

To make it all happen at bootup do

```
rc-update add net.eth0 default

rc-update add net.eth1 default
```

Step 2 is more difficult. You need iptables in your kernel and if you are doing that you may as well have a firewall to look after your PC and the rest of the network. You probably want to search the forums for that. I use Smoothwall, which wants a whole PC to itself.

----------

## Utoxin

I'd reccomend Shorewall for the Masquerading. It's very nicely put together, and easy to set up from what I recall. (Set it up almost 2 years ago now, so it's been a while...)

----------

## zeuz

Thanks for all the answers!  :Smile: 

NeddySeagoon, I have a symlink, eth1 is pointing to eth0. 

Theese are the net.* i have in /etc/init.d:

```
net.eth0

net.eth1 -> net.eth0

net.lo

net.ppp0

```

I will try the rest now.

Edit: It works! The only thing i did was to re-comment the gateway line in /etc/conf.d/net. Now for the masquerading, i'll look up both Smoothwall and Shorewall. Thanks again for the answers!

Oh, and by the way, I got the up thing from the install documentation

 *Code Listing 14: Examples for /etc/conf.d/net wrote:*   

> (For rp-pppoe)
> 
> iface_eth0="up"
> 
> 

 

Another edit: I've read some in this thread and of what i could see, I had IPtables loaded in the kernel already. Now i'll emerge iptables and smoothwall and see what i can do, or should i just stick to that guide? I'm feeling a bit insecure on the config...

----------

## zeuz

I'm really sorry if the files i posted were too long or something...

I have now emerged iptables and shorewall, read the documentation on shorewall's site and tried to configure it. If i connect with adsl-start It works as it should, however, when I do shorewall start I get host unreachable, so I guess that I have configured shorewall wrong....  :Razz: 

I would really appriciate any help I can get on this. Here are the conf files:

shorewall.conf

```
##############################################################################

#  /etc/shorewall/shorewall.conf V1.4 - Change the following variables to

#  match your setup

#

#  This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]

#

#  This file should be placed in /etc/shorewall

#

#  (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)

##############################################################################

#                              L O G G I N G

##############################################################################

#

# General note about log levels. Log levels are a method of describing

# to syslog (8) the importance of a message and a number of parameters

# in this file have log levels as their value.

#

# Valid levels are:

#

#   7   debug

#   6   info

#   5   notice

#   4   warning

#   3   err

#   2   crit

#   1   alert

#   0   emerg

#

# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall

# log messages are generated by NetFilter and are logged using facility

# 'kern' and the level that you specifify. If you are unsure of the level

# to choose, 6 (info) is a safe bet. You may specify levels by name or by

# number.

#

# If you have build your kernel with ULOG target support, you may also

# specify a log level of ULOG (must be all caps). Rather than log its

# messages to syslogd, Shorewall will direct netfilter to log the messages

# via the ULOG target which will send them to a process called 'ulogd'.

# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be

# configured to log all Shorewall message to their own log file

################################################################################

#

# LOG FILE LOCATION

#

# This variable tells the /sbin/shorewall program where to look for Shorewall

# log messages. If not set or set to an empty string (e.g., LOGFILE="") then

# /var/log/messages is assumed.

#

# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to

#          look for Shorewall messages.It does NOT control the destination for

#          these messages. For information about how to do that, see

#

#              http://www.shorewall.net/shorewall_logging.html

LOGFILE=/var/log/messages

#

# LOG FORMAT

#

# Shell 'printf' Formatting template for the --log-prefix value in log messages

# generated by Shorewall to identify Shorewall log messages. The supplied

# template is expected to accept either two or three arguments; the first is

# the chain name, the second (optional) is the logging rule number within that

# chain and the third is the ACTION specifying the disposition of the packet

# being logged. You must use the %d formatting type for the rule number; if your

# template does not contain %d then the rule number will not be included.

#

# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:

#

#   LOGFORMAT="fp=%s:%d a=%s "

#

# If not specified or specified as empty (LOGFORMAT="") then the value

# "Shorewall:%s:%s:" is assumed.

# 

# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up 

# to but not including the first '%') to find log messages in the 'show log',

# 'status' and 'hits' commands. This part should not be omitted (the 

# LOGFORMAT should not begin with "%") and the leading part should be

# sufficiently unique for /sbin/shorewall to identify Shorewall messages.

LOGFORMAT="Shorewall:%s:%s:"

#

# LOG RATE LIMITING

#

# The next two variables can be used to control the amount of log output

# generated. LOGRATE is expressed as a number followed by an optional

# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum

# rate at which a particular message will occur. LOGBURST determines the

# maximum initial burst size that will be logged. If set empty, the default

# value of 5 will be used.

#

# Example:

#

#   LOGRATE=10/minute

#   LOGBURST=5

#

# If BOTH variables are set empty then logging will not be rate-limited.

#

LOGRATE=

LOGBURST=

#

# LEVEL AT WHICH TO LOG 'UNCLEAN' PACKETS

#

# This variable determines the level at which Mangled/Invalid packets are logged

# under the 'dropunclean' interface option. If you set this variable to an

# empty value (e.g., LOGUNCLEAN= ), Mangled/Invalid packets will be dropped

# silently.

#

# The value of this variable also determines the level at which Mangled/Invalid

# packets are logged under the 'logunclean' interface option. If the variable

# is empty, these packets will still be logged at the 'info' level.

#

# See the comment at the top of this section for a description of log levels

#

LOGUNCLEAN=info

#

# BLACKLIST LOG LEVEL

#

# Set this variable to the syslogd level that you want blacklist packets logged

# (beware of DOS attacks resulting from such logging). If not set, no logging

# of blacklist packets occurs.

#

# See the comment at the top of this section for a description of log levels

#

BLACKLIST_LOGLEVEL=

#

# LOGGING 'New not SYN' rejects

#

# This variable only has an effect when NEWNOTSYN=No (see below).

#

# When a TCP packet that does not have the SYN flag set and the ACK and RST

# flags clear then unless the packet is part of an established connection,

# it will be rejected by the firewall. If you want these rejects logged,

# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.

#

# See the comment at the top of this section for a description of log levels

#

# Example: LOGNEWNOTSYN=debug

LOGNEWNOTSYN=info

#

# MAC List Log Level

#

# Specifies the logging level for connection requests that fail MAC

# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then

# such connection requests will not be logged.

#

# See the comment at the top of this section for a description of log levels

#

MACLIST_LOG_LEVEL=info

#

# TCP FLAGS Log Level

#

# Specifies the logging level for packets that fail TCP Flags

# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then

# such packets will not be logged.

#

# See the comment at the top of this section for a description of log levels

#

TCP_FLAGS_LOG_LEVEL=info

#

# RFC1918 Log Level

#

# Specifies the logging level for packets that fail RFC 1918

# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then

# RFC1918_LOG_LEVEL=info is assumed.

#

# See the comment at the top of this section for a description of log levels

#

RFC1918_LOG_LEVEL=info

################################################################################

#       L O C A T I O N   O F   F I L E S   A N D   D I R E C T O R I E S

################################################################################

#

# PATH - Change this if you want to change the order in which Shorewall

#        searches directories for executable files.

#

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

#

# SHELL

#

# The firewall script is normally interpreted by /bin/sh. If you wish to change

# the shell used to interpret that script, specify the shell here.

SHOREWALL_SHELL=/bin/sh

# SUBSYSTEM LOCK FILE

#

# Set this to the name of the lock file expected by your init scripts. For

# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't

# use lock files, set this to "".

#

SUBSYSLOCK=/var/lock/subsys/shorewall

#

# SHOREWALL TEMPORARY STATE DIRECTORY

#

# This is the directory where the firewall maintains state information while

# it is running

#

STATEDIR=/var/lib/shorewall

#

# KERNEL MODULE DIRECTORY

#

# If your netfilter kernel modules are in a directory other than

# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that

# directory in this variable. Example: MODULESDIR=/etc/modules.

MODULESDIR=

################################################################################

#                       F I R E W A L L   O P T I O N S

################################################################################

# NAME OF THE FIREWALL ZONE

#

# Name of the firewall zone -- if not set or if set to an empty string, "fw"

# is assumed.

#

FW=fw

#

# ENABLE IP FORWARDING

#

# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you

# say "Off" or "off", packet forwarding will be disabled. You would only want

# to disable packet forwarding if you are installing Shorewall on a

# standalone system or if you want all traffic through the Shorewall system

# to be handled by proxies.

#

# If you set this variable to "Keep" or "keep", Shorewall will neither

# enable nor disable packet forwarding.

#

IP_FORWARDING=On

#

# AUTOMATICALLY ADD NAT IP ADDRESSES

#

# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses

# for each NAT external address that you give in /etc/shorewall/nat. If you say

# "No" or "no", you must add these aliases youself.

#

ADD_IP_ALIASES=Yes

#

# AUTOMATICALLY ADD SNAT IP ADDRESSES

#

# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses

# for each SNAT external address that you give in /etc/shorewall/masq. If you say

# "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" unless

# you are sure that you need it -- most people don't!!!

#

ADD_SNAT_ALIASES=No

#

# ENABLE TRAFFIC SHAPING

#

# If you say "Yes" or "yes" here, Traffic Shaping is enabled in the firewall. If

# you say "No" or "no" then traffic shaping is not enabled. If you enable traffic

# shaping you must have iproute[2] installed (the "ip" and "tc" utilities) and

# you must enable packet mangling above.

#

TC_ENABLED=No

#

# Clear Traffic Shapping/Control

#

# If this option is set to 'No' then Shorewall won't clear the current

# traffic control rules during [re]start. This setting is intended

# for use by people that prefer to configure traffic shaping when

# the network interfaces come up rather than when the firewall

# is started. If that is what you want to do, set TC_ENABLED=Yes and

# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That

# way, your traffic shaping rules can still use the 'fwmark'

# classifier based on packet marking defined in /etc/shorewall/tcrules.

#

# If omitted, CLEAR_TC=Yes is assumed.

CLEAR_TC=Yes

#

# Mark Packets in the forward chain

#

# When processing the tcrules file, Shorewall normally marks packets in the

# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set

# this to "Yes". If not specified or if set to the empty value (e.g.,

# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.

#

# Marking packets in the FORWARD chain has the advantage that inbound

# packets destined for Masqueraded/SNATed local hosts have had their destination

# address rewritten so they can be marked based on their destination. When

# packets are marked in the PREROUTING chain, packets destined for

# Masqueraded/SNATed local hosts still have a destination address corresponding

# to the firewall's external interface.

#

# Note: Older kernels do not support marking packets in the FORWARD chain and

#       setting this variable to Yes may cause startup problems.

MARK_IN_FORWARD_CHAIN=No

#

# MSS CLAMPING

#

# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"

# option. This option is most commonly required when your internet

# interface is some variant of PPP (PPTP or PPPoE). Your kernel must

# have CONFIG_IP_NF_TARGET_TCPMSS set.

#

# [From the kernel help:

#

#    This option adds a `TCPMSS' target, which allows you to alter the

#    MSS value of TCP SYN packets, to control the maximum size for that

#    connection (usually limiting it to your outgoing interface's MTU

#    minus 40).

#

#    This is used to overcome criminally braindead ISPs or servers which

#    block ICMP Fragmentation Needed packets.  The symptoms of this

#    problem are that everything works fine from your Linux

#    firewall/router, but machines behind it can never exchange large

#    packets:

#        1) Web browsers connect, then hang with no data received.

#    2) Small mail works fine, but large emails hang.

#    3) ssh works fine, but scp hangs after initial handshaking.

# ]

#

# If left blank, or set to "No" or "no", the option is not enabled.

#

CLAMPMSS=yes

#

# ROUTE FILTERING

#

# Set this variable to "Yes" or "yes" if you want kernel route filtering on all

# interfaces started while Shorewall is started (anti-spoofing measure).

#

# If this variable is not set or is set to the empty value, "No" is assumed.

# Regardless of the setting of ROUTE_FILTER, you can still enable route filtering

# on individual interfaces using the 'routefilter' option in the

# /etc/shorewall/interfaces file.

ROUTE_FILTER=No

#

# NAT BEFORE RULES

#

# Shorewall has traditionally processed static NAT rules before port forwarding

# rules. If you would like to reverse the order, set this variable to "No".

#

# If this variable is not set or is set to the empty value, "Yes" is assumed.

NAT_BEFORE_RULES=Yes

# DNAT IP ADDRESS DETECTION

#

# Normally when Shorewall encounters the following rule:

#

#   DNAT   net   loc:192.168.1.3   tcp   80

#

# it will forward TCP port 80 connections from the net to 192.168.1.3

# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is

# convenient for two reasons:

#

#   a) If the the network interface has a dynamic IP address, the

#      firewall configuration will work even when the address

#      changes.

#

#   b) It saves having to configure the IP address in the rule

#      while still allowing the firewall to be started before the

#      internet interface is brought up.

#

# This default behavior can also have a negative effect. If the

# internet interface has more than one IP address then the above

# rule will forward connection requests on all of these addresses;

# that may not be what is desired.

#

# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply

# only if the original destination address is the primary IP address of

# one of the interfaces associated with the source zone. Note that this

# requires all interfaces to the source zone to be up when the firewall

# is [re]started.

DETECT_DNAT_IPADDRS=No

#

# MUTEX TIMEOUT

#

# The value of this variable determines the number of seconds that programs

# will wait for exclusive access to the Shorewall lock file. After the number

# of seconds corresponding to the value of this variable, programs will assume

# that the last program to hold the lock died without releasing the lock.

#

# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.

#

# An appropriate value for this parameter would be twice the length of time

# that it takes your firewall system to process a "shorewall restart" command.

MUTEX_TIMEOUT=60

#

# NEWNOTSYN

#

# TCP connections are established using the familiar three-way "handshake":

#

#   CLIENT         SERVER

#

#   SYN-------------------->

#            <------------------SYN,ACK

#       ACK-------------------->

#

# The first packet in that exchange (packet with the SYN flag on and the ACK

# and RST flags off) is referred to in Netfilter terminology as a "syn" packet.

# A packet is said to be NEW if it is not part of or related to an already

# established connection.

#

# The NETNOTSYN option determines the handling of non-SYN packets (those with

# SYN off or with ACK or RST on) that are not associated with an already

# established connection.

# 

# If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not

# part of an already established connection, it will be dropped by the

# firewall. The setting of LOGNEWNOTSYN above determines if these packets are

# logged before they are dropped.

#

# If NEWNOTSYN is set to "Yes" or "yes" then such packets will not be

# dropped but will pass through the normal rule/policy processing.

#

# Users with a High-availability setup with two firewall's and one acting

# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may

# also need to select NEWNOTSYN=Yes.

#

# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis 

# using the 'newnotsyn' option in /etc/shorewall/interfaces.

#

# I find that NEWNOTSYN=No tends to result in lots of "stuck"

# connections because any network timeout during TCP session tear down

# results in retries being dropped (Netfilter has removed the

# connection from the conntrack table but the end-points haven't

# completed shutting down the connection).  I therefore have chosen

# NEWNOTSYN=Yes as the default value.

NEWNOTSYN=Yes

#

# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT

#

# Normally, when a "shorewall stop" command is issued or an error occurs during

# the execution of another shorewall command, Shorewall puts the firewall into

# a state where only traffic to/from the hosts listed in

# /etc/shorewall/routestopped is accepted. 

#

# When performing remote administration on a Shorewall firewall, it is

# therefore recommended that the IP address of the computer being used for

# administration be added to the firewall's /etc/shorewall/routestopped file.

#

# Some administrators have a hard time remembering to do this with the result

# that they get to drive across town in the middle of the night to restart

# a remote firewall (or worse, they have to get someone out of bed to drive 

# across town to restart a very remote firewall).

#

# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this setting,

# when the firewall enters the 'stopped' state:

#

# All traffic that is part of or related to established connections is still

# allowed and all OUTPUT traffic is allowed. This is in addition to traffic

# to and from hosts listed in /etc/shorewall/routestopped.

#

# If this variable is not set or it is set to the null value then

# ADMINISABSENTMINDED=No is assumed.

#

ADMINISABSENTMINDED=Yes

#

# BLACKLIST Behavior

#

# Shorewall offers two types of blacklisting:

#

#   - static blacklisting through the /etc/shorewall/blacklist file together

#     with the 'blacklist' interface option.

#   - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.

#

# The following variable determines whether the blacklist is checked for each

# packet or for each new connection.

#

#   BLACKLISTNEWONLY=Yes   Only consult blacklists for new connection

#            requests

#

#   BLACKLISTNEWONLY=No   Consult blacklists for all packets.

#

# If the BLACKLISTNEWONLY option is not set or is set to the empty value then

# BLACKLISTNEWONLY=No is assumed.

#

BLACKLISTNEWONLY=Yes

# MODULE NAME SUFFIX

#

# When loading a module named in /etc/shorewall/modules, Shorewall normally

# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names

# end in ".o", ".ko", ".gz" or "o.gz". If your distribution uses a different

# naming convention then you can specify the suffix (extension) for module 

# names in this variable.

#

# To see what suffix is used by your distribution:

#

#     ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter

#

# All of the file names listed should have the same suffix (extension). Set

# MODULE_SUFFIX to that suffix.

#

# Examples: 

#

#   If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"

#   If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"

#

MODULE_SUFFIX=

################################################################################

#                       P A C K E T   D I S P O S I T I O N

################################################################################

#

# BLACKLIST DISPOSITION

#

# Set this variable to the action that you want to perform on packets from

# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,

# DROP is assumed.

#

BLACKLIST_DISPOSITION=DROP

#

# MAC List Disposition

#

# This variable determines the disposition of connection requests arriving

# on interfaces that have the 'maclist' option and that are from a device

# that is not listed for that interface in /etc/shorewall/maclist. Valid

# values are ACCEPT, DROP and REJECT. If not specified or specified as

# empty (MACLIST_DISPOSITION="") then REJECT is assumed

MACLIST_DISPOSITION=REJECT

#

# TCP FLAGS Disposition

#

# This variable determins the disposition of packets having an invalid

# combination of TCP flags that are received on interfaces having the

# 'tcpflags' option specified in /etc/shorewall/interfaces. If not specified

# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is assumed.

TCP_FLAGS_DISPOSITION=DROP

#LAST LINE -- DO NOT REMOVE

```

zones

```
#

# Shorewall 1.4 /etc/shorewall/zones

#

# This file determines your network zones. Columns are:

#

#   ZONE      Short name of the zone (5 Characters or less in length).

#   DISPLAY      Display name of the zone

#   COMMENTS   Comments about the zone

#

# THE ORDER OF THE ENTRIES IN THIS FILE IS IMPORTANT IF YOU HAVE NESTED OR 

# OVERLAPPING ZONES DEFINED THROUGH /etc/shorewall/hosts.

#

# See http://www.shorewall.net/Documentation.htm#Nested

#

#ZONE   DISPLAY      COMMENTS

net   Net      Internet

loc   Local      Local networks

dmz   DMZ      Demilitarized zone

#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

```

rules

```
#

# Shorewall version 1.4 - Rules File

#

# /etc/shorewall/rules

#

#   Rules in this file govern connection establishment. Requests and

#   responses are automatically allowed using connection tracking.

#

#   In most places where an IP address or subnet is allowed, you

#   can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to

#   indicate that the rule matches all addresses except the address/subnet

#   given. Notice that no white space is permitted between "!" and the

#   address/subnet.

#

# Columns are:

#

#

#   ACTION      ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE,

#         LOG or an <action>.

#

#            ACCEPT   -- allow the connection request

#            DROP     -- ignore the request

#            REJECT   -- disallow the request and return an

#                   icmp-unreachable or an RST packet.

#            DNAT     -- Forward the request to another

#                   system (and optionally another

#                   port).

#            DNAT-    -- Advanced users only.

#                   Like DNAT but only generates the

#                   DNAT iptables rule and not

#                   the companion ACCEPT rule.

#            REDIRECT -- Redirect the request to a local

#                   port on the firewall.

#            REDIRECT-

#                -- Advanced users only.

#                   Like REDIRET but only generates the

#                   REDIRECT iptables rule and not

#                   the companion ACCEPT rule.

#            CONTINUE -- (For experts only). Do not process

#                   any of the following rules for this

#                   (source zone,destination zone). If

#                   The source and/or destination IP

#                   address falls into a zone defined

#                   later in /etc/shorewall/zones, this

#                   connection request will be passed

#                   to the rules defined for that

#                   (those) zone(s).

#            LOG      -- Simply log the packet and continue.

#            QUEUE    -- Queue the packet to a user-space

#                   application such as p2pwall.

#            <action> -- The name of an action defined in

#                   /etc/shorewall/actions.

#

#         You may rate-limit the rule by optionally

#         following ACCEPT, DNAT[-], REDIRECT[-] or LOG with

# 

#            < <rate>/<interval>[:<burst>] >

#

#         where <rate> is the number of connections per 

#         <interval> ("sec" or "min") and <burst> is the

#         largest burst permitted. If no <burst> is given,

#         a value of 5 is assumed. There may be no

#         no whitespace embedded in the specification.

#

#            Example: ACCEPT<10/sec:20>

#

#         The ACTION (and rate limit) may optionally be followed

#         by ":" and a syslog log level (e.g, REJECT:info or

#         DNAT<4/sec:8>:debugging). This causes the packet to be

#         logged at the specified level.

#

#         NOTE: For those of you who prefer to place the

#         rate limit in a separate column, see the RATE LIMIT

#         column below. If you specify a value in that column,

#         you must not include a rate limit in the ACTION column

#

#         You may also specify ULOG (must be in upper case) as a

#         log level.This will log to the ULOG target for routing

#         to a separate log through use of ulogd

#         (http://www.gnumonks.org/projects/ulogd).

#

#   SOURCE      Source hosts to which the rule applies. May be a zone

#                       defined in /etc/shorewall/zones, $FW to indicate the

#         firewall itself, or "all" If the ACTION is DNAT or

#         REDIRECT, sub-zones of the specified zone may be

#         excluded from the rule by following the zone name with

#         "!' and a comma-separated list of sub-zone names.

#

#         Except when "all" is specified, clients may be further

#         restricted to a list of subnets and/or hosts by

#         appending ":" and a comma-separated list of subnets

#         and/or hosts. Hosts may be specified by IP or MAC

#         address; mac addresses must begin with "~" and must use

#         "-" as a separator.

#

#         dmz:192.168.2.2      Host 192.168.2.2 in the DMZ

#

#         net:155.186.235.0/24   Subnet 155.186.235.0/24 on the

#                  Internet

#

#         loc:192.168.1.1,192.168.1.2

#                  Hosts 192.168.1.1 and

#                  192.168.1.2 in the local zone.

#         loc:~00-A0-C9-15-39-78  Host in the local zone with

#                                               MAC address 00:A0:C9:15:39:78.

#

#         Alternatively, clients may be specified by interface

#         by appending ":" to the zone name followed by the

#         interface name. For example, loc:eth1 specifies a

#         client that communicates with the firewall system

#         through eth1. This may be optionally followed by

#         another colon (":") and an IP/MAC/subnet address

#         as described above (e.g., loc:eth1:192.168.1.5).

#

#   DEST      Location of Server. May be a zone defined in

#         /etc/shorewall/zones, $FW to indicate the firewall

#         itself or "all"

#

#         Except when "all" is specified, the server may be

#         further restricted to a particular subnet, host or

#         interface by appending ":" and the subnet, host or

#         interface. See above.

#

#            Restrictions:

#

#            1. MAC addresses are not allowed.

#            2. In DNAT rules, only IP addresses are

#               allowed; no FQDNs or subnet addresses

#               are permitted.

#            3. You may not specify both an interface and

#               an address.

#

#         Unlike in the SOURCE column, you may specify a range of

#         up to 256 IP addresses using the syntax

#         <first ip>-<last ip>. When the ACTION is DNAT or DNAT-,

#         the connections will be assigned to addresses in the

#         range in a round-robin fashion.

#

#         The port that the server is listening on may be

#         included and separated from the server's IP address by

#         ":". If omitted, the firewall will not modifiy the

#         destination port. A destination port may only be

#         included if the ACTION is DNAT or REDIRECT.

#

#         Example: loc:192.168.1.3:3128 specifies a local

#         server at IP address 192.168.1.3 and listening on port

#         3128. The port number MUST be specified as an integer

#         and not as a name from /etc/services.

#

#         if the ACTION is REDIRECT, this column needs only to

#         contain the port number on the firewall that the

#         request should be redirected to.

#

#   PROTO      Protocol - Must be "tcp", "udp", "icmp", a number, or

#         "all".

#

#   DEST PORT(S)    Destination Ports. A comma-separated list of Port

#         names (from /etc/services), port numbers or port

#         ranges; if the protocol is "icmp", this column is

#         interpreted as the destination icmp-type(s).

#

#         A port range is expressed as <low port>:<high port>.

#

#         This column is ignored if PROTOCOL = all but must be

#         entered if any of the following ields are supplied.

#         In that case, it is suggested that this field contain

#          "-"

#

#         If your kernel contains multi-port match support, then

#         only a single Netfilter rule will be generated if in

#         this list and the CLIENT PORT(S) list below:

#         1. There are 15 or less ports listed.

#         2. No port ranges are included.

#         Otherwise, a separate rule will be generated for each

#         port.

#

#   CLIENT PORT(S)   (Optional) Port(s) used by the client. If omitted,

#         any source port is acceptable. Specified as a comma-

#         separated list of port names, port numbers or port

#         ranges.

#

#         If you don't want to restrict client ports but need to

#         specify an ADDRESS in the next column, then place "-"

#         in this column.

#

#         If your kernel contains multi-port match support, then

#         only a single Netfilter rule will be generated if in

#         this list and the DEST PORT(S) list above:

#         1. There are 15 or less ports listed.

#         2. No port ranges are included.

#         Otherwise, a separate rule will be generated for each

#         port.

#

#   ORIGINAL DEST   (0ptional -- only allowed if ACTION is DNAT[-] or

#                       REDIRECT[-]) If included and different from the IP

#         address given in the SERVER column, this is an address

#         on some interface on the firewall and connections to

#         that address will be forwarded to the IP and port

#         specified in the DEST column.

#

#         A comma-separated list of addresses may also be used. 

#         This is usually most useful with the REDIRECT target 

#         where you want to redirect traffic destined for

#         particular set of hosts.

#

#         Finally, if the list of addresses begins with "!" then

#         the rule will be followed only if the original 

#         destination address in the connection request does not

#         match any of the addresses listed.

#

#         The address (list) may optionally be followed by

#         a colon (":") and a second IP address. This causes

#         Shorewall to use the second IP address as the source

#         address in forwarded packets. See the Shorewall

#         documentation for restrictions concerning this feature.

#         If no source IP address is given, the original source

#         address is not altered.

#

#   RATE LIMIT   You may rate-limit the rule by placing a value in 

#         this colume:

# 

#            <rate>/<interval>[:<burst>]

#

#         where <rate> is the number of connections per 

#         <interval> ("sec" or "min") and <burst> is the

#         largest burst permitted. If no <burst> is given,

#         a value of 5 is assumed. There may be no

#         no whitespace embedded in the specification.

#

#            Example: 10/sec:20

#

#         If you place a rate limit in this column, you may not

#         place a similar limit in the ACTION column.

#

#   USER SET   This column may only be non-empty if the SOURCE is

#         the firewall itself and the ACTION is ACCEPT, DROP or

#         REJECT.

#         

#         The column may contain a user set name defined in the

#         /etc/shorewall/usersets file or it may contain:

#

#            [<user name or number>]:[<group name or number>]

#

#         When this column is non-empty, the rule applies only

#         if the program generating the output is running under

#         the effective <user>(s) and/or <group>(s) specified.

#         When a user set name is given, a log level may not be

#         present in the ACTION column; logging for such rules is

#         controlled by the user set's entry in 

#         /etc/shorewall/usersets.

#

#   Example: Accept SMTP requests from the DMZ to the internet

#

#   #ACTION SOURCE   DEST PROTO   DEST    SOURCE   ORIGINAL

#   #                               PORT    PORT(S) DEST

#   ACCEPT   dmz   net     tcp   smtp

#

#   Example: Forward all ssh and http connection requests from the internet

#       to local system 192.168.1.3

#

#   #ACTION SOURCE   DEST            PROTO   DEST    SOURCE   ORIGINAL

#   #                                       PORT    PORT(S) DEST

#   DNAT   net   loc:192.168.1.3 tcp   ssh,http

#

#   Example: Forward all http connection requests from the internet

#       to local system 192.168.1.3 with a limit of 3 per second and

#       a maximum burst of 10

#

#   #ACTION    SOURCE   DEST            PROTO   DEST    SOURCE   ORIGINAL

#   #                                          PORT    PORT(S) DEST

#   DNAT<3/sec:10>   net   loc:192.168.1.3 tcp   http

#

#   Example: Redirect all locally-originating www connection requests to

#       port 3128 on the firewall (Squid running on the firewall

#       system) except when the destination address is 192.168.2.2

#

#   #ACTION  SOURCE   DEST      PROTO   DEST    SOURCE   ORIGINAL

#   #                               PORT    PORT(S) DEST

#   REDIRECT loc   3128      tcp   www    -   !192.168.2.2

#

#   Example: All http requests from the internet to address

#                130.252.100.69 are to be forwarded to 192.168.1.3

#

#   #ACTION  SOURCE   DEST         PROTO   DEST    SOURCE   ORIGINAL

#   #                                  PORT    PORT(S) DEST

#   DNAT      net   loc:192.168.1.3 tcp     80      -       130.252.100.69

#

#       Example: You want to accept SSH connections to your firewall only 

#       from internet IP addresses 130.252.100.69 and 130.252.100.70

#

#   #ACTION  SOURCE   DEST         PROTO   DEST    SOURCE   ORIGINAL

#   #                                  PORT    PORT(S) DEST

#   ACCEPT    net:130.252.100.69,130.252.100.70 fw \

#               tcp   22

####################################################################################################

#ACTION  SOURCE      DEST         PROTO   DEST    SOURCE      ORIGINAL   RATE      USER

#                                     PORT    PORT(S)    DEST      LIMIT

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

```

----------

