mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-10-26 08:41:46 +01:00
appendix/examples/zone-policy: add wiki legend and fix indentation
Add contents of the original legend at the wiki's image and adjust texts to 72 columns.
This commit is contained in:
currite
parent
2bf266ce3b
commit
28f47e3c29
@ -15,16 +15,31 @@ We have three networks.
|
||||
DMZ - 192.168.200.0/24, 2001:0DB8:0:BBBB::0/64
|
||||
|
||||
|
||||
This specific example is for a router on a stick, but is very easily adapted
|
||||
for however many NICs you have.
|
||||
**This specific example is for a router on a stick, but is very easily
|
||||
adapted for however many NICs you have**:
|
||||
|
||||
|
||||
* Internet - 192.168.200.100 - TCP/80
|
||||
* Internet - 192.168.200.100 - TCP/443
|
||||
* Internet - 192.168.200.100 - TCP/25
|
||||
* Internet - 192.168.200.100 - TCP/53
|
||||
* VyOS actis as DHCP, DNS forwarder, NAT, router and firewall.
|
||||
* 192.168.200.200/2001:0DB8:0:BBBB::200 is an internal/external DNS, web
|
||||
and mail (SMTP/IMAP) server.
|
||||
* 192.168.100.10/2001:0DB8:0:AAAA::10 is the administrator's console. It
|
||||
can SSH to VyOS.
|
||||
* LAN and DMZ hosts have basic outbound access: Web, FTP, SSH.
|
||||
* LAN can access DMZ resources.
|
||||
* DMZ cannot access LAN resources.
|
||||
* Inbound WAN connect to DMZ host.
|
||||
|
||||
.. image:: /_static/images/zone-policy-diagram.png
|
||||
:width: 80%
|
||||
:align: center
|
||||
:alt: Network Topology Diagram
|
||||
|
||||
The VyOS interface is assigned the .1/:1 address of their respective networks.
|
||||
WAN is on VLAN 10, LAN on VLAN 20, and DMZ on VLAN 30.
|
||||
The VyOS interface is assigned the .1/:1 address of their respective
|
||||
networks. WAN is on VLAN 10, LAN on VLAN 20, and DMZ on VLAN 30.
|
||||
|
||||
It will look something like this:
|
||||
|
||||
@ -57,31 +72,33 @@ It will look something like this:
|
||||
Zones Basics
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Each interface is assigned to a zone. The interface can be physical or virtual
|
||||
such as tunnels (VPN, pptp, gre, etc) and are treated exactly the same.
|
||||
Each interface is assigned to a zone. The interface can be physical or
|
||||
virtual such as tunnels (VPN, PPTP, GRE, etc) and are treated exactly
|
||||
the same.
|
||||
|
||||
Traffic flows from zone A to zone B. That flow is what I refer to as a
|
||||
zone-pair-direction. eg. A->B and B->A are two zone-pair-destinations.
|
||||
|
||||
Ruleset are created per zone-pair-direction.
|
||||
|
||||
I name rule sets to indicate which zone-pair-direction they represent. eg.
|
||||
ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ, DMZ-LAN.
|
||||
I name rule sets to indicate which zone-pair-direction they represent.
|
||||
eg. ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ, DMZ-LAN.
|
||||
|
||||
In VyOS, you have to have unique Ruleset names. In the event of overlap, I
|
||||
add a "-6" to the end of v6 rulesets. eg. LAN-DMZ, LAN-DMZ-6. This allows for
|
||||
each auto-completion and uniqueness.
|
||||
In VyOS, you have to have unique Ruleset names. In the event of overlap,
|
||||
I add a "-6" to the end of v6 rulesets. eg. LAN-DMZ, LAN-DMZ-6. This
|
||||
allows for each auto-completion and uniqueness.
|
||||
|
||||
In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is the
|
||||
firewall itself.
|
||||
In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is
|
||||
the firewall itself.
|
||||
|
||||
If your computer is on the LAN and you need to SSH into your VyOS box, you
|
||||
would need a rule to allow it in the LAN-Local ruleset. If you want to access
|
||||
a webpage from your VyOS box, you need a rule to allow it in the Local-LAN
|
||||
ruleset.
|
||||
If your computer is on the LAN and you need to SSH into your VyOS box,
|
||||
you would need a rule to allow it in the LAN-Local ruleset. If you want
|
||||
to access a webpage from your VyOS box, you need a rule to allow it in
|
||||
the Local-LAN ruleset.
|
||||
|
||||
In rules, it is good to keep them named consistently. As the number of rules
|
||||
you have grows, the more consistency you have, the easier your life will be.
|
||||
In rules, it is good to keep them named consistently. As the number of
|
||||
rules you have grows, the more consistency you have, the easier your
|
||||
life will be.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -97,14 +114,16 @@ you have grows, the more consistency you have, the easier your life will be.
|
||||
Rule 800 - SSH
|
||||
Rule 900 - IMAPS
|
||||
|
||||
The first two rules are to deal with the idiosyncrasies of VyOS and iptables.
|
||||
The first two rules are to deal with the idiosyncrasies of VyOS and
|
||||
iptables.
|
||||
|
||||
Zones and Rulesets both have a default action statement. When using
|
||||
Zone-Policies, the default action is set by the zone-policy statement and is
|
||||
represented by rule 10000.
|
||||
Zone-Policies, the default action is set by the zone-policy statement
|
||||
and is represented by rule 10000.
|
||||
|
||||
It is good practice to log both accepted and denied traffic. It can save you
|
||||
significant headaches when trying to troubleshoot a connectivity issue.
|
||||
It is good practice to log both accepted and denied traffic. It can save
|
||||
you significant headaches when trying to troubleshoot a connectivity
|
||||
issue.
|
||||
|
||||
To add logging to the default rule, do:
|
||||
|
||||
@ -113,38 +132,40 @@ To add logging to the default rule, do:
|
||||
set firewall name <ruleSet> enable-default-log
|
||||
|
||||
|
||||
By default, iptables does not allow traffic for established session to return,
|
||||
so you must explicitly allow this. I do this by adding two rules to every
|
||||
ruleset. 1 allows established and related state packets through and rule 2
|
||||
drops and logs invalid state packets. We place the established/related rule at
|
||||
the top because the vast majority of traffic on a network is established and
|
||||
the invalid rule to prevent invalid state packets from mistakenly being matched
|
||||
against other rules. Having the most matched rule listed first reduces CPU load
|
||||
in high volume environments. Note: I have filed a bug to have this added as a
|
||||
default action as well.
|
||||
By default, iptables does not allow traffic for established session to
|
||||
return, so you must explicitly allow this. I do this by adding two rules
|
||||
to every ruleset. 1 allows established and related state packets through
|
||||
and rule 2 drops and logs invalid state packets. We place the
|
||||
established/related rule at the top because the vast majority of traffic
|
||||
on a network is established and the invalid rule to prevent invalid
|
||||
state packets from mistakenly being matched against other rules. Having
|
||||
the most matched rule listed first reduces CPU load in high volume
|
||||
environments. Note: I have filed a bug to have this added as a default
|
||||
action as well.
|
||||
|
||||
''It is important to note, that you do not want to add logging to the
|
||||
established state rule as you will be logging both the inbound and outbound
|
||||
packets for each session instead of just the initiation of the session.
|
||||
Your logs will be massive in a very short period of time.''
|
||||
established state rule as you will be logging both the inbound and
|
||||
outbound packets for each session instead of just the initiation of the
|
||||
session. Your logs will be massive in a very short period of time.''
|
||||
|
||||
In VyOS you must have the interfaces created before you can apply it to the
|
||||
zone and the rulesets must be created prior to applying it to a zone-policy.
|
||||
In VyOS you must have the interfaces created before you can apply it to
|
||||
the zone and the rulesets must be created prior to applying it to a
|
||||
zone-policy.
|
||||
|
||||
I create/configure the interfaces first. Build out the rulesets for each
|
||||
zone-pair-direction which includes at least the three state rules. Then I setup
|
||||
the zone-policies.
|
||||
zone-pair-direction which includes at least the three state rules. Then
|
||||
I setup the zone-policies.
|
||||
|
||||
Zones do not allow for a default action of accept; either drop or reject.
|
||||
It is important to remember this because if you apply an interface to a zone
|
||||
and commit, any active connections will be dropped. Specifically, if you are
|
||||
SSH’d into VyOS and add local or the interface you are connecting through to a
|
||||
zone and do not have rulesets in place to allow SSH and established sessions,
|
||||
you will not be able to connect.
|
||||
Zones do not allow for a default action of accept; either drop or
|
||||
reject. It is important to remember this because if you apply an
|
||||
interface to a zone and commit, any active connections will be dropped.
|
||||
Specifically, if you are SSH’d into VyOS and add local or the interface
|
||||
you are connecting through to a zone and do not have rulesets in place
|
||||
to allow SSH and established sessions, you will not be able to connect.
|
||||
|
||||
The following are the rules that were created for this example
|
||||
(may not be complete), both in IPv4 and IPv6. If there is no IP specified,
|
||||
then the source/destination address is not explicit.
|
||||
The following are the rules that were created for this example (may not
|
||||
be complete), both in IPv4 and IPv6. If there is no IP specified, then
|
||||
the source/destination address is not explicit.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -213,10 +234,10 @@ Since we have 4 zones, we need to setup the following rulesets.
|
||||
Dmz-wan
|
||||
Dmz-local
|
||||
|
||||
Even if the two zones will never communicate, it is a good idea to create the
|
||||
zone-pair-direction rulesets and set enable-default-log. This will allow you to
|
||||
log attempts to access the networks. Without it, you will never see the
|
||||
connection attempts.
|
||||
Even if the two zones will never communicate, it is a good idea to
|
||||
create the zone-pair-direction rulesets and set enable-default-log. This
|
||||
will allow you to log attempts to access the networks. Without it, you
|
||||
will never see the connection attempts.
|
||||
|
||||
This is an example of the three base rules.
|
||||
|
||||
@ -325,26 +346,32 @@ Start by setting the interface and default action for each zone.
|
||||
set zone-policy zone dmz default-action drop
|
||||
set zone-policy zone dmz interface eth0.30
|
||||
|
||||
In this case, we are setting the v6 ruleset that represents traffic sourced
|
||||
from the LAN, destined for the DMZ.
|
||||
Because the zone-policy firewall syntax is a little awkward, I keep it straight
|
||||
by thinking of it backwards.
|
||||
In this case, we are setting the v6 ruleset that represents traffic
|
||||
sourced from the LAN, destined for the DMZ. Because the zone-policy
|
||||
firewall syntax is a little awkward, I keep it straight by thinking of
|
||||
it backwards.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
set zone-policy zone dmz from lan firewall ipv6-name lan-dmz-6
|
||||
|
||||
dmz-lan policy is lan-dmz. You can get a rhythm to it when you build out a bunch at one time.
|
||||
DMZ-LAN policy is LAN-DMZ. You can get a rhythm to it when you build out
|
||||
a bunch at one time.
|
||||
|
||||
In the end, you will end up with something like this config. I took out everything but the Firewall, Interfaces, and zone-policy sections. It is long enough as is.
|
||||
In the end, you will end up with something like this config. I took out
|
||||
everything but the Firewall, Interfaces, and zone-policy sections. It is
|
||||
long enough as is.
|
||||
|
||||
|
||||
IPv6 Tunnel
|
||||
^^^^^^^^^^^
|
||||
|
||||
If you are using a IPv6 tunnel from HE.net or someone else, the basis is the same except you have two WAN interface. One for v4 and one for v6.
|
||||
If you are using a IPv6 tunnel from HE.net or someone else, the basis is
|
||||
the same except you have two WAN interface. One for v4 and one for v6.
|
||||
|
||||
You would have 5 zones instead of just 4 and you would configure your v6 ruleset between your tunnel interface and your LAN/DMZ zones instead of to the WAN.
|
||||
You would have 5 zones instead of just 4 and you would configure your v6
|
||||
ruleset between your tunnel interface and your LAN/DMZ zones instead of
|
||||
to the WAN.
|
||||
|
||||
LAN, WAN, DMZ, local and TUN (tunnel)
|
||||
|
||||
@ -367,7 +394,8 @@ v6 pairs would be:
|
||||
|
||||
Notice, none go to WAN since WAN wouldn't have a v6 address on it.
|
||||
|
||||
You would have to add a couple of rules on your wan-local ruleset to allow protocol 41 in.
|
||||
You would have to add a couple of rules on your wan-local ruleset to
|
||||
allow protocol 41 in.
|
||||
|
||||
Something like:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user