Deploying a Security Group in Bridge Mode

Introduction to Bridge Mode

If it is not possible divide the existing network into several networks with different IP addresses, you can configure a Security Group in the Bridge Mode.

A Security Group in Bridge Mode is invisible to Layer 3 traffic.

When traffic arrives at one of the bridge slave interfaces, the Security Group inspects it and passes it to the second bridge slave interface.

Example Topology for Bridge Mode

Item

Description

1

Network, which an administrator needs to divide into two Layer 2 segments.

The Security Group in Bridge Mode connects between these segments.

2

First network segment.

3

Switch that connects the first network segment to one bridged slave interface (4) on the Security Group in Bridge Mode.

4

One bridged slave interface (for example, eth1-05) on the Security Group in Bridge Mode.

5

Security Group in Bridge Mode.

6

Another bridged slave interface (for example, eth1-07) on the Security Group in Bridge Mode.

7

Dedicated Gaia Management Interface (for example, eth1-Mgmt1) on the Security Group.

8

Switch that connects the second network segment to the other bridged slave interface (6) on the Security Group in Bridge Mode.

9

Second network segment.

Supported Software Blades in Bridge Mode

This table lists Software Blades, features, and their support for the Bridge Mode.

Software Blade or Feature

Support of a
Security Gateway
in Bridge Mode

Support of VSX
Virtual Systems
in Bridge Mode

Firewall

Yes

Yes

IPsec VPN

No

No

IPS

Yes

Yes

URL Filtering

Yes

Yes

DLP

Yes

No

Anti-Bot

Yes

Yes

Anti-Virus

Yes (1)

Yes (1)

Application Control

Yes

Yes

HTTPS Inspection

Yes (2)

No

Identity Awareness

Yes (3)

No

Threat Emulation - ThreatCloud emulation

Yes

Yes in Active/Active Bridge Mode

No in Active/Standby Bridge Mode

Threat Emulation - Local emulation

Yes

No in all Bridge Modes

Threat Emulation - Remote emulation

Yes

Yes in Active/Active Bridge Mode

No in Active/Standby Bridge Mode

Mobile Access

No

No

UserCheck

Yes

No

Multi-Portal (Mobile Access Portal, Identity Awareness Captive Portal, Data Loss Prevention Portal, and so on)

Yes

No

QoS

Yes (see sk89581)

No (see sk79700)

HTTP / HTTPS proxy

Yes

No

Security Servers - SMTP, HTTP, FTP, POP3

Yes

No

Client Authentication

Yes

No

User Authentication

Yes

No

Notes:

  1. Does not support the Anti-Virus in Traditional Mode.

  2. HTTPS Inspection in Layer 2 works as Man-in-the-Middle, based on MAC addresses:

    • Client sends a TCP [SYN] packet to the MAC address X.

    • Security Gateway creates a TCP [SYN-ACK] packet and sends it to the MAC address X.

    • Security Gateway in Bridge Mode does not need IP addresses, because CPAS takes the routing and the MAC address from the original packet.

    Note - To be able to perform certificate validation (CRL/OCSP download), Security Gateway needs at least one interface to be assigned with an IP address. Probe bypass can have issues with Bridge Mode. Therefore, we do not recommend Probe bypass in Bridge Mode configuration.

  3. Identity Awareness in Bridge Mode supports only the AD Query authentication.

Limitations in Bridge Mode

You can configure only two slave interfaces in one Bridge interface. You can think of this Bridge interface as a two-port Layer 2 switch. Each port can be a Physical interface, a VLAN interface, or a Bond interface.

These features and deployments are not supported in Bridge Mode:

  • NAT rules (specifically, Firewall kernel in logs shows the traffic as accepted, but Security Gateway does not actually forward it). For more information, see sk106146.

  • Access to Multi-Portal (Mobile Access Portal, Identity Awareness Captive Portal, Data Loss Prevention Portal, and so on) from bridged networks, if the bridge does not have an assigned IP address.

For more information, see sk101371: Bridge Mode on Gaia OS and SecurePlatform OS.