Network Configuration: Difference between revisions
No edit summary |
|||
| (14 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
= Network Configuration = | = Network Configuration = | ||
The most critical configuration in | The most critical configuration in NG Firewall is the proper configuration of your network settings in [[Config]] > [[Network]]. For simple, networks the configuration completed during the [[Setup Wizard]] is probably sufficient. However, some networks have multiple WANs, multiple LANs, various subnets, VLANs, VRRP, etc. This describes how networking operates and is configured in NG Firewall. | ||
== Cardinal Rules == | == Cardinal Rules == | ||
There are several key rules to how | There are several key rules to how NG Firewall operates that should be understood before deploying NG Firewall in an advanced/complex network. | ||
{| | {| | ||
| Line 11: | Line 11: | ||
[[File:alert.jpg|right|100px|caption]] | [[File:alert.jpg|right|100px|caption]] | ||
| | | | ||
# ''' | # '''NG Firewall MUST be installed in-line.''' | ||
# ''' | # '''NG Firewall MUST have a working internet connection.''' | ||
# ''' | # '''NG Firewall routes ALL traffic according to its routing table.''' | ||
|} | |} | ||
''' | '''NG Firewall MUST be installed in-line.''' NG Firewall is a gateway product, and it is designed to be in-line with network traffic. Some network administrators want to deploy some of the functionality of NG Firewall without installing it in-line. This isn't how NG Firewall is designed and it will likely not work. | ||
For example, [[Spam Blocker]] will filter SMTP as it passes through | For example, [[Spam Blocker]] will filter SMTP as it passes through NG Firewall. It will not store-and-forward to your email server like some products. [[Web Filter]] will filter web traffic as it passes through NG Firewall. It is does not operate as a explicit proxy that you "point" clients' browsers to send web traffic. All applications and functionality are designed to operate in a context where NG Firewall is installed in-line with the network flow of traffic. | ||
''' | '''NG Firewall MUST have a working internet connection.''' NG Firewall and many of its apps rely on cloud services. NG Firewall must have a working and consistent connection with the internet. This includes unfiltered HTTPS, HTTP, and DNS access to various cloud services. Without a valid internet connection and configuration many functions of NG Firewall will not work properly. | ||
''' | '''NG Firewall routes ALL traffic according to its routing table.''' Obviously, this is how all routers operate. They receive packets on an interface and then lookup in the routing table/rules where to send it. Where NG Firewall differs is that it is often installed as a bridge or with some interfaces bridged together. In the NG Firewall context, two bridged interfaces share a configuration (some products call them "zones"). Traffic passing between bridged interfaces are still subject to this cardinal rule. | ||
This is often a surprise to people on complex networks as effectively you will need to tell | This is often a surprise to people on complex networks as effectively you will need to tell NG Firewall where to send all the traffic on your network if you want it to go to the correct place. If you have a subnet that NG Firewall doesn't have a route for, then it will be sent to the default gateway even if that subnet is internal. For NG Firewall to operate correctly, you must configure it with a complete routing table so it knows how to reach all hosts on your network. | ||
== Placing | == Placing NG Firewall on the Network == | ||
The first step, after understanding the above cardinal rules, is to decide where to place | The first step, after understanding the above cardinal rules, is to decide where to place NG Firewall on the network. Obviously, NG Firewall must be installed in-line with all network traffic so this provides two options: | ||
# Install | # Install NG Firewall as the gateway/firewall for the network. | ||
# Install | # Install NG Firewall ''behind'' an existing gateway/firewall in flow with traffic. | ||
Installing | Installing NG Firewall as the gateway/firewall is recommended. It is usually the simplest approach and it allows NG Firewall to leverage its full feature set including [[WAN Failover]] and [[WAN Balancer]]. This also places it in a convenient place to handle other separate internal networks (like wireless segments) that may only be connected at the gateway. Also, If you have tagged VLANs it is much simpler to run NG Firewall as a endpoint of those VLANs. This is commonly referred to as ''router mode.'' | ||
However, often organizations don't want to replace the existing gateway/firewall or can't because it is controlled by a different organization. In these cases, installing | However, often organizations don't want to replace the existing gateway/firewall or can't because it is controlled by a different organization. In these cases, installing NG Firewall as a "bridge" behind the gateway allows NG Firewall and the apps to scan and process network traffic without providing the routing functions of your firewall. This is commonly referred to as ''bridge mode.'' | ||
Also, technically you can stick | Also, technically you can stick NG Firewall ''in front of'' an existing firewall. Typically firewall/gateways use NAT so all internal hosts share external IPs. This means by the time the traffic reaches the NG Firewall outside the firewall the source address of all internal communication will have the public address of the firewall. As such, NG Firewall can not differentiate between internal hosts so much of the functionality of NG Firewall (Web Filter, Reports, Shield, and so on) is severely compromised. Installing NG Firewall outside a NAT device is never recommended. | ||
== Configuring the Interfaces == | == Configuring the Interfaces == | ||
The second major step, after choosing a place to deploy | The second major step, after choosing a place to deploy NG Firewall, is configuring the interfaces. All the configuration options of interfaces are documented in [[Interfaces|the Interfaces documentation]]. | ||
Likely, External and Internal and are already configured from the [[Setup Wizard]]. | Likely, External and Internal and are already configured from the [[Setup Wizard]]. | ||
| Line 48: | Line 48: | ||
* Configure additional subnets on the External/Internal. | * Configure additional subnets on the External/Internal. | ||
Because | Because NG Firewall routes all traffic according to its routing table, additional routes/aliases may be required for any additional subnets on your network. | ||
More information on that in [[Installation#Configure Other Subnets]] | More information can be found on that in [[Installation#Configure Other Subnets]] | ||
* Configure additional interfaces | * Configure additional interfaces | ||
After the setup wizard only External and Internal are configured. Additional interfaces are disabled and still require configuration. | After the setup wizard only External and Internal are configured. Additional interfaces are disabled and still require configuration. | ||
More information on that in [[Installation#Configure Other Interfaces]] | More information can be found on that in [[Installation#Configure Other Interfaces]] | ||
* Configure any tagged VLANs | * Configure any tagged VLANs | ||
If you have tagged VLANs (802.1q) on your network | If you have tagged VLANs (802.1q) on your network, you will need to add [[Network Configuration#VLANs|VLAN Tagged Interfaces]]. | ||
== Bridging == | == Bridging == | ||
When two interfaces are bridged in | When two interfaces are bridged in NG Firewall this means they are effectively sharing a configuration. | ||
Some products use the concept of "zones." In this terminology, bridging two interfaces puts those interfaces in the same "zone" or "network space." | Some products use the concept of "zones." In this terminology, bridging two interfaces puts those interfaces in the same "zone" or "network space." | ||
| Line 70: | Line 70: | ||
This is extremely useful when there is a firewall upstream. | This is extremely useful when there is a firewall upstream. | ||
For example, if the firewall is 192.168.1.1, then you can | For example, if the firewall is 192.168.1.1, then you can configure External as 192.168.1.2/24 with 192.168.1.1 as the gateway. | ||
The internal hosts all have 192.168.1.* addresses and can continue to use 192.168.1.1 as a gateway (192.168.1.2 will also work as a gateway). | The internal hosts all have 192.168.1.* addresses and can continue to use 192.168.1.1 as a gateway (192.168.1.2 will also work as a gateway). | ||
[[Image:bridge_scenario_standard.png|center|Standard Bridge Mode]] | [[Image:bridge_scenario_standard.png|center|Standard Bridge Mode]] | ||
It is important to remember that even when bridging '' | It is important to remember that even when bridging ''NG Firewall routes ALL traffic according to its routing table.'' | ||
This means if you have other subnets besides 192.168.1.* like 192.168.2.*, then you will need to add aliases or routes for them otherwise that traffic will go to the default gateway. | This means if you have other subnets besides 192.168.1.* like 192.168.2.*, then you will need to add aliases or routes for them otherwise that traffic will go to the default gateway. | ||
=== DMZ Bridge === | === DMZ Bridge === | ||
Another common scenario to use bridging is when | Another common scenario to use bridging is when NG Firewall has a public IP (1.2.3.2 in this example), but you have other public servers with public IPs (1.2.3.*). | ||
You could put those servers on the private network and use [[Port Forward Rules]]. But lets assume you wanted to keep them configured with public IPs to keep them separate from the internal and avoid any NAT/port forwarding issues. | You could put those servers on the private network and use [[Port Forward Rules]]. But lets assume you wanted to keep them configured with public IPs to keep them separate from the internal and avoid any NAT/port forwarding issues. | ||
| Line 91: | Line 91: | ||
You can also just use bridge mode to provide alternate ports to existing interfaces/zones. | You can also just use bridge mode to provide alternate ports to existing interfaces/zones. | ||
Be careful, as traffic between the two goes through | Be careful, as traffic between the two goes through NG Firewall! | ||
For example, if ''Interface 2'' is configured as 192.168.1.1/24 and ''Interface 3'' is bridged to ''Interface 2'', then they are both effectively 192.168.1.1. | For example, if ''Interface 2'' is configured as 192.168.1.1/24 and ''Interface 3'' is bridged to ''Interface 2'', then they are both effectively 192.168.1.1. | ||
| Line 103: | Line 103: | ||
There are some important differences: | There are some important differences: | ||
* In scenario 1, traffic between ''Interface 2'' and ''Interface 3'' goes through | * In scenario 1, traffic between ''Interface 2'' and ''Interface 3'' goes through NG Firewall and is routed via NG Firewall's routing table | ||
* In scenario 1, traffic between ''Interface 2'' and ''Interface 3'' goes through | * In scenario 1, traffic between ''Interface 2'' and ''Interface 3'' goes through NG Firewall and is scanned by the apps (if not bypassed via [[Bypass Rules]]) | ||
=== What "bridged" really means. === | === What "bridged" really means. === | ||
In | In NG Firewall when two interfaces are bridged it means that they are in the same zone or that they both connect to the same network space. As the [[Network_Configuration#Cardinal_Rules|cardinal]] rules explain, '''NG Firewall routes all traffic according to its routing table''' - even those crossing between two bridged interfaces. This is sometimes called ''brouting'' or a ''brouter'' - unlike how a traditional layer-2 bridge/switch behaves. | ||
It | It means that packets coming inside one side of a bridge will NOT necessarily exit the other side of the bridge. It also means that packets destined with a specific route will be routed according to NG Firewall's routing table. '''All traffic is routed according to NG Firewall's routing table.''' It also means MAC addresses are not maintained across segments, even if they are bridged together as packets are brouted. | ||
This may cause you to wonder how | This may cause you to wonder how NG Firewall works in the traditional "Bridge Mode." The answer is simple, for outbound traffic to the internet NG Firewall will route that to its default gateway which was probably where the traffic was headed anyway and definitely where it should go. For inbound traffic NG Firewall knows where each local host on the bridged segment lives and it routes it directly. So inbound and outbound traffic both flow as expected. | ||
Where things get complicated is when networks have more complicated routes and do not configure | Where things get complicated is when networks have more complicated routes and do not configure NG Firewall with those routes. Assume NG Firewall is installed in traditional bridge mode on a 192.168.1.1/24 network. Lets assume the network also has another internal network of 192.168.2.1/24 behind an internal router 192.168.1.100. There is probably already a route on the existing firewall telling it that 192.168.2.* can be reached behind 192.168.1.100. If the user then inserts NG Firewall in bridge mode and configures it as 192.168.1.2, the entire 192.168.1.* network will work but none of the traffic on 192.168.2.* will work. Why? Because NG Firewall routes *all* traffic according to its routing table. The firewall will route 192.168.2.* traffic to 192.168.1.100. When that traffic passes through NG Firewall it will not route it to 192.168.1.100 - it will route it according to its routing table. Since it knows nothing about 192.168.2.* and those addresses aren't local, it will be sent back out to the default gateway. As such the 192.168.2.* network will be completely offline as return traffic from the internet will not reach those hosts. Once a 192.168.2.0/24 route to 192.168.1.100 is added to NG Firewall traffic will flow as expected. The routing table on NG Firewall must reflect the layout of the network. | ||
Another common scenario is bridging two separate networks with one | Another common scenario is bridging two separate networks with one NG Firewall server. Lets look at an example with 4 interfaces: network1External, network1Internal, network2External, network2Internal. network1Internal is bridged to network1External. network2Internal is bridged to network2External. The problem with this scenario is that '''NG Firewall routes all traffic according to its routing table.''' If traffic comes in on network2Internal and is bound for the internet it will '''NOT''' be sent out network2External just because that's where it was originally headed. It will be routed according to NG Firewall's routing table, which is the default route of NG Firewall - probably network1External's gateway! To setup this scenario one must use WAN Balancer and routes to assure that traffic coming in network2Internal is routed via network2External. This is true whether or not the separate network or separate physical networks or separate VLAN networks. | ||
The key to using bridge mode effectively is understanding how | The key to using bridge mode effectively is understanding how NG Firewall routes traffic. While bridging can often be convenient it can also create headaches for complicated setups. | ||
== NAT == | == NAT == | ||
NAT or Network Address Translation is the operation of rewriting the source address of packets. Typically this is used so many internal hosts with internal IPs (192.168.*.*, 10.*.*.*, | NAT or Network Address Translation is the operation of rewriting the source address of packets. Typically this is used so many internal hosts with internal IPs (192.168.*.*, 10.*.*.*, and so on) can share one or several public IPs. | ||
There are 3 ways that NAT is done is | There are 3 ways that NAT is done is NG Firewall: | ||
# If you check ''NAT traffic exiting this interface (and bridged peers)'' on any WAN interface configuration. | # If you check ''NAT traffic exiting this interface (and bridged peers)'' on any WAN interface configuration. | ||
| Line 132: | Line 132: | ||
=== NAT traffic exiting this interface (and bridged peers) === | === NAT traffic exiting this interface (and bridged peers) === | ||
The first option is ''NAT traffic exiting this interface (and bridged peers)'' | The first option is ''NAT traffic exiting this interface (and bridged peers)''. As described in the [[Interfaces]] documentation, this option will NAT any traffic exiting this interface and any of its bridged peers. This is enabled by default on WANs. | ||
What this means is that any and all traffic exiting that WAN interface or bridged peers will be NATd to ''auto'' which is the current primary address of that WAN interface. Traffic between this interface and any bridged peers will not be NATd. Checking this option also blocks all traffic coming to this WAN that is not to a local process or explicitly forwarded with a [[Port Forward Rules|Port Forward Rule]]. | What this means is that any and all traffic exiting that WAN interface or bridged peers will be NATd to ''auto'' which is the current primary address of that WAN interface. Traffic between this interface and any bridged peers will not be NATd. Checking this option also blocks all traffic coming to this WAN that is not to a local process or explicitly forwarded with a [[Port Forward Rules|Port Forward Rule]]. | ||
| Line 144: | Line 144: | ||
=== When and Where to perform NAT === | === When and Where to perform NAT === | ||
If there are only two interfaces in | If there are only two interfaces in NG Firewall the first and second options are identical. When there are multiple internal subnets you will need to configure where you wish to NAT so that you have the desired behavior. | ||
If you wish internal networks to be able to speak with each other ( | If you wish internal networks to be able to speak with each other (''i.e.'' 192.168.1.100 should be able to reach 192.168.2.100 on a different interface) then you do not want to NAT between those networks. | ||
[[Image:nat_scenario_wan.png|center|Scenario 1:NAT at WAN]] | [[Image:nat_scenario_wan.png|center|Scenario 1:NAT at WAN]] | ||
| Line 161: | Line 161: | ||
NAT rules can be used in conjunction with the two NAT checkboxes and any matched NAT rule will take precedence. Most networks need only one the first two options, but sometimes there are scenarios where a NAT rule is wanted desired such as [[1:1 NAT]] or when you want to guarantee that certain traffic (like SMTP exiting an email server) uses another address other than the primary WAN address. | NAT rules can be used in conjunction with the two NAT checkboxes and any matched NAT rule will take precedence. Most networks need only one the first two options, but sometimes there are scenarios where a NAT rule is wanted desired such as [[1:1 NAT]] or when you want to guarantee that certain traffic (like SMTP exiting an email server) uses another address other than the primary WAN address. | ||
If no NAT option is enabled (all unchecked and no NAT rules) then | If no NAT option is enabled (all unchecked and no NAT rules) then NG Firewall will route like a typical router without performing any NAT operation. | ||
''Note:'' The ''NAT traffic exiting this interface (and bridged peers)'' option in WAN is equivalent to appending an ''Auto'' NAT rule to the end of the [[NAT Rules]] matching all traffic with ''Destination Interface'' equal to that WAN or any bridged peer but excluding traffic between any bridged peers in that zone. It also includes a [[Filter Rules|forward filter rule]] to block inbound sessions from this WAN or bridged peers not explicitly port forwarded excluding sessions between any bridged peers in that zone. | ''Note:'' The ''NAT traffic exiting this interface (and bridged peers)'' option in WAN is equivalent to appending an ''Auto'' NAT rule to the end of the [[NAT Rules]] matching all traffic with ''Destination Interface'' equal to that WAN or any bridged peer but excluding traffic between any bridged peers in that zone. It also includes a [[Filter Rules|forward filter rule]] to block inbound sessions from this WAN or bridged peers not explicitly port forwarded excluding sessions between any bridged peers in that zone. | ||
| Line 174: | Line 174: | ||
'''IMPORTANT:''' | '''IMPORTANT:''' | ||
The term VLAN is sometimes also used to describe putting multiple untagged (no 802.1q tag) subnets on the same wire. For example, | The term VLAN is sometimes also used to describe putting multiple untagged (no 802.1q tag) subnets on the same wire. For example, NG Firewall is in bridge mode as 192.168.1.2/24 but there is also a 192.168.2.* on the same wire. | ||
If there are no 802.1q tags on the 192.168.2.* traffic - it is '''NOT''' a VLAN and new VLAN interfaces should '''NOT''' be created on | If there are no 802.1q tags on the 192.168.2.* traffic - it is '''NOT''' a VLAN and new VLAN interfaces should '''NOT''' be created on NG Firewall. In this scenario you should use guidance in [[Installation#Configure Other Subnets]] to properly configure NG Firewall to handle these subnets. VLAN interfaces will '''ONLY''' handle tagged 802.1q packets and all packets sent to a VLAN interface will be tagged with 802.1q tags. | ||
</blockquote> | </blockquote> | ||
VLANs have several uses. Often you want multiple completely separate internal subnets on a network, but you do not want to run multiple physical ethernet networks through a building. VLANs allow you to run multiple networks on the same physical wire while still guaranteeing they are completely separate and secure. To do this you must have VLAN enabled switches and products through-out the network. VLANs can also be useful if you have limited ethernet ports on | VLANs have several uses. Often you want multiple completely separate internal subnets on a network, but you do not want to run multiple physical ethernet networks through a building. VLANs allow you to run multiple networks on the same physical wire while still guaranteeing they are completely separate and secure. To do this you must have VLAN enabled switches and products through-out the network. VLANs can also be useful if you have limited ethernet ports on NG Firewall and wish to overload a single NIC with two separate purposes. This requires that NIC to be connected to a VLAN enabled switch. | ||
To create a VLAN interface click on the ''Add Tagged VLAN Interface'' button at the bottom of the interfaces grid on the [[Config]] > [[Network]] > [[Interfaces]]. This will create a new ''virtual interface.'' First, you will need to give this interface a new name, and also select the ''Parent Interface.'' The ''Parent Interface'' is the physical interface that this VLAN virtual interface exists on. Then you will need to configure an ''802.1q Tag'' which is an integer between 1 and 4094 inclusive. After this you will configure the interface just like any interface. | To create a VLAN interface click on the ''Add Tagged VLAN Interface'' button at the bottom of the interfaces grid on the [[Config]] > [[Network]] > [[Interfaces]]. This will create a new ''virtual interface.'' First, you will need to give this interface a new name, and also select the ''Parent Interface.'' The ''Parent Interface'' is the physical interface that this VLAN virtual interface exists on. Then you will need to configure an ''802.1q Tag'' which is an integer between 1 and 4094 inclusive. After this you will configure the interface just like any interface. | ||
This new ''VLAN interface'' is just like a physical interface in all ways. This means you can configured this VLAN interface exactly like any physical interface. It is completely separate from the physical parent interface. Any packet coming in on the physical parent interface with the 802.1q tag matching the configured value (1-4094) will be considered by | This new ''VLAN interface'' is just like a physical interface in all ways. This means you can configured this VLAN interface exactly like any physical interface. It is completely separate from the physical parent interface. Any packet coming in on the physical parent interface with the 802.1q tag matching the configured value (1-4094) will be considered by NG Firewall to be coming in the VLAN interface. Any packet sent to the virtual VLAN interface will actually be sent on the physical parent interface with the configured 802.1q tag. All untagged packets on the physical parent interface will be processed like normal through the physical parent interface, only 802.1q tagged packets with the matching 802.1q tag will be processed by the VLAN interface. | ||
After configuring | After configuring NG Firewall with the appropriate tagged VLAN interfaces, you will need to configured some VLAN-enabled managed switch to properly process the packets as desired. For example, [http://vinf.net/2011/01/27/how-to-configure-a-port-based-vlan-on-an-hp-procurve-1810g-switch/ here is a document] describing how to configure a HP ProCurve switch. | ||
<blockquote> | <blockquote> | ||
| Line 197: | Line 197: | ||
===Configuring VLAN on | ===Configuring VLAN on NG Firewall in Bridge Mode=== | ||
Some users want to configure | Some users want to configure NG Firewall in bridge mode in the middle of a VLANed network. | ||
This is possible, but '''NOT RECOMMENDED'''. It is suggested to install | This is possible, but '''NOT RECOMMENDED'''. It is suggested to install NG Firewall as the gateway and terminate VLANs on an addressed VLAN interface. However, if you wish to install NG Firewall as a bridge in the middle of several (V)LANs simultaneously, the following instructions will allow you to establish multiple bridges and then enter the routes to tell NG Firewall that if traffic enters on a specific interface it should exit the bridged peer. | ||
*You will need to create 2 virtual interfaces for each VLAN you want to set up. | *You will need to create 2 virtual interfaces for each VLAN you want to set up. | ||
| Line 219: | Line 219: | ||
#Enter DNS servers you would like to use | #Enter DNS servers you would like to use | ||
</blockquote> | </blockquote> | ||
[[Image:external_vlan.png| | [[Image:external_vlan.png|600px|center|Scenario 1: Additional Port]] | ||
*To set up the internal's VLAN interface | *To set up the internal's VLAN interface | ||
| Line 230: | Line 230: | ||
#Bridge this interface to the external VLAN interface | #Bridge this interface to the external VLAN interface | ||
</blockquote> | </blockquote> | ||
[[Image:internal_vlan.png| | [[Image:internal_vlan.png|600px|center|Scenario 1: Additional Port]] | ||
*Go to WAN Balancer and set the weights to send 100% of network traffic out of your untagged external interface | *Go to WAN Balancer and set the weights to send 100% of network traffic out of your untagged external interface | ||
| Line 242: | Line 242: | ||
== VRRP == | == VRRP == | ||
VRRP provides redundancy | VRRP provides network level redundancy. | ||
Multiple | Multiple NG Firewalls can be run in parallel in a high availability configuration. | ||
In this configuration one | In this configuration one NG Firewall will be the "primary" and one or more NG Firewalls will be the "secondary." | ||
In the event the | In the event the primary fails, one of the remaining secondary NG Firewall will take over the primary role such that network traffic continues to flow without interruption. | ||
NG Firewall uses VRRP or [http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol Virtual Redundancy Router Protocol] to handle the switching between NG Firewall servers. | |||
All | All NG Firewall servers must be on and all configured with a share VRRP Virtual Address. The primary is the only NG Firewall to answer/handle traffic routed to the VRRP Virtual Address. | ||
If the | If the primary fails an "election" is held over VRRP and the next-highest-priority secondary will begin handling traffic to the VRRP Virtual Address. | ||
All | All NG Firewall interfaces must be configured statically, and there must be no bridged interfaces. Parallel NG Firewalls configured as bridges will create a bridge loop! | ||
=== VRRP Basic Example === | === VRRP Basic Example === | ||
A common configuration is running two | A common configuration is running two NG Firewalls to act as the gateway for the internal network. | ||
For example, | For example, let's assume NG Firewall 1, the primary, has a public IP of 1.2.3.4 and an internal IP of 192.168.1.2. | ||
Lets assume | Lets assume NG Firewall 2 has a public IP of 1.2.3.5 and an internal IP of 192.168.1.3. | ||
Both are running in "router" mode and doing NAT and acting as a gateway. Note that all IPs must be unique! | Both are running in "router" mode and doing NAT and acting as a gateway. Note that all IPs must be unique! | ||
This configuration requires each | This configuration requires each NG Firewall to have its own external IP! | ||
Now we configure | Now we configure NG Firewall 1 to have a VRRP Virtual Address of 192.168.1.1 on the Internal interface, and also configure NG Firewall 2 to also have a VRRP Virtual Address of 192.168.1.1 its Internal interface. | ||
They both share the same VRRP Virtual Address. Each | They both share the same VRRP Virtual Address. Each NG Firewall in the group must have the same VRRP ID. So let's give NG Firewall 1 a VRRP ID of 1 and also give NG Firewall 2 a VRRP ID of 1. | ||
We want | We want NG Firewall 1 to be the primary when it's on and working without issues so give it a higher priority of 100. | ||
NG Firewall 2 is the secondary so it should be given a lower priority: let's give it a lower priority of 50. | |||
[[Image:VrrpSingle.png|center|Simple VRRP Example]] | [[Image:VrrpSingle.png|center|Simple VRRP Example]] | ||
[[Image:VrrpUntangle1Internal.png|center|VRRP | [[Image:VrrpUntangle1Internal.png|center|VRRP NG Firewall 1 Config]] | ||
[[Image:VrrpUntangle2Internal.png|center|VRRP | [[Image:VrrpUntangle2Internal.png|center|VRRP NG Firewall 2 Config]] | ||
Configure your internal hosts to use the VRRP Virtual Address (192.168.1.1) as the gateway. In this configuration the | Configure your internal hosts to use the VRRP Virtual Address (192.168.1.1) as the gateway. In this configuration the primary will route all traffic to 192.168.1.1 just like a regular address. | ||
Should the | Should the primary fail within a few seconds the secondary will become the new primary and start routing traffic. | ||
Note: You should configure the DHCP server to hand out 192.168.1.1 as the default gateway. If | Note: You should configure the DHCP server to hand out 192.168.1.1 as the default gateway. If NG Firewall is providing DHCP. Configure NG Firewall 1 as the "authoritative" with 192.168.1.1 as the "Gateway Override." Configure NG Firewall 2 the same but as non-authoritative. This way NG Firewall 1 will handle all DHCP unless it is down, in which case NG Firewall 2 will handle DHCP. | ||
=== VRRP External Example === | === VRRP External Example === | ||
The above example work great for outbound traffic, but if you have inbound traffic being port forwarded that traffic might fail if the | The above example work great for outbound traffic, but if you have inbound traffic being port forwarded that traffic might fail if the NG Firewall owning that address fails. | ||
VRRP can also be used to provide redundancy for inbound traffic. For example, similar to above, | VRRP can also be used to provide redundancy for inbound traffic. For example, similar to above, let's assume you have NG Firewall 1 with 1.2.3.4 and NG Firewall 2 with 1.2.3.5. | ||
You can configure both with a shared VRRP Virtual Address of 1.2.3.3. Now configure port forwards on both | You can configure both with a shared VRRP Virtual Address of 1.2.3.3. Now configure port forwards on both NG Firewall for traffic destined to 1.2.3.3 to the appropriate internal host. | ||
Only the | Only the primary will handle traffic to 1.2.3.3. If the primary fails the secondary will take over traffic handling for 1.2.3.3 and port forwarding. External hosts will still be able to reach local services should the primary fail. | ||
In this scenario [[NAT Rules]] can also be configured if outbound traffic should use the same address regardless of which server is handling the traffic. | In this scenario [[NAT Rules]] can also be configured if outbound traffic should use the same address regardless of which server is handling the traffic. | ||
| Line 292: | Line 292: | ||
It is also possible to combine VRRP on multiple interfaces. For example, combine the above two examples. VRRP | It is also possible to combine VRRP on multiple interfaces. For example, combine the above two examples. VRRP | ||
can be used to provide redundancy on both interfaces. VRRP IDs must be unique for each server. For example, the external on both should be VRRP ID 1 and the internal on both should be VRRP ID 2. | can be used to provide redundancy on both interfaces. VRRP IDs must be unique for each server. For example, the external on both should be VRRP ID 1 and the internal on both should be VRRP ID 2. | ||
In this scenario VRRP is "grouped" such that if the server loses its " | In this scenario VRRP is "grouped" such that if the server loses its "primary" status on one interface it will also release its primary status on other interfaces. | ||
[[Image:VrrpDouble.png|center|Simple Combined Example]] | [[Image:VrrpDouble.png|center|Simple Combined Example]] | ||
[[Image:VrrpUntangle1External.png|center|VRRP | [[Image:VrrpUntangle1External.png|center|VRRP NG Firewall 1 Config]] | ||
[[Image:VrrpUntangle2External.png|center|VRRP | [[Image:VrrpUntangle2External.png|center|VRRP NG Firewall 2 Config]] | ||
[[Image:VrrpUntangle1Internal.png|center|VRRP | [[Image:VrrpUntangle1Internal.png|center|VRRP NG Firewall 1 Config]] | ||
[[Image:VrrpUntangle2Internal.png|center|VRRP | [[Image:VrrpUntangle2Internal.png|center|VRRP NG Firewall 2 Config]] | ||
For example, in the picture above if the Internal interface on | For example, in the picture above if the Internal interface on NG Firewall 1 is unplugged, then NG Firewall 2 will become the primary and start responding to 192.168.1.1. | ||
NG Firewall 1 will also release its primary status on the external interface so that NG Firewall 2 will also handle 1.2.3.3. This is to avoid any scenarios where NG Firewall 1 is primary the external address and NG Firewall 2 is primary on the internal address. | |||
=== VRRP FAQs === | === VRRP FAQs === | ||
| Line 312: | Line 312: | ||
==== What kind of problems count as a failure for VRRP purposes? ==== | ==== What kind of problems count as a failure for VRRP purposes? ==== | ||
Most critical hardware issues such as power outages, crashes, or freezes will immediately cause the VRRP broadcast to stop and the | Most critical hardware issues such as power outages, crashes, or freezes will immediately cause the VRRP broadcast to stop and the secondary will immediately take over. | ||
Furthermore, if some common errors are detected in software such as the NIC being unplugged then the VRRP broadcast is stopped. | Furthermore, if some common errors are detected in software such as the NIC being unplugged then the VRRP broadcast is stopped. | ||
==== How can I see which is the VRRP master? ==== | ==== How can I see which is the VRRP master? ==== | ||
The VRRP status is available in the VRRP settings. The ''Is VRRP Master?'' indicator will be green if | The VRRP status is available in the VRRP settings. The ''Is VRRP Master?'' indicator will be green if primary. | ||
==== How can I test my VRRP configuration? ==== | ==== How can I test my VRRP configuration? ==== | ||
Simply configure VRRP then unplug one of the VRRP | Simply configure VRRP then unplug one of the VRRP NG Firewall interfaces. The secondary should immediately take over and you should still be able to ping the VRRP Virtual Address. | ||
==== How quickly does traffic switch? ==== | ==== How quickly does traffic switch? ==== | ||
| Line 327: | Line 327: | ||
VRRP acts very quickly in the case of a failure and usually switches in less than a few seconds. However, TCP sessions will be reset as state is lost. | VRRP acts very quickly in the case of a failure and usually switches in less than a few seconds. However, TCP sessions will be reset as state is lost. | ||
==== Is state shared between | ==== Is state shared between NG Firewalls? ==== | ||
No. There is zero state sharing between | No. There is zero state sharing between NG Firewall. The session tables are separate, so sessions will be reset if the secondary takes over. Furthermore application data is not shared or synchronized between servers. | ||
This includes things like host tables, | This includes things like host tables, Captive Portal logins, OpenVPN state, IPsec state, email quarantines, Reports, quotas & penalty boxes, Web Filter bypass states, antispam learning, etc. | ||
==== Can I run VRRP in bridge mode? ==== | ==== Can I run VRRP in bridge mode? ==== | ||
No. " | No. "Secondary" NG Firewalls are still live, they just do not handle traffic to the VRRP Virtual Address. As such if any bridge loop is created with bridged interfaces between the primary and secondary the network will stop functioning. | ||
Latest revision as of 15:37, 3 May 2022
Network Configuration
The most critical configuration in NG Firewall is the proper configuration of your network settings in Config > Network. For simple, networks the configuration completed during the Setup Wizard is probably sufficient. However, some networks have multiple WANs, multiple LANs, various subnets, VLANs, VRRP, etc. This describes how networking operates and is configured in NG Firewall.
Cardinal Rules
There are several key rules to how NG Firewall operates that should be understood before deploying NG Firewall in an advanced/complex network.
 |
|
NG Firewall MUST be installed in-line. NG Firewall is a gateway product, and it is designed to be in-line with network traffic. Some network administrators want to deploy some of the functionality of NG Firewall without installing it in-line. This isn't how NG Firewall is designed and it will likely not work.
For example, Spam Blocker will filter SMTP as it passes through NG Firewall. It will not store-and-forward to your email server like some products. Web Filter will filter web traffic as it passes through NG Firewall. It is does not operate as a explicit proxy that you "point" clients' browsers to send web traffic. All applications and functionality are designed to operate in a context where NG Firewall is installed in-line with the network flow of traffic.
NG Firewall MUST have a working internet connection. NG Firewall and many of its apps rely on cloud services. NG Firewall must have a working and consistent connection with the internet. This includes unfiltered HTTPS, HTTP, and DNS access to various cloud services. Without a valid internet connection and configuration many functions of NG Firewall will not work properly.
NG Firewall routes ALL traffic according to its routing table. Obviously, this is how all routers operate. They receive packets on an interface and then lookup in the routing table/rules where to send it. Where NG Firewall differs is that it is often installed as a bridge or with some interfaces bridged together. In the NG Firewall context, two bridged interfaces share a configuration (some products call them "zones"). Traffic passing between bridged interfaces are still subject to this cardinal rule.
This is often a surprise to people on complex networks as effectively you will need to tell NG Firewall where to send all the traffic on your network if you want it to go to the correct place. If you have a subnet that NG Firewall doesn't have a route for, then it will be sent to the default gateway even if that subnet is internal. For NG Firewall to operate correctly, you must configure it with a complete routing table so it knows how to reach all hosts on your network.
Placing NG Firewall on the Network
The first step, after understanding the above cardinal rules, is to decide where to place NG Firewall on the network. Obviously, NG Firewall must be installed in-line with all network traffic so this provides two options:
- Install NG Firewall as the gateway/firewall for the network.
- Install NG Firewall behind an existing gateway/firewall in flow with traffic.
Installing NG Firewall as the gateway/firewall is recommended. It is usually the simplest approach and it allows NG Firewall to leverage its full feature set including WAN Failover and WAN Balancer. This also places it in a convenient place to handle other separate internal networks (like wireless segments) that may only be connected at the gateway. Also, If you have tagged VLANs it is much simpler to run NG Firewall as a endpoint of those VLANs. This is commonly referred to as router mode.
However, often organizations don't want to replace the existing gateway/firewall or can't because it is controlled by a different organization. In these cases, installing NG Firewall as a "bridge" behind the gateway allows NG Firewall and the apps to scan and process network traffic without providing the routing functions of your firewall. This is commonly referred to as bridge mode.
Also, technically you can stick NG Firewall in front of an existing firewall. Typically firewall/gateways use NAT so all internal hosts share external IPs. This means by the time the traffic reaches the NG Firewall outside the firewall the source address of all internal communication will have the public address of the firewall. As such, NG Firewall can not differentiate between internal hosts so much of the functionality of NG Firewall (Web Filter, Reports, Shield, and so on) is severely compromised. Installing NG Firewall outside a NAT device is never recommended.
Configuring the Interfaces
The second major step, after choosing a place to deploy NG Firewall, is configuring the interfaces. All the configuration options of interfaces are documented in the Interfaces documentation. Likely, External and Internal and are already configured from the Setup Wizard.
After the setup wizard you might still need to do some of the following configuration
- Configure additional subnets on the External/Internal.
Because NG Firewall routes all traffic according to its routing table, additional routes/aliases may be required for any additional subnets on your network. More information can be found on that in Installation#Configure Other Subnets
- Configure additional interfaces
After the setup wizard only External and Internal are configured. Additional interfaces are disabled and still require configuration. More information can be found on that in Installation#Configure Other Interfaces
- Configure any tagged VLANs
If you have tagged VLANs (802.1q) on your network, you will need to add VLAN Tagged Interfaces.
Bridging
When two interfaces are bridged in NG Firewall this means they are effectively sharing a configuration. Some products use the concept of "zones." In this terminology, bridging two interfaces puts those interfaces in the same "zone" or "network space."
Standard Bridge Mode
The most common scenario this is used is in bridge mode where the External is bridged to the Internal. This is extremely useful when there is a firewall upstream.
For example, if the firewall is 192.168.1.1, then you can configure External as 192.168.1.2/24 with 192.168.1.1 as the gateway. The internal hosts all have 192.168.1.* addresses and can continue to use 192.168.1.1 as a gateway (192.168.1.2 will also work as a gateway).
It is important to remember that even when bridging NG Firewall routes ALL traffic according to its routing table. This means if you have other subnets besides 192.168.1.* like 192.168.2.*, then you will need to add aliases or routes for them otherwise that traffic will go to the default gateway.
DMZ Bridge
Another common scenario to use bridging is when NG Firewall has a public IP (1.2.3.2 in this example), but you have other public servers with public IPs (1.2.3.*). You could put those servers on the private network and use Port Forward Rules. But lets assume you wanted to keep them configured with public IPs to keep them separate from the internal and avoid any NAT/port forwarding issues.
In this case, you can bridge a "DMZ" interface to your external and it essentially shares the configuration and "zone" with external. This means you can place servers with public IPs on that segment and they can continue to use 1.2.3.1 as a gateway.
Additional Port
You can also just use bridge mode to provide alternate ports to existing interfaces/zones. Be careful, as traffic between the two goes through NG Firewall!
For example, if Interface 2 is configured as 192.168.1.1/24 and Interface 3 is bridged to Interface 2, then they are both effectively 192.168.1.1. Basically Interface 3 becomes an additional port for the Interface 2 network.
This is almost identical to a configuration without Interface 3 where Interface 2 is plugged into a switch with two free ports.
There are some important differences:
- In scenario 1, traffic between Interface 2 and Interface 3 goes through NG Firewall and is routed via NG Firewall's routing table
- In scenario 1, traffic between Interface 2 and Interface 3 goes through NG Firewall and is scanned by the apps (if not bypassed via Bypass Rules)
What "bridged" really means.
In NG Firewall when two interfaces are bridged it means that they are in the same zone or that they both connect to the same network space. As the cardinal rules explain, NG Firewall routes all traffic according to its routing table - even those crossing between two bridged interfaces. This is sometimes called brouting or a brouter - unlike how a traditional layer-2 bridge/switch behaves.
It means that packets coming inside one side of a bridge will NOT necessarily exit the other side of the bridge. It also means that packets destined with a specific route will be routed according to NG Firewall's routing table. All traffic is routed according to NG Firewall's routing table. It also means MAC addresses are not maintained across segments, even if they are bridged together as packets are brouted.
This may cause you to wonder how NG Firewall works in the traditional "Bridge Mode." The answer is simple, for outbound traffic to the internet NG Firewall will route that to its default gateway which was probably where the traffic was headed anyway and definitely where it should go. For inbound traffic NG Firewall knows where each local host on the bridged segment lives and it routes it directly. So inbound and outbound traffic both flow as expected.
Where things get complicated is when networks have more complicated routes and do not configure NG Firewall with those routes. Assume NG Firewall is installed in traditional bridge mode on a 192.168.1.1/24 network. Lets assume the network also has another internal network of 192.168.2.1/24 behind an internal router 192.168.1.100. There is probably already a route on the existing firewall telling it that 192.168.2.* can be reached behind 192.168.1.100. If the user then inserts NG Firewall in bridge mode and configures it as 192.168.1.2, the entire 192.168.1.* network will work but none of the traffic on 192.168.2.* will work. Why? Because NG Firewall routes *all* traffic according to its routing table. The firewall will route 192.168.2.* traffic to 192.168.1.100. When that traffic passes through NG Firewall it will not route it to 192.168.1.100 - it will route it according to its routing table. Since it knows nothing about 192.168.2.* and those addresses aren't local, it will be sent back out to the default gateway. As such the 192.168.2.* network will be completely offline as return traffic from the internet will not reach those hosts. Once a 192.168.2.0/24 route to 192.168.1.100 is added to NG Firewall traffic will flow as expected. The routing table on NG Firewall must reflect the layout of the network.
Another common scenario is bridging two separate networks with one NG Firewall server. Lets look at an example with 4 interfaces: network1External, network1Internal, network2External, network2Internal. network1Internal is bridged to network1External. network2Internal is bridged to network2External. The problem with this scenario is that NG Firewall routes all traffic according to its routing table. If traffic comes in on network2Internal and is bound for the internet it will NOT be sent out network2External just because that's where it was originally headed. It will be routed according to NG Firewall's routing table, which is the default route of NG Firewall - probably network1External's gateway! To setup this scenario one must use WAN Balancer and routes to assure that traffic coming in network2Internal is routed via network2External. This is true whether or not the separate network or separate physical networks or separate VLAN networks.
The key to using bridge mode effectively is understanding how NG Firewall routes traffic. While bridging can often be convenient it can also create headaches for complicated setups.
NAT
NAT or Network Address Translation is the operation of rewriting the source address of packets. Typically this is used so many internal hosts with internal IPs (192.168.*.*, 10.*.*.*, and so on) can share one or several public IPs.
There are 3 ways that NAT is done is NG Firewall:
- If you check NAT traffic exiting this interface (and bridged peers) on any WAN interface configuration.
- If you check NAT traffic coming from this interface (and bridged peers) on any non-WAN interface configuration.
- If you add a NAT Rule
NAT traffic exiting this interface (and bridged peers)
The first option is NAT traffic exiting this interface (and bridged peers). As described in the Interfaces documentation, this option will NAT any traffic exiting this interface and any of its bridged peers. This is enabled by default on WANs.
What this means is that any and all traffic exiting that WAN interface or bridged peers will be NATd to auto which is the current primary address of that WAN interface. Traffic between this interface and any bridged peers will not be NATd. Checking this option also blocks all traffic coming to this WAN that is not to a local process or explicitly forwarded with a Port Forward Rule.
NAT traffic coming from this interface (and bridged peers)
The second option is NAT traffic coming from this interface (and bridged peers), as described in the Interfaces documentation, will NAT any traffic coming from this interface and any of its bridged peers. This is not enabled by default.
What this means is that all traffic from this interfaces will get NATd to auto which is the primary address of which ever interface the traffic it exits. Traffic between this interface and any bridged peers will not be NATd. Checking this option also blocks all traffic to this non-WAN except traffic forwarded with a Port Forward Rule.
When and Where to perform NAT
If there are only two interfaces in NG Firewall the first and second options are identical. When there are multiple internal subnets you will need to configure where you wish to NAT so that you have the desired behavior.
If you wish internal networks to be able to speak with each other (i.e. 192.168.1.100 should be able to reach 192.168.2.100 on a different interface) then you do not want to NAT between those networks.
As such, you should uncheck NAT traffic coming from this interface (and bridged peers) on both LAN interfaces, and check NAT traffic exiting this interface (and bridged peers) on the WAN(s).
If you wish for internal networks to be completely separate such that they can not speak to each other then you want to check NAT traffic coming from this interface (and bridged peers) on the non-WAN interfaces. This means NAT will be performed on all traffic from these LANs and inbound sessions will be blocked unless explicitly forwarded with Port Forward Rules.
NAT Rules
The third option is explicitly configuring exactly what should be NATd to what address with NAT Rules. Be aware, these rules do not also explicitly block any inbound traffic like the two NAT options. NAT rules can be used in conjunction with the two NAT checkboxes and any matched NAT rule will take precedence. Most networks need only one the first two options, but sometimes there are scenarios where a NAT rule is wanted desired such as 1:1 NAT or when you want to guarantee that certain traffic (like SMTP exiting an email server) uses another address other than the primary WAN address.
If no NAT option is enabled (all unchecked and no NAT rules) then NG Firewall will route like a typical router without performing any NAT operation.
Note: The NAT traffic exiting this interface (and bridged peers) option in WAN is equivalent to appending an Auto NAT rule to the end of the NAT Rules matching all traffic with Destination Interface equal to that WAN or any bridged peer but excluding traffic between any bridged peers in that zone. It also includes a forward filter rule to block inbound sessions from this WAN or bridged peers not explicitly port forwarded excluding sessions between any bridged peers in that zone.
Note: The NAT traffic coming from this interface (and bridged peers) option in WAN is equivalent to appending an Auto NAT rule to the end of the NAT Rules matching all traffic with Source Interface equal to that non-WAN or any bridged peer but excluding traffic between any bridged peers in that zone. It also includes a forward filter rule to block inbound sessions to this non-WAN or bridged peers not explicitly port forwarded, excluding sessions between any bridged peers in that zone.
VLANs
VLANs or Virtual LANs are commonly used so that multiple subnets can share the same wire while maintaining complete separation including separate broadcast domains.
IMPORTANT:
The term VLAN is sometimes also used to describe putting multiple untagged (no 802.1q tag) subnets on the same wire. For example, NG Firewall is in bridge mode as 192.168.1.2/24 but there is also a 192.168.2.* on the same wire. If there are no 802.1q tags on the 192.168.2.* traffic - it is NOT a VLAN and new VLAN interfaces should NOT be created on NG Firewall. In this scenario you should use guidance in Installation#Configure Other Subnets to properly configure NG Firewall to handle these subnets. VLAN interfaces will ONLY handle tagged 802.1q packets and all packets sent to a VLAN interface will be tagged with 802.1q tags.
VLANs have several uses. Often you want multiple completely separate internal subnets on a network, but you do not want to run multiple physical ethernet networks through a building. VLANs allow you to run multiple networks on the same physical wire while still guaranteeing they are completely separate and secure. To do this you must have VLAN enabled switches and products through-out the network. VLANs can also be useful if you have limited ethernet ports on NG Firewall and wish to overload a single NIC with two separate purposes. This requires that NIC to be connected to a VLAN enabled switch.
To create a VLAN interface click on the Add Tagged VLAN Interface button at the bottom of the interfaces grid on the Config > Network > Interfaces. This will create a new virtual interface. First, you will need to give this interface a new name, and also select the Parent Interface. The Parent Interface is the physical interface that this VLAN virtual interface exists on. Then you will need to configure an 802.1q Tag which is an integer between 1 and 4094 inclusive. After this you will configure the interface just like any interface.
This new VLAN interface is just like a physical interface in all ways. This means you can configured this VLAN interface exactly like any physical interface. It is completely separate from the physical parent interface. Any packet coming in on the physical parent interface with the 802.1q tag matching the configured value (1-4094) will be considered by NG Firewall to be coming in the VLAN interface. Any packet sent to the virtual VLAN interface will actually be sent on the physical parent interface with the configured 802.1q tag. All untagged packets on the physical parent interface will be processed like normal through the physical parent interface, only 802.1q tagged packets with the matching 802.1q tag will be processed by the VLAN interface.
After configuring NG Firewall with the appropriate tagged VLAN interfaces, you will need to configured some VLAN-enabled managed switch to properly process the packets as desired. For example, here is a document describing how to configure a HP ProCurve switch.
Note: VLAN interfaces are completely separate from their physical parents, however they do share the same physical NIC and as such will be limited by the throughput of the physical NIC. For example, if you have two 100Mbit tagged VLAN WANs on the same physical 100Mbit NIC, then you will still be limited to 100Mbit total on both WANs at any given time.
Example: We want to have two completely separate LANs on our network but we only have one wire or one network card. As such we need a VLAN enabled switch. Configure the internal interface with the IP and configuration from LAN 1. Create a tagged VLAN interface with 802.1q tag 3. Configured the new VLAN interface with the IP and configuration for LAN 2. Now configure your VLAN switch to send VLAN 3 packets to the appropriate ports with LAN 2 hosts. In this scenario we are using the same wire but have two separate LANs with separate broadcasts domains.
Note: If you want to use a single wire and/or network card but you don't care about keeping the two LANs seperate, you don't need VLANs and can just use aliases/routes.
Configuring VLAN on NG Firewall in Bridge Mode
Some users want to configure NG Firewall in bridge mode in the middle of a VLANed network. This is possible, but NOT RECOMMENDED. It is suggested to install NG Firewall as the gateway and terminate VLANs on an addressed VLAN interface. However, if you wish to install NG Firewall as a bridge in the middle of several (V)LANs simultaneously, the following instructions will allow you to establish multiple bridges and then enter the routes to tell NG Firewall that if traffic enters on a specific interface it should exit the bridged peer.
- You will need to create 2 virtual interfaces for each VLAN you want to set up.
- One as a child to the external interface
- One as a child to the internal interface
- To set up the external's VLAN interface
- Click on Create a tagged VLAN interface
- Give the interface a name that's easily identifiable by you
- Set the Parent Interface to External
- Set the 802.1q tag
- Config type must be "Addressed"
- Under IPv4 configuration, assign a unique static IP to the interface.
- Enter the IP address for the VLAN gateway
- Enter DNS servers you would like to use
- To set up the internal's VLAN interface
- Click on Create a tagged VLAN interface
- Give the interface a name that's easily identifiable by you
- Set the Parent Interface to Internal
- Set the same 802.1q tag that you configured on the external VLAN interface
- Config type must be "Bridged"
- Bridge this interface to the external VLAN interface
- Go to WAN Balancer and set the weights to send 100% of network traffic out of your untagged external interface
- Click over to the Route Rules tab and create a new rule
- Source Interface : [Internal VLAN interface]
- Destination WAN : [External VLAN interface]
VRRP
VRRP provides network level redundancy.
Multiple NG Firewalls can be run in parallel in a high availability configuration. In this configuration one NG Firewall will be the "primary" and one or more NG Firewalls will be the "secondary." In the event the primary fails, one of the remaining secondary NG Firewall will take over the primary role such that network traffic continues to flow without interruption.
NG Firewall uses VRRP or Virtual Redundancy Router Protocol to handle the switching between NG Firewall servers. All NG Firewall servers must be on and all configured with a share VRRP Virtual Address. The primary is the only NG Firewall to answer/handle traffic routed to the VRRP Virtual Address. If the primary fails an "election" is held over VRRP and the next-highest-priority secondary will begin handling traffic to the VRRP Virtual Address.
All NG Firewall interfaces must be configured statically, and there must be no bridged interfaces. Parallel NG Firewalls configured as bridges will create a bridge loop!
VRRP Basic Example
A common configuration is running two NG Firewalls to act as the gateway for the internal network. For example, let's assume NG Firewall 1, the primary, has a public IP of 1.2.3.4 and an internal IP of 192.168.1.2. Lets assume NG Firewall 2 has a public IP of 1.2.3.5 and an internal IP of 192.168.1.3. Both are running in "router" mode and doing NAT and acting as a gateway. Note that all IPs must be unique! This configuration requires each NG Firewall to have its own external IP!
Now we configure NG Firewall 1 to have a VRRP Virtual Address of 192.168.1.1 on the Internal interface, and also configure NG Firewall 2 to also have a VRRP Virtual Address of 192.168.1.1 its Internal interface. They both share the same VRRP Virtual Address. Each NG Firewall in the group must have the same VRRP ID. So let's give NG Firewall 1 a VRRP ID of 1 and also give NG Firewall 2 a VRRP ID of 1. We want NG Firewall 1 to be the primary when it's on and working without issues so give it a higher priority of 100. NG Firewall 2 is the secondary so it should be given a lower priority: let's give it a lower priority of 50.
Configure your internal hosts to use the VRRP Virtual Address (192.168.1.1) as the gateway. In this configuration the primary will route all traffic to 192.168.1.1 just like a regular address. Should the primary fail within a few seconds the secondary will become the new primary and start routing traffic.
Note: You should configure the DHCP server to hand out 192.168.1.1 as the default gateway. If NG Firewall is providing DHCP. Configure NG Firewall 1 as the "authoritative" with 192.168.1.1 as the "Gateway Override." Configure NG Firewall 2 the same but as non-authoritative. This way NG Firewall 1 will handle all DHCP unless it is down, in which case NG Firewall 2 will handle DHCP.
VRRP External Example
The above example work great for outbound traffic, but if you have inbound traffic being port forwarded that traffic might fail if the NG Firewall owning that address fails. VRRP can also be used to provide redundancy for inbound traffic. For example, similar to above, let's assume you have NG Firewall 1 with 1.2.3.4 and NG Firewall 2 with 1.2.3.5.
You can configure both with a shared VRRP Virtual Address of 1.2.3.3. Now configure port forwards on both NG Firewall for traffic destined to 1.2.3.3 to the appropriate internal host. Only the primary will handle traffic to 1.2.3.3. If the primary fails the secondary will take over traffic handling for 1.2.3.3 and port forwarding. External hosts will still be able to reach local services should the primary fail.
In this scenario NAT Rules can also be configured if outbound traffic should use the same address regardless of which server is handling the traffic.
VRRP Combined Example
It is also possible to combine VRRP on multiple interfaces. For example, combine the above two examples. VRRP can be used to provide redundancy on both interfaces. VRRP IDs must be unique for each server. For example, the external on both should be VRRP ID 1 and the internal on both should be VRRP ID 2. In this scenario VRRP is "grouped" such that if the server loses its "primary" status on one interface it will also release its primary status on other interfaces.
For example, in the picture above if the Internal interface on NG Firewall 1 is unplugged, then NG Firewall 2 will become the primary and start responding to 192.168.1.1.
NG Firewall 1 will also release its primary status on the external interface so that NG Firewall 2 will also handle 1.2.3.3. This is to avoid any scenarios where NG Firewall 1 is primary the external address and NG Firewall 2 is primary on the internal address.
VRRP FAQs
What kind of problems count as a failure for VRRP purposes?
Most critical hardware issues such as power outages, crashes, or freezes will immediately cause the VRRP broadcast to stop and the secondary will immediately take over. Furthermore, if some common errors are detected in software such as the NIC being unplugged then the VRRP broadcast is stopped.
How can I see which is the VRRP master?
The VRRP status is available in the VRRP settings. The Is VRRP Master? indicator will be green if primary.
How can I test my VRRP configuration?
Simply configure VRRP then unplug one of the VRRP NG Firewall interfaces. The secondary should immediately take over and you should still be able to ping the VRRP Virtual Address.
How quickly does traffic switch?
VRRP acts very quickly in the case of a failure and usually switches in less than a few seconds. However, TCP sessions will be reset as state is lost.
No. There is zero state sharing between NG Firewall. The session tables are separate, so sessions will be reset if the secondary takes over. Furthermore application data is not shared or synchronized between servers. This includes things like host tables, Captive Portal logins, OpenVPN state, IPsec state, email quarantines, Reports, quotas & penalty boxes, Web Filter bypass states, antispam learning, etc.
Can I run VRRP in bridge mode?
No. "Secondary" NG Firewalls are still live, they just do not handle traffic to the VRRP Virtual Address. As such if any bridge loop is created with bridged interfaces between the primary and secondary the network will stop functioning.
