After reading the Configuration guild as well as the Command
Reference I believe I now have a much better understanding
on how the OFR firewall(s) works as well as how NAT is affected.
I should also say so far my testing (I'm in the early phase
of testing) seem to prove what I state. I'm writing this
up no so much for myself but for future OFR users who may
need a better understanding.
Below is my attempt at trying to explain what I have gained.
There is still a major hole which I will point out.
<Note to the Vyatta Tech writers>
The information on firewalls in the Configuration guild is
only fair. Work needs to be done to improve the information
and the firewall options which are offered. By cleaning up
the chapters others will have an easier time of understanding
firewalls. I admit I'm not a tech writer, I'm just an end
user who needs to understand the document.
</Note>
The example I will use is where the OFR is a 'boader' router
between the Internet (WAN) and the internal LAN. I believe
once this example is understood any other use will be easy
to understand.
In the base configuration of OFR there is two interfaces
(eth0 - WAN side, and eth1 - LAN side). It should be noted
the OFR can support a total of 23 interfaces which means that
it can have a total of 23 firewalls.
Each interface his a firewall, which is broken into 3 parts.
And the packets are filtered as they transverse the interface.
The firewall 3 parts are:
In - deals with packets as they come through the interface
'IN'to the OFR.
Out - deals with packets as they go from the OFR out through
the interface to the remote machine(s) either on the WAN or
on the LAN.
Local - deals with packets which come from remote machine(s)
through the interface for a process running 'in' or 'on' the
OFR. The packets via this firewall will never pass through
the router to be routed to any other interface.
When a packet comes into the router and is routed via NAT
it will not pass thought a firewall UNTIL after the internal
IP address has been routed to the final target IP address and
as it transverse the interface via the 'out' firewall.
The last paragraph is only explained in the NAT section of
the Configuration guild.
<Hole in the current OFR docs>
While the Configuration guild somewhat touches on how the
firewall is used for NATS I believe this is really not
correctly fully explained.
I *believe* as the packet passes through the WAN interface
the 'In' firewall should be able to affect the packet BEFORE
any NAT routing happens and before the 'out' interface on the
'LAN' side and visa versa.
Maybe someone can clear this up so we have a better
understanding on how the 'In' interface firewall works with NAT
before it gets passed to the 'out' interface firewall.
</Hole>
Now lets look at what happen when we specified a port in a
NAT rule. Lets use port 80 (http) as an example.
As a packet comes into the OFR to be routed via NAT it has
an IP address which can be changed to a new IP before the
firewall. Specifying a port in NAT *does not* punch a hole
in the firewall. The *only* place where a hole can be punch
is in the firewall rule (not the NAT rule). So yes it is
possible that a packet for port 80 to be blocked at the
'out' firewall on the LAN interface even though port 80
has been define in a NAT rule and routed to a new IP.
Responder lists (or what Cisco calls them)
The concept of a responder list is all incoming packets are
blocked *unless* they are a reply to a packet which was already
sent. This is very nice way to block all 'new' packets at the
firewall unless a hole has been punched to allow new packets.
I should also note that after all user define rules, there is
an implicit rule of 'deny all' which can also help but can
block packets at the wrong time. The quote below will help
to understand why.
<quote from Command Reference page 366 dealing with 'state'>
established This rule will be applied to packget that are part
of a connection that has seen packets in both
directions (for example, a reply packet, or
an outgoing packet on a connection that has been
replied to). Supported values are as follows:
enable: Allow packets that are part of an established
connection.
disable: Block packets that are part of an established
connection.
The default is disable.
new This rule will applied to packets created new
connections. For TCP, this will be packets with the
SYN flag set. Supported values are as follows:
enable: Allow packets that are part of a new
connections. For TCP, this will be with the SYN flag
set. Supported values are as follows:
enable: Allow packets that are part of a new
connections.
disable: Block packets that are part of new connection.
The default is disable
</quote>
If an 'established' rule is not used then only packets
which would be allowed through the firewall would be where
a hole was punched. Reply packet would be blocked.
So what I have done with my 'out' LAN interface firewall is
to have the below rules. Remember the rules are applied in
order of their number. Which means rules which will be hit
most often should have a lower number.
rule #1 - allow all packets from my LAN to be routed back to my
LAN
rule #2 - allow established packets
rule #4 - allow new SMTP packets
rule #4 - allow new HTTP packets
rule #5 - allow new SSH packets
rule #6 - allow new ICMP 'echo' packet
rule #7 - allow new ICMP 'echo reply' packet
rule #n - allow new ***** packet
I will use similar rules on the 'local' WAN interface firewall
to allow established, SSH and NTP only to the router from the
WAN. As for the 'local' LAN interface I will allow established,
SSH, HTTP and NTP.
I realize this is not the definitive answer to firewalls but
as I stated earlier, it is my understanding of the OFR
firewalls. I welcome commits to clear up any mis-understanding
I may have.
Tony
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users
