| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
Transparent Mode Usage
The cOS Core Transparent Mode feature allows a Clavister firewall to be placed at a point in a network without any reconfiguration of the network and without hosts being aware of its presence. All cOS Core features can then be used to monitor and manage traffic flowing through that point. cOS Core can allow or deny access to different types of services (for example HTTP) and in specified directions. As long as users are accessing the services permitted, they will not be aware of the firewall's presence.Network security and control can therefore be significantly enhanced with deployment of a Clavister firewall operating in transparent mode, while disturbance to existing users and hosts is minimized.
In certain, less usual circumstances, switch routes can have a network range specified instead of all-nets. This is usually when a network is split between two interfaces but the administrator does not know exactly which users are on which interface.
As explained later, transparent mode can alternatively be configured by enabling it directly on interfaces. This automatically adds the switch routes to the routing table associated with the interface.
Broadcast Packet Forwarding
By default, broadcast packets will not be forwarded with transparent mode. Forwarding must be switched on by enabling the property Forward broadcast packets on switch routes and this must be done for the routes for both the source and destination interface. This is explained further in Section 4.2.7, Broadcast Packet Forwarding.![[Note]](images/note.png) |
Note:IPv6 is not supported in switch routes |
|---|---|
Although IPv6 is supported in normal cOS Core routes, it is not supported in switch routes. This means that IPv6 cannot be used with transparent mode. |
Usage Scenarios
Two examples of transparent mode usage are:Implementing Security Between Users
In a corporate environment, there may be a need to protect the computing resources of different departments from one another. The finance department might require access to only a restricted set of services (HTTP for example) on the sales department's servers whilst the sales department might require access to a similarly restricted set of applications on the finance department's hosts. By deploying a single Clavister firewall between the two department's physical networks, transparent but controlled access can be achieved.
Controlling Internet Access
An organization allows traffic between the external Internet and a range of public IPv4 addresses on an internal network. Transparent mode can control what kind of service is permitted to these IP addresses and in what direction. For instance the only services permitted in such a situation may be HTTP access out to the Internet. This usage is dealt with in greater depth below in Section 4.9.2, Enabling Internet Access.
Comparison with Routing Mode
The Clavister firewall can be regarded as operating in either of two modes:Routing Mode using non-switch routes.
Transparent Mode using switch routes.
With non-switch routes, the firewall acts as a router and routing operates at layer 3 of the OSI model. If the firewall is placed into a network for the first time, or if network topology changes, the routing configuration must therefore be checked and adjusted to ensure that the routing table is consistent with the new layout. Reconfiguration of IP settings may be required for pre-existing routers and protected servers. This works well when comprehensive control over routing is desired.
With switch routes, the Clavister firewall operates in transparent mode and resembles a OSI Layer 2 Switch in that it screens IP packets and forwards them transparently to the correct interface without modifying any of the source or destination information at the IP or Ethernet levels. This is achieved by cOS Core keeping track of the MAC addresses of the connected hosts and cOS Core allows physical Ethernet networks on either side of the firewall to act as though they were a single logical IP network.
Two benefits of transparent mode over conventional routing are:
A user can move from one interface to another in a "plug-n-play" fashion, without changing their IP address (assuming their IP address is fixed). The user can still obtain the same services as before (for example HTTP, FTP) without any need to change routes.
The same network address range can exist on several interfaces.
|
Note: Transparent and Routing Mode can be combined |
|---|---|
|
Transparent mode and routing mode can operate together on a single Clavister firewall. Switch Routes can be defined alongside standard non-switch routes although the two types cannot be combined for the same interface. An interface operates in one mode or the other. It is also possible to create a hybrid case by applying address translation on otherwise transparent traffic. |
How Transparent Mode Functions
In transparent mode, cOS Core allows ARP transactions to pass through the Clavister firewall, and determines from this ARP traffic the relationship between IP addresses, physical addresses and interfaces. cOS Core remembers this address information in order to relay IP packets to the correct receiver. During the ARP transactions, neither of the endpoints will be aware of the firewall.When beginning communication, a host will locate the target host's physical address by broadcasting an ARP request. This request is intercepted by cOS Core and it sets up an internal ARP Transaction State entry and broadcasts the ARP request to all the other switch-route interfaces except the interface the ARP request was received on. If cOS Core receives an ARP reply from the destination within a configurable timeout period, it will relay the reply back to the sender of the request, using the information previously stored in the ARP Transaction State entry.
During the ARP transaction, cOS Core learns the source address information for both ends from the request and reply. cOS Core maintains two tables to store this information: the Content Addressable Memory (CAM) and Layer 3 Cache. The CAM table tracks the MAC addresses available on a given interface and the Layer 3 cache maps an IP address to MAC address and interface. As the Layer 3 Cache is only used for IP traffic, Layer 3 Cache entries are stored as single host entries in the routing table.
For each IP packet that passes through the Clavister firewall, a route lookup for the destination is done. If the route of the packet matches a Switch Route or a Layer 3 Cache entry in the routing table, cOS Core knows that it should handle this packet in a transparent manner. If a destination interface and MAC address is available in the route, cOS Core has the necessary information to forward the packet to the destination. If the route was a Switch Route, no specific information about the destination is available and the firewall will have to discover where the destination is located in the network.
Discovery is done by cOS Core sending out ARP as well as ICMP (ping) requests, acting as the initiating sender of the original IP packet for the destination on the interfaces specified in the Switch Route. If an ARP reply is received, cOS Core will update the CAM table and Layer 3 Cache and forward the packet to the destination.
If the CAM table or the Layer 3 Cache is full, the tables are partially flushed automatically. Using the discovery mechanism of sending ARP and ICMP requests, cOS Core will rediscover destinations that may have been flushed.
Enabling Transparent Mode
To enable cOS Core transparent mode, the following steps are required:The interfaces that are to be transparent can be first collected together into a single Interface Group object. Interfaces in the group should be marked as Security/Transport Equivalent if hosts are to move freely between them. This option is explained further in Section 3.4.10, Interface Groups.
As explained later, this step can be skipped if a group is not needed and switch routes are to be added individually for each interface instead of for the group as a whole.
A Switch Route is now created in the appropriate routing table and the interface group associated with it. Any existing non-switch routes for interfaces in the group should be removed from the routing table.
For the Network parameter in the switch route, specify all-nets or alternatively, specify a network or range of IP addresses that will be transparent between the interfaces (this latter option is discussed further below).
Note that it is possible to instead enable transparent mode directly on the interfaces in the group and this will automatically add switch routes.
Create the appropriate IP rules in the IP rule set to allow the desired traffic to flow between the interfaces operating in transparent mode.
If no restriction at all is to be initially placed on traffic flowing in transparent mode, the following single IP rule could be added but more restrictive IP rules are recommended.
| Action | Src Interface | Src Network | Dest Interface | Dest Network | Service |
|---|---|---|---|---|---|
| Allow | any | all-nets | any | all-nets | all_services |
Restricting the Network Parameter
As cOS Core listens to ARP traffic, it continuously adds single host routes to the routing table as it discovers on which interface IP addresses are located. As the name suggests, single host routes give a route for a single IP address. The number of these routes can therefore become large as connections are made to more and more hosts.A key advantage of specifying a network or a range of IP addresses instead of all-nets for the Network parameter is that the number of routes automatically generated by cOS Core will be significantly smaller. A single host route will only be added if the IP address falls within the network or address specified. Reducing the number of routes added will reduce the processing overhead of route lookups.
Specifying a network or address range is, of course, only possible if the administrator has some knowledge of the network topology and often this may not be the case.
Multiple Switch Routes are Connected Together
The setup steps listed above describe placing all the interfaces into a single interface group object which is associated with a single switch route.An alternative to one switch route is to not use an interface group but instead use an individual switch route for each interface. The end result is the same. All the switch routes defined in a single routing table will be connected together by cOS Core and no matter how interfaces are associated with the switch routes, transparency will exist between them.
For example, if the interfaces if1 to if6 appear in a switch routes in routing table A, the resulting interconnections will be as illustrated below.
Connecting together switch routes in this way only applies, however, if all interfaces are associated with the same routing table. The situation where they are not, is described next.
Creating Separate Transparent Mode Networks
If we now have two routing tables A and B so that interfaces if1, if2 and if3 appear in a switch route in table A and interfaces if4, if5, if6 appear in a switch route in table B, the resulting interconnections will be as illustrated below.
The diagram above illustrates how switch route interconnections for one routing table are completely separate from the switch route interconnections for another routing table. By using different routing tables in this way we can create two separate transparent mode networks.
The routing table used for an interface is decided by the Routing Table Membership parameter for each interface. To implement separate transparent mode networks, interfaces must have their Routing Table Membership reset.
By default, all interfaces have Routing Table Membership set to be all routing tables. Also by default, one main routing table always exists and once an additional routing table has been defined, the Membership for any interface can then be set to be that new table.
If transparent mode is being set up for all hosts and users on a VLAN then the technique described above of using multiple routing tables also applies. A dedicated routing table should be defined for each VLAN ID and switch routes should then be defined in that routing table which refer to the VLAN interfaces. The reason for doing this is to restrict the ARP requests to the interfaces on which the VLAN is defined.To better explain this, let us consider a VLAN vlan5 which is defined on two physical interfaces called if1 and if2. Both physical interfaces have switch routes defined so they operate in transparent mode. Two VLAN interfaces with the same VLAN ID are defined on the two physical interfaces and they are called vlan5_if1 and vlan5_if2.
For the VLAN to operate in transparent mode we create a routing table with the ordering set to only and which contains the following 2 switch routes:
| Network | Interface |
|---|---|
| all-nets | vlan5_if1 |
| all-nets | vlan5_if2 |
Instead of creating individual entries, an interface group could be used in the above routing table.
No other non-switched routes should be in this routing table because traffic that follows such routes will be tagged incorrectly with the VLAN ID.
Finally, we must associate the created routing table with its VLAN interface by using the option to make each VLAN interface a member of a specific routing table.
Enabling Transparent Mode Directly on Interfaces
The recommended way to enable transparent mode is to add switch routes, as described above. An alternative method is to enable transparent mode directly on an interface (a check box for this is provided in the graphical user interfaces). When enabled in this way, default switch routes are automatically added to the routing table for the interface and any corresponding non-switch routes are automatically removed. This method is used in the detailed examples given later.High Availability and Transparent Mode
Switch routes are not synchronized in an HA cluster and therefore true transparent mode cannot be implemented.Instead of switch routes the solution with an HA cluster is to use Proxy ARP to separate two networks. This is described further in Section 4.2.6, Proxy ARP. The key disadvantage with this approach is that first, clients will not be able to roam between cOS Core interfaces, retaining the same IP address. Secondly, and more importantly, their network routes will need to be manually configured for proxy ARP.
In most transparent mode scenarios, the IP address of clients is predefined and fixed and is not dynamically fetched using DHCP. It is a key advantage of using transparent mode that users can plug in anywhere and cOS Core can route traffic correctly after determining their location and IP address from ARP exchanges.However in some transparent mode scenarios, user IP addresses might be allocated by a DHCP server. For example, it may be an ISP's DHCP server that hands out public IPv4 addresses to clients located behind the firewall when it is operating in transparent mode. In this case, cOS Core must be correctly configured as a DHCP relayer to allow the forwarding of DHCP traffic between clients and the DHCP server.
It may also be the case that the exact IP address of the DHCP server is unknown but what is known is the Ethernet interface to which the DHCP server is connected.
To enable DHCP requests to be relayed through the firewall, the property DHCP Passthrough must be enabled on all the interfaces involved with transparent mode. Doing this is described further in Section 3.4.12, Layer 2 Pass Through
![[Important]](images/important.png) |
Important: Transparent mode must be enabled on the interface |
|---|---|
|
For DHCP passthrough to function, transparent mode must also be enabled on the interface so the routes are added automatically. If switch routes are added manually then DHCP passthrough cannot function. |
A common misunderstanding when setting up Transparent Mode is how to correctly set up access to the Internet. Below is a typical scenario where a number of users on an IP network called lannet access the Internet via an ISP's gateway with IP address gw-ip.
The non-switch route usually needed to allow Internet access would be:
| Route type | Interface | Destination | Gateway |
|---|---|---|---|
| Non-switch | if1 | all-nets | gw-ip |
Now suppose the Clavister firewall is to operate in transparent mode between the users and the ISP. The illustration below shows how, using switch routes, the firewall is set up to be transparent between the internal physical Ethernet network (pn2) and the Ethernet network to the ISP's gateway (pn1). The two Ethernet networks are treated as a single logical IP network in Transparent Mode with a common address range (in this example 192.168.10.0/24).
In this situation, any "normal" non-switch all-nets routes in the routing table should be removed and replaced with an all-nets switch route (not doing this is a common mistake during setup). This switch route will allow traffic from the local users on Ethernet network pn2 to find the ISP gateway.
These same users should also configure the Internet gateway on their local computers to be the ISPs gateway address. In non-transparent mode the user's gateway IP would be the firewall's IP address but in transparent mode the ISP's gateway is on the same logical IP network as the users and will therefore be gw-ip.
cOS Core May Also Need Internet Access
The Clavister firewall also needs to find the Internet if it is to perform cOS Core functions such as DNS lookup, Web Content Filtering or Anti-Virus and IDP updating. To allow this, individual "normal" non-switch routes need to be set up in the routing table for each IP address specifying the interface which leads to the ISP and the ISPs gateway IP address.If the IPv4 addresses that need to be reached by cOS Core are 85.12.184.39 and 194.142.215.15 then the complete routing table for the above example would be:
| Route type | Interface | Destination | Gateway |
|---|---|---|---|
| Switch | if1 | all-nets | |
| Switch | if2 | all-nets | |
| Non-switch | if1 | 85.12.184.39 | gw-ip |
| Non-switch | if1 | 194.142.215.15 | gw-ip |
The appropriate IP rules will also need to be added to the IP rule set to allow Internet access through the Clavister firewall.
Grouping IP Addresses
It can be quicker when dealing with many IP addresses to group all the addresses into a single group IP object and then use that object in a single defined route. In the above example, 85.12.184.39 and 194.142.215.15 could be grouped into a single object in this way.Using NAT
NAT should not be enabled for cOS Core in Transparent Mode since, as explained previously, the Clavister firewall is acting like a level 2 switch and address translation is done at the higher IP OSI layer.The other consequence of not using NAT is that IP addresses of users accessing the Internet usually need to be public IPv4 addresses.
If NATing needs to be performed in the example above to hide individual addresses from the Internet, it would have to be done by a device (possibly another Clavister firewall) between the 192.168.10.0/24 network and the Internet. In this case, internal, private IPv4 addresses could be used by the users on Ethernet network pn2.
In the use case illustrated below, a Clavister firewall in transparent mode is placed between an Internet access router and the internal network. The router is used to share the Internet connection with a single public IPv4 address. The internal NATed network behind the firewall is in the 10.0.0.0/24 address space. Clients on the internal network are allowed to access the Internet via the HTTP protocol. The actual setup steps are listed in the example below.
Example 4.21. Setting Up Transparent Mode
In this example, transparent mode is set up with transparent mode enabled on individual interfaces. An interface group is not used.
Command-Line Interface
Configure the wan interface:
Device:/> set Interface Ethernet wan
IP=10.0.0.1
Network=10.0.0.0/24
DefaultGateway=10.0.0.5
AutoSwitchRoute=YesConfigure the lan interface:
Device:/> set Interface Ethernet lan
IP=10.0.0.2
Network=10.0.0.0/24
AutoSwitchRoute=YesAdd the IP rule:
Device:/> add IPRule Action=Allow
SourceInterface=lan
SourceNetwork=10.0.0.0/24
DestinationInterface=any
DestinationNetwork=all-nets
Service=http
Name=http_allowInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Configure the wan interface:
Configure the lan interface:
Configure the rules:
By default, cOS Core transparent mode uses ARP requests and ICMP packets sent on all interfaces except the receiving interface to discover which is the correct interface for sending packets to a given IP address. However, this approach can fail if the remote network equipment (which might be another Clavister firewall) in the transparent mode setup drops this ARP and ICMP traffic because of the way it is configured.
cOS Core provides an alternative method of discovering the correct sending interface which is to send out the initial packet in the traffic flow on all interfaces except the receiving interface. If a reply is received on an interface then cOS Core updates its internal tables so that subsequent packets to that same destination address are automatically sent only on the interface that received a response. This behavior more closely resembles the behavior of a common network switch. This packet flooding feature can be enabled in cOS Core for both Ethernet interfaces and VLAN interfaces.
Packet Flooding Setup
Transparent mode with packet flooding is set up with the following steps:Optionally set up an Interface Group object that contains all the interfaces that are to be transparent. This step is needed if the Security/Transport Equivalent feature of interface groups is required. This feature is explained further in Section 3.4.10, Interface Groups.
Enable transparency on each individual interface and also the associated Host Learning property.
Make sure that the IP rule set allows traffic to flow from the receiving interfaces to any of the interfaces with transparent mode enabled.
The following should be noted about using the packet flooding feature:
The Host Learning feature can only be activated directly on Ethernet or VLAN interfaces after transparent mode is first enabled on those interfaces. Transparent mode should not be configured by directly creating Switch Route objects.
For any single routing table, all the transparent mode enabled interfaces associated with that table should all have the same value set for the Host Learning property. If this is not the case but at least one route has host learning enabled, cOS Core will automatically set the remaining routes to have host learning enabled and issue a warning message that this has been done on activation.
When packet flooding takes place, packets are sent on all other interfaces in a routing table, both Ethernet and VLAN, that have transparent mode enabled. The routing table chosen is the one associated with the receiving interface.
For routing to work correctly, it may be necessary to create a new routing table and make the interfaces involved in a transparent mode network a member of that routing table. By default, all interfaces will be a member of the main routing table.
Packet flooding is subject to the IP rule set. This means that IP rule set entries may need to be created which allow the flood packets to flow from the source interface to all of the potential destination interfaces in the transparent mode network.
Packet Flooding Processing
The following sequence of events takes place with packet flooding:The first packet arrives on a transparent network interface and cOS Core checks its internal tables to see if it already knows which interface it should be sent out on to reach the destination IP.
If the destination interface cannot be found, the routing table associated with the arrival interface is scanned for other interfaces that have transparency and host learning enabled. The packet is simultaneously sent out on all the interfaces found.
The interface that gets a reply to the sent packet is recorded in the internal tables as the interface to use for that destination. All subsequent packets to that same destination are sent out on that same interface.
Example 4.22. Setting Up Transparent Mode With Packet Flooding
This example copies Example 4.21, “Setting Up Transparent Mode” but uses packet flooding to associate interfaces with destination IPs.
Command-Line Interface
Configure the wan interface:
Device:/> set Interface Ethernet wan
IP=10.0.0.1
Network=10.0.0.0/24
DefaultGateway=10.0.0.5
AutoSwitchRoute=Yes
HostLearning=YesConfigure the lan interface:
Device:/> set Interface Ethernet lan
IP=10.0.0.2
Network=10.0.0.0/24
AutoSwitchRoute=Yes
HostLearning=YesAdd the IP rule:
Device:/> add IPRule Action=Allow
SourceInterface=lan
SourceNetwork=10.0.0.0/24
DestinationInterface=any
DestinationNetwork=all-nets
Service=http
Name=http_allowInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Configure the wan interface:
Configure the lan interface:
Configure the rules:
cOS Core includes support for relaying the Bridge Protocol Data Units (BPDUs) across the Clavister firewall. BPDU frames carry Spanning Tree Protocol (STP) messages between layer 2 switches in a network. STP allows the switches to understand the network topology and avoid the occurrences of loops in the switching of packets.
The diagram below illustrates a situation where BPDU messages would occur if the administrator enables the switches to run the STP protocol. Two Clavister firewalls are deployed in transparent mode between the two sides of the network. The switches on either side of the firewall need to communicate and require cOS Core to relay switch BPDU messages in order that packets do not loop between the firewalls.
Implementing BPDU Relaying
The cOS Core BDPU relaying implementation only carries STP messages. These STP messages can be of three types:
cOS Core checks the contents of BDPU messages to make sure the content type is supported. If it is not, the frame is dropped.
Enabling/Disabling BPDU Relaying
BPDU relaying is disabled by default and can be controlled through the advanced setting Relay Spanning-tree BPDUs. Logging of BPDU messages can also be controlled through this setting. When enabled, all incoming STP, RSTP and MSTP BPDU messages are relayed to all transparent interfaces in the same routing table, except the incoming interface.Multi-protocol Label Switching (MPLS) is a standard that allows the attaching of labels to IP packets to provide information about the packet's eventual destination. The router that initially attached the MPLS label is known as the ingress router.
Network nodes that support MPLS can then use this attached information to route packets without needing to perform route lookups and therefore increase processing speed. In addition to overall faster traffic movement, MPLS also makes it easier to manage Quality of Service (QoS).
MPLS is considered to be "multi-protocol" because it works with the Internet Protocol, Asynchronous Transport Mode (ATM) and frame relay network. When considered in reference to the OSI network model, MPLS allows packets to be forwarded at the layer two level rather than at the layer three level and for this reason it is said to operate at the two and a half level.
cOS Core MPLS Support
cOS Core supports MPLS Pass Through. This is relevant in transparent mode scenarios where the MPLS labeled packets are allowed to traverse the firewall. cOS Core can optionally validate the integrity of these MPLS packets and the administrator can change the advanced setting Relay MPLS to specify the specific action to be taken. The possible values for this setting are:Ignore - Verify packets and allow all verified MPLS labeled packets to pass silently. Packets that fail verification are logged.
Log - Verify packets and allow all verified MPLS packets to pass as well as being logged. Packets that fail verification are also logged.
Drop - Silently drop all MPLS packets without verification or logging.
Drop/Log - Drop all MPLS packets without verification and log these drops.
CAM To L3 Cache Dest Learning
Enable this if the firewall should be able to learn the destination for hosts by combining destination address information and information found in the CAM table.Default: Enabled
Decrement TTL
Enable this if the TTL should be decremented each time a packet traverses the firewall in transparent mode.Default: Disabled
Dynamic CAM Size
This setting can be used to manually configure the size of the CAM table. Normally Dynamic is the preferred value to use.Default: Dynamic
CAM Size
If the Dynamic CAM Size setting is not enabled then this is the maximum number of entries in each CAM table.Default: 8192
Dynamic L3C Size
Allocate the L3 Cache Size value dynamically.Default: Enabled
L3 Cache Size
This setting is used to manually configure the size of the Layer 3 Cache. Enabling Dynamic L3C Size is normally preferred.Default: Dynamic
Transparency ATS Expire
Defines the lifetime of an unanswered ARP Transaction State (ATS) entry in seconds. Valid values are 1-60 seconds.Default: 3 seconds
Transparency ATS Size
Defines the maximum total number of ARP Transaction State (ATS) entries. Valid values are 128-65536 entries.Default: 4096
|
Note: Optimal ATS handling |
|---|---|
|
Both Transparency ATS Expire and Transparency ATS Size can be used to adjust the ATS handling to be optimal in different environments. |
Null Enet Sender
Defines what to do when receiving a packet that has the sender hardware (MAC) address in Ethernet header set to null (0000:0000:0000). Options:Default: DropLog
Broadcast Enet Sender
Defines what to do when receiving a packet that has the sender hardware (MAC) address in Ethernet header set to the broadcast Ethernet address (FFFF:FFFF:FFFF). Options:Default: DropLog
Multicast Enet Sender
Defines what to do when receiving a packet that has the sender hardware (MAC) address in Ethernet header set to a multicast Ethernet address. Options:Default: DropLog
Relay Spanning-tree BPDUs
When set to Ignore all incoming STP, RSTP and MSTP BPDUs are relayed to all transparent interfaces in the same routing table, except the incoming interface. Options:Default: Drop
Relay MPLS
When set to Ignore all incoming MPLS packets are relayed in transparent mode. Options:Default: Drop
