Networking-Blog

My WordPress Blog

Linux Iptables Web-Redirect 8080

PREROUTING CHAIN :

sudo iptables -t nat -I PREROUTING 20 -s 85.234.70.18/32 -p tcp -m tcp –dport 80 -j
REDIRECT –to-ports 8080

IF DATA IS FOR FIREWALL : It will hit the INPUT chain.

INPUT CHAIN :

sudo iptables -I INPUT -p tcp -m tcp –dport 81 -j Content_Filter
sudo iptables -I INPUT -p tcp -m tcp –dport 8080 -j Content_Filter

CONTENT_FILTER CHAIN :

sudo iptables -I Content_Filter 3 -s 85.234.70.18/32 -j ACCEPT

FORWARD CHAIN :

sudo iptables -I FORWARD 17 -s 85.234.70.18/32 -j ACCEPT

Remote Site incoming traffic to be naTTed using  eth2 public ip address :

POSTROUTING CHAIN :

sudo iptables -t nat -I POSTROUTING 6 -o eth2 -s 85.234.70.18/32 -j SNAT –to 85.234.65.46

MessageLabs Email Filtering

List of MessageLabs Public Ip Address Ranges :

Subnet IP Subnet Mask
216.82.240.0 255.255.240.0     /20 216.82.240.0 – 216.82.255.255
67.219.240.0 255.255.240.0     /20 67.219.240.0 – 67.219.255.255
85.158.136.0 255.255.248.0     /21 85.158.136.0 – 85.158.143.255
95.131.104.0 255.255.248.0     /21 95.131.104.0 – 95.131.111.255
46.226.48.0 255.255.248.0      /21 46.226.48.0 – 46.226.55.255
117.120.16.0 255.255.248.0     /21 117.120.16.0 – 117.120.23.255
193.109.254.0 255.255.254.0  /23 193.109.254.0 – 193.109.255.255
194.106.220.0 255.255.254.0  /23 194.106.220.0 – 194.106.221.255
195.245.230.0 255.255.254.0  /23 195.245.230.0 – 195.245.231.255

Linux Iptables Firewall Rules :

Create a Chain :

sudo iptables -t nat -N messagelabs

!

Create a PREROUTING rule to forward port 25 to “messagelabs” chain :

sudo iptables -t nat -I PREROUTING 11 -d 195.99.136.99/32 -p tcp -m tcp –dport 25 -j messagelabs

!
Create rules in messagelabs chain to DNAT port 25 Traffic to internal host :
sudo iptables -t nat -I messagelabs 1 -s 216.82.240.0/20 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 67.219.240.0/20 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 85.158.136.0/21 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 95.131.104.0/21 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 46.226.48.0/21 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 117.120.16.0/21 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 193.109.254.0/23 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 194.106.220.0/23 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
sudo iptables -t nat -I messagelabs 1 -s 195.245.230.0/23 -p tcp -m tcp –dport 25 -j DNAT –to 172.31.10.12:25
!
!
Next Chain down the line that will be accessed is the FORWARD chain :
This will FORWARD traffic to the POSTROUTING chain where it will locally break-out to the internet.
!
sudo iptables -I FORWARD 1 -d 172.31.10.12/32 -p tcp -m tcp –dport 25 -j ACCEPT
!
!
Final chain to be accessed is the POSTROUTING chain,
where traffic is SNATed to a particular interface
:
!
sudo iptables -t nat -I POSTROUTING 5 -o eth1 -s 172.31.10.12 -j SNAT –to 195.99.136.99

Linux Iptables DNS Chain

Allow internet access to DNS Server public address. Lets go ahead and create the rules needed.

Lets Create the nat dns Chain :

sudo iptables -N dns
!
Allow local access to NaT traffic out to internet DNS Servers.
Allow POSTROUTING Chain, DNS Traffic to jump to Chain dns
!
sudo iptables -I POSTROUTING 19 -i eth0 -s 10.10.0.0/16 -p udp -m udp –dport 53 –j dns
!

Allow local access to Public DNS Server to ACCEPT :
sudo iptables –I dns -i eth1 -d 80.84.86.80 -p udp -m udp –dport 53 –j ACCEPT
sudo iptables -I dns -i eth1 -d 80.84.86.81 -p udp -m udp –dport 53 -j ACCEPT

Linux Iptables Content Filter Web Rule

Create New -t nat Chain :
!
sudo iptables -t nat -N ssl_https
sudo iptables -t nat -N unfiltered_web
sudo iptables -t nat -N filtered_web
**********************************************************************

Firstly we need to allow HTTPS Traffic to the Internet :
Allow Subnet HTTPS Traffic to jump to Chain ssl_https :

sudo iptables -t nat -I PREROUTING 1 -s 10.10.0.0/16 -p tcp -m tcp –dport 443 -j ssl_https
Allow HTTPS Traffic to Accept :

sudo iptables -t nat -I ssl_https 1 -p tcp -m tcp –dport 443 -j ACCEPT
!

Secondly need to Create a FORWARD Chain Rule in order to allow HTTPS Traffic as this is the
second chain down the line that gets Inspected
:
!

Lets create a new Chain :

sudo iptables -N ssl-https
!
Allow HTTPS Traffic to jump to Chain ssl-https
sudo iptables -I FORWARD 1 -p tcp -m tcp –dport 443 -jssl-https :
!

Allow HTTPS Traffic to ACCEPT :
sudo iptables -I
ssl-https 1 -p tcp -m tcp –dport 443 -j ACCEPT
!

Thirdly Allow  HTTPS Traffic to SNAT to Public Assigned Address for local break-out ” 88.834.85.88″ :

sudo iptables -t nat -I internet_web 1 -o eth0 -p tcp -m tcp –dport 443  -j SNAT –to 88.834.85.88

or

sudo iptables -t nat -I POSTROUTING 1 -o eth0 -s 10.200.0.5/32 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 1 -o eth0 -s 192.0.0.0/16 -j MASQUERADE

Action that should take place is to ‘masquerade‘ packets, i.e. replacing the sender’s address by the
router’s address for local break-out to the internet.

B00m… Complete….
**********************************************************************

Another Scenerio : Allow HTTP Traffic to be Filtered by Content Filter also allow certain ip addresses
to be bypass Content Filter, where this additional rule will be configured under unfiltered_web Chain.
!

Create Filtered and unfiltered nat Chains in order for PREROUTING Chain tojump to in order to
consolidate rules more profoundly
:
!
Allow Subnet HTTP Traffic to jump to Chain unfiltered_web :
sudo iptables -t nat -I PREROUTING 2 -s 10.10.0.0/16 -p tcp -m tcp –dport 80 -j unfiltered_web
!
Allow HTTP Traffic to bypass Content Filter :
sudo iptables -t nat -I unfiltered_web 1 -d “public-ip” -p tcp -m tcp –dport 80 -j ACCEPT
!
Allow Filtered HTTP Traffic to jump to Chain filtered_web :
sudo iptables -t nat -I unfiltered_web 2 -p tcp -m tcp –dport 80 -j filtered_web
!

This is where HTTPS Traffic gets Redirect to Content Filter.
Allow HTTP Traffic to Redirect to Port 8080 (Content Filter Listening Port)

sudo iptables -t nat -I filtered_web 1 -i eth0 -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 8080
or
sudo iptables -t nat -I filtered_web 1 -i eth0 -p tcp -m tcp –dport 80 -j DNAT –to-destination 10.200.0.5:800
!


Now we need to have HTTP Traffic NaTTeD out for Local break out to the Internet in order for the
unfiltered_web chain
:
This is Configured in the POSTROUTING Chain.
!
Lets Create a new Chain Internet_web in order to organise chains more profoundly.

sudo iptables -t nat -N internet_web
!
Allow HTTP & HTTPS Traffic NaTTeD to jump to Chain previously created internet_web
sudo iptables -t nat -I POSTROUTING 2 -o eth0 -p tcp -m tcp –dport 80 -j internet_web
!
Allow HTTP & HTTPS Traffic to SNAT to Public Assigned Address for local break-out ” 88.834.85.88″ :
sudo iptables -t nat -I internet_web 2 -o eth0 -p tcp -m tcp –dport 80  -j SNAT –to 88.8234.85.88
B00m…

Linux IPTables Add Chain

sudo iptables -N home_users
!
sudo iptables -I home_users -d 10.20.190.0/23 -j ACCEPT
sudo iptables -I home_users -d 10.20.192.0/21 -j ACCEPT

sudo iptables -I FORWARD 64 -s 10.20.253.24/29 -d 10.20.0.0/16 -j home_users

This will cover networks destined within the home_users chain :

/21 = 10.20.190.0 – 10.20.191.255
/23 = 10.20.192.0 – 10.20.199.255

To add the chain home_users :
sudo iptables -N home_users
!
To delete the chain home_users :
sudo iptables -X home_users
!
!

“iptables –table nat –flush”

This will remove all chains from your current running netfilter table (firewall rules)…
you just dropped your pants.

!

“iptables –delete-chain”

This will remove all chains from your current running nat table
!

“iptables –table nat –delete-chain”

No need to do this after a flush!  There are no chains in your current running nat table
because you already flushed it.

!

“iptables –table nat –append POSTROUTING –out-interface eth0 -j MASQUERADE”

This will enable nat in your current running nat table until we get down to the restart below.
!

“echo 1 > /proc/sys/net/ipv4/ip_forward”

This will turn on routing.  To bad next time you boot, it will not be enabled.  Use sysct
!

“service iptables restart”
I love this one.  This command will un-do every “iptable” command above.
Now NAT is no longer running. When the iptables service is restarted, it reads
the saved config and anything was in “current running” is gone.
Instead, use iptables-save
.
!
!
The cleanest method of accomplishing this is to create a new chain which does both
the LOG and DROP for you
.

The following IPTABLES rules will create a LOGDROP chain.

Create the LOGDROP chain
iptables -N LOGDROP > /dev/null 2> /dev/null
iptables -F LOGDROP
iptables -A LOGDROP -j LOG –log-prefix “LOGDROP ”
iptables -A LOGDROP -j DROP

1. The first rule in this set creates the new chain.
The output is sent to /dev/null because if you attempt to run this twice on the
same system, you will get an error saying the chain already exists. It’s up to you if you
want to see that message or not.

2. The second rule flushes the contents of the chain, again, so that if you run it twice on the
same system you don’t have duplicate rules in the chain
.

3. The third rule LOGS the traffic with the added “LOGDROP” prefix and the fourth rule
DROP’s the traffic.

“iptables -A INPUT -p tcp –dport 80 -j LOGDROP”
Log and drop all connections to the HTTP port

As you can see, you now simply use the LOGDROP target in order to log and drop any
traffic you want
.You must ensure that you define the LOGDROP target BEFORE you
attempt to use it in a rule
.

Linux Danaguardian Proxy Iptables

Push traffic to Proxy Filter Dansguardian :

PREROUTING Chain :
this will have all traffic destined for port tcp 80 to jump to unfiltered_web chain.

iptables -I PREROUTING -p tcp -m tcp –dport 80 -j unfiltered_web

unfiltered_web chain entry :

iptables -I unfiltered_web -d 83.166.168.43 -p tcp -m tcp –dport 80 -j ACCEPT
iptables -I unfiltered_web -d 212.41.178.44 -p tcp -m tcp –dport 80 -j ACCEPT
iptables -I unfiltered_web -s 172.16.2.49 -p tcp -m tcp –dport 80 -j ACCEPT

Once unfiltered traffic to bypass proxy dansguardian using unfiltered_web chain as above,
the last entry is to poing it back to filtered_web chain,  in order to have other ip addresses or
subnets HTTP traffic filtered using the filtered_web chain .
to have proxy filter HTTP traffic :

This will cause unfiltered_web to jump to filtered_web chain

iptables -I unfiltered_web-j filtered_web

filtered_web chain entry :

This will cause filtered_web chain to push all HTTP traffic to dansguardian proxy server
on 172.16.150.248 on tcp port 8080.

Tcp 80 will be DNAT to tcp port 8080 to destination address of 172.16.150.248.

iptables -I filtered_web -p tcp -m tcp –dport 80 -j DNAT –to-destination 172.16.150.248:8080

In Brief Summary :

iptables -I PREROUTING -p tcp -m tcp –dport 80 -j unfiltered_web
!
iptables -I unfiltered_web
-j filtered_web
(Make changes in this chain for unfiltered traffic as seen above)
!
iptables -I 
filtered_web -p tcp -m tcp –dport 80 -j DNAT –to-destination 172.16.150.248:8080

Additional Notes :

For HTTP external sites that need to bypass proxy due to HTTPS authentication,
These are the changes that need to be made within iptables :

sudo iptables -t nat -I PREROUTING -s 172.16.0.0/16 -d 83.166.168.51/32 -p tcp -m tcp –dport 443 -j ACCEPT
!

sudo iptables -I FORWARD 18 -s 172.16.0.0/16 -d 83.166.168.51/32 -p tcp -m tcp –dport 443 -j ACCEPT

Quick Summary :

sudo iptables -t nat -I PREROUTING 1 -i eth 0 -s 10.10.0.0/16 -p tcp -m tcp –dport 80 -j unfiltered_web
!
sudo iptables -t nat -I unfiltered_web 1 -i eth0 -s 10.10.34.12/32 -j ACCEPT
sudo iptables -t nat -I unfiltered_web 2 -i eth0 -j filtered_web
!
sudo iptables -t nat -I filtered_web 1 -i eth0 -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 8080

Linux Iptables Port Forward

PREROUTING rule so that traffic coming to a particular public IP port is routed to your internal machine.

DNAT the traffic to your internal machine
Internal machine FILTER rules should not block the incoming traffic .

sudo iptables -t nat -I PREROUTING 1 -d 85.234.65.57 -p tcp -m multiport –dports 80,443
-j DNAT –to 10.20.0.13
!
sudo iptables -I FORWARD 33 -d 10.20.0.13 -p tcp -m multiport –dports 80,443 -j ACCEPT
sudo iptables -I FORWARD -m state –state RELATED,ESTABLISHED -j ACCEPT

RELATED,ESTABLISHED will take care of any return packets.
Accept packets to webservers (http and https) in the FORWARD chain.

Create additional chain within FORWARD chain to jump to another chain.
This configuration is organizing chain to required service or naming ACL.

Create a chain :
sudo iptables -N ahdb_network
Create FORWARD rule to jump to ahdb_network :
sudo iptables -I FORWARD 1 -s 128.0.0.0/8 -d 128.0.0.0/8 -j ahdb_network
sudo iptables -I FORWARD 1 -s 128.0.0.0/8 -d 10.0.0.0/16 -j ahdb_network
sudo iptables -I FORWARD 1 -s 10.0.0.0/16 -d 128.0.0.0/8 -j ahdb_network
ahdb_network Chain :
sudo iptables -I ahdb_network 1 -s 128.0.0.0/8 -d 128.0.0.0/8 -j ACCEPT
sudo iptables -I ahdb_network 2 -s 128.10.0.0/16 -d 10.0.0.0/16 -j ACCEPT
sudo iptables -I ahdb_network 3 -s 128.20.0.0/16 -d 10.0.0.0/16 -j ACCEPT
sudo iptables -I ahdb_network 4 -s 10.0.0.0/16 -d 128.10.0.0/16 -j ACCEPT
sudo iptables -I ahdb_network 5 -s 10.0.0.0/16 -d 128.20.0.0/16 -j ACCEPT
Intersite VPN Connectivity :

iptables -I FORWARD 63 -o eth0 -s 10.20.0.0/16 -d 10.20.21.1/32 -p tcp -m tcp
--dport 3389 -j Priory_Vets_Group
!
iptables -I FORWARD 64 -o eth0 -s 10.20.21.1/32 -d 10.20.0.0/16 -p tcp -m tcp
--sport 3389 -j Priory_Vets_Group
!
iptables -I Priory_Vets_Group 1 -d 10.20.0.0/16 -j ACCEPT
iptables -I Priory_Vets_Group 2 -d 10.20.21.1/32 -j ACCEPT

Linux Iptables Established Traffic

# Example /etc/sysconfig/iptables configuration file
#
# Turn on traffic filtering
*filter

# Set default policies
:INPUT DROP [1:44]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [27040:2493902]

# Accept all traffic from the loopback interface.
-A INPUT -i lo -j ACCEPT

# Accept legitimate responses to traffic we generate.
iptables -I INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -I INPUT 11 -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -I OUTPUT 11 -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -I public_in 11 -m state –state RELATED,ESTABLISHED -j ACCEPT

!
# Forward all legitimate responses to forwarded traffic.
# iptables -I FORWARD -m state –state RELATED,ESTABLISHED -j ACCEPT
!
# Allow inbound DNS responses from our ISPs DNS servers.
# Change these to the IP addresses of your ISPs DNS servers.
iptables -I INPUT -s 0.0.0.0 -i eth0 -p udp -m state –state ESTABLISHED -m udp –sport 53 -j ACCEPT
iptables -I INPUT -s 0.0.0.0 -i eth0 -p tcp -m tcp –sport 53 -m state –state ESTABLISHED -j ACCEPT
iptables -I INPUT -s 1.1.1.1 -i eth0 -p udp -m state –state ESTABLISHED -m udp –sport 53 -j ACCEPT
iptables -I INPUT -s 1.1.1.1 -i eth0 -p tcp -m tcp –sport 53 -m state –state ESTABLISHED -j ACCEPT

!
# Allow inbound DHCP from the Local wireless network (note: not from 10.0.0/8)
# Change this to the network allocated for your use.
iptables -I INPUT -s 10.1.2.0/255.255.255.0 -i wlan0 -p udp –dport 67:68 –sport 67:68 -j ACCEPT
!
# Allow inbound FTP from the entire wireless network.
iptables -I INPUT -d 10.1.2.0/255.255.255.0 -p tcp -m tcp –dport 21 -j ACCEPT
iptables -I INPUT -d 10.1.2.1 -p udp -m state –state NEW,ESTABLISHED -m udp –dport 21 -j ACCEPT

!
# Allow all related traffic to/from non-privileged ports.
iptables -I INPUT -p tcp -m tcp –sport 1024:65535 –dport 1024:65535 -m state –state RELATED,ESTABLISHED -j ACCEPT

Linux Iptables Active / Passive FTP

Active FTP

From the server-side firewall’s standpoint, to support active mode FTP the following
communication channels need to be opened
:

* FTP server’s port 21 from anywhere (Client initiates connection)
* FTP server’s port 21 to ports > 1024 (Server responds to client’s control port)
* FTP server’s port 20 to ports > 1024 (Server initiates data connection to client’s data port)
* FTP server’s port 20 from ports > 1024 (Client sends ACKs to server’s data port)

Active FTP

The sequence of events for active FTP is:

1. Your client connects to the FTP server by establishing an FTP control connection to
port 21 of the server
. Your commands such as ‘ls’ and ‘get’ are sent over this connection.

2. Whenever the client requests data over the control connection, the server initiates data
transfer connections back to the client. The source port of these data transfer connections is always
port 20 on the server, and the destination port is a high port (greater than 1024) on the client
.

3. Thus the ls listing that you asked for comes back over the port 20 to high port connection,
not the port 21 control connection
.

FTP active mode therefore transfers data in a counter intuitive way to the TCP standard,
as it selects port 20 as it’s source port (not a random high port that’s greater than 1024) and
connects back to the client on a random high port that has been pre-negotiated on the
port 21 control connection.

Active FTP may fail in cases where the client is protected from the Internet via many to one
NAT (masquerading)
. This is because the firewall will not know which of the many servers behind it
should receive the return connection
.

Passive FTP

Passive FTP works differently:

1. Your client connects to the FTP server by establishing an FTP control connection to port 21
of the server. Your commands such as ls and get are sent over that connection
.

2. Whenever the client requests data over the control connection, the client initiates the data transfer
connections to the server. The source port of these data transfer connections is always a high port on
the client with a destination port of a high port on the server
.

Passive FTP should be viewed as the server never making an active attempt to connect to the client
for
FTP data transfers. Because client always initiates the required connections,

Passive FTP works better for clients protected by a firewall.

The main problem with active mode FTP actually falls on the client side.
The
FTP client doesn’t make the actual connection to the data port of the server–it
simply tells the server what port it is listening on and the server connects back to the
specified port on the client
.

From the client side firewall this appears to be an outside system initiating a connection
to an internal client–something that is usually blocked
.

Linux Iptables Commands :

iptables -A INPUT -p tcp –dport ftp -j ACCEPT
iptables -A INPUT -p tcp –dport ftp-data -j ACCEPT
iptables
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport ftp -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport ftp-data -j ACCEPT

or

/sbin/modprobe ip_conntrack_ftp
iptables -A INPUT -p TCP -i eth0 –dport 21 -m state –state NEW -j ACCEPT
iptables
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables
-A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

Summary

The following chart should help admins remember how each FTP mode works:

Active FTP :
command : client >1024 -> server 21
data    : client >1024 <- server 20

Passive FTP :
command : client >1024 -> server 21
data    : client >1024 -> server >1024

As Windows defaults to active FTP, and Linux defaults to passive,
you'll  probably have to accommodate both forms when deciding upon
a security  policy for your FTP server.

Client Protected by a Firewall Problem.

Typically firewalls don't allow incoming connection at all, which
frequently blocks active FTP from functioning. Active FTP connections
appears to work when the client initiates an outbound connection to the
server on port 21.

The connection then appears to hang,, how ever, as soon as you use the
ls,dir, or get commands. The reason is that the firewall is blocking the
return traffic connection from the server to the client (from port 20
on the server to a high port on the client).

If a firewall allows all outbound connections to the internet,
then passive FTP clients behind a firewall will usually work correctly as
the clients initiate all the FTP connections.

Packet Processing In iptables

Figure 14-1 Iptables Packet Flow Diagram

Iptables.gif

You need to specify the table and the chain for each firewall rule you create.
There is an exception: Most rules are related to filtering, so iptables assumes that any
chain that’s defined without an associated table will be a part of the filter table.
The filter table is therefore the default.

To help make this clearer, take a look at the way packets are handled by iptables.

In Figure 14.1 a TCP packet from the Internet arrives at the firewall’s interface
on Network A to create a data connection.

The packet is first examined by your rules in the mangle table’s PREROUTING chain,
if any. It is then inspected by the rules in the nat table’s PREROUTING chain to see
whether the packet requires DNAT.

It is then routed.

If the packet is destined for a protected network, then it is filtered by the rules in the
FORWARD chain of the filter table and, if necessary, the packet undergoes SNAT in the
POSTROUTING chain before arriving at Network B. When the destination server
decides to reply, the packet undergoes the same sequence of steps.

Both the FORWARD and POSTROUTING chains may be configured to implement
quality of service (QoS) features. in their mangle tables, but this is not usually done
in SOHO environments.

If the packet is destined for the firewall itself, then it passes through the
mangle table
of the INPUT chain, if configured, before being filtered by the rules in
the INPUT chain of the filter table before. If it successfully passes these tests then it is
processed by the intended application on the firewall.

At some point, the firewall needs to reply. This reply is routed and inspected by the
rules in the OUTPUT chain of the mangle table, if any. Next, the rules in the OUTPUT
chain of the nat table determine whether DNAT is required and the rules in the OUTPUT
chain of the filter table are then inspected to help restrict unauthorized packets.
Finally, before the packet is sent back to the Internet, SNAT and QoS mangling is done
by the POSTROUTING chain

Table 14-1 Processing For Packets Routed By The Firewall

Queue Type Queue Function Packet Transformation Chain in Queue Chain Function
Filter Packet filtering
FORWARD
Filters packets to servers
accessible by another NIC
on the firewall
.
INPUT
Filters packets destined to the
firewall
.
OUTPUT
Filters packets originating
from the firewall.
Nat Network Address Translation
PREROUTING
Address translation occurs
before routing. Facilitates the transformation of the destination
IP address to be compatible with the firewall’s routing table.
Used with NAT of the destination
IP address, also known as destination NAT or DNAT
.
POSTROUTING
Address translation occurs after
routing. This implies that there
was no need to modify the
destination IP address of the packet
as in pre-routing. Used with NAT
of the source IP address using either
one-to-one or many-to-one NAT.
This is known as source NAT,
or SNAT
.
OUTPUT
Network address translation for
packets generated by the firewall.
(Rarely used in SOHO environments
)
Mangle TCP header modification
PREROUTING
POSTROUTING
OUTPUT
INPUT
FORWARD
Modification of the TCP packet
quality of service bits before routing occurs.
(Rarely used in SOHO environments)