2.7. Creating Layer 2 Topologies¶
2.7.1. What it is¶
A topology is an entry point for network traffic into SSL Orchestrator. A layer 2 topology is created to enable “transparent” traffic to flow into SSL Orchestrator for decryption and service chain processing. In a layer 2 topology, the external VLANs of the F5 BIG-IP do not possess self-IPs, therefore the topology does not participate in routing. Both sides of F5 BIG-IP are in the same routing subnet, with the F5 BIG-P sitting in the physical path between them as a “bump-in-the-wire”. An inbound or outbound layer 2 topology is defined by which VLANs consume the incoming traffic, and by how SSL is handled. In an outbound scenario (internal clients to external resources), the SSL configuration re-issues (forges) server certificates. In an inbound scenario (external clients to internal resources), the SSL configuration contains end-entity server certificates and private keys. You must define inbound and outbound layer 2 topologies separately. There are also a few advantages and disadvantages of a layer 2 topology over layer 3 topologies.
Note
L2 topology modes are made possible by hardware chipsets only available on F5 BIG-IP i58x0 platforms and above, plus VIPRION B2250 and B4450 blades. L2 topologies are not supported in vCMP and VE platform environments.
Advantages of a layer 2 topology
Layer 2 topologies do not require routing changes to insert. They simply require a physical insertion in an existing layer 3 environment.
Disadvantages of a layer 2 topology
Layer 2 topologies do not generally benefit from sub-second failover. In a layer 3 environment, F5 BIG-IP high availability (HA) peers can fail over quickly through shared “floating” IP addresses. As a layer 2 topology has no IP addresses, it cannot directly notify the environment that a failover has happened, thus requires external forces to notice interface state. This is typically accomplished through path discovery health checks (e.g. BGP, OSPF, CDP, STP, etc.), and failover time is dependent on the frequency of those health checks.
Note
While possible to deploy a layer 2 topology with third-party “fail-to-wire” devices, failing to wire would also bypass the security stack. It is always recommended practice to deploy SSL Orchestrator as an HA pair, in lieu of simply bypassing a failed security zone.
Layer 2 topologies do not support existing application or explicit proxy topologies, or any advanced routing features of the F5 BIG-IP.
Use the following table to explore the primary differences between the layer 2 and layer 3 topology modes:
Feature
Layer 3
Layer 2
Transparent forward proxy
Yes
Yes
Explicit forward proxy
Yes
No
Reverse proxy
Yes
Yes
Inline layer 2 security services
Yes
Yes
Inline layer 3 security services
Yes
Yes
Inline HTTP security services
Yes
Yes
ICAP security services
Yes
Yes
TAP security services
Yes
Yes
WAF security service (inbound)
Yes
Yes
SWG security service (outbound)
Yes
Yes
High availability
Yes
Yes
802.3ad LACP
Yes
Yes
802.1q VLAN trunking
Yes
Yes
802.1d Spanning tree
Yes
Yes
IPv6
Yes
Yes
vCMP
Yes
No
Native sub-second HA failover
Yes
No
Note
While layer 2 topologies are fundamentally easier to deploy, layer 3 topologies are more flexible and support more modes of operation. Layer 2 topologies also require additional considerations in the surrounding routing environment to support interface failure detection if SSL Orchestrator is configured as HA peers.
2.7.2. How to build it¶
Layer 2 topologies employ a “virtual-wire” configuration to forward layer 2 headers across an otherwise full-proxy SSL Orchestrator configuration. The topology workflow itself is the same as a corresponding layer 3 forward or reverse proxy topology, except without IP addresses and egress routing assignments.
Before starting the configuration, ensure the following system DB variables are set appropriately. SSL Orchestrator automatically sets many of these variables for an L2 topology configuration, but in the event of failure it might be useful to verify.
Name |
Default |
Required |
Comments |
---|---|---|---|
bcm56xxd.vwire.4kvlans |
disable |
enable |
Allows dynamic creation of VLANs under the virtual wire |
l2.virtualwire.standby.bridging |
disable |
disable |
Enable/disable L2 virtual wire bridging for standby box |
tm.rstcause.pkt |
disable |
enable |
Only for debugging purposes, logs the reset reason from RST packet |
tm.rstcause.log |
disable |
enable |
Only for debugging purposes, sends the reset reason to the LTM log |
vlangroup.forwarding.override |
enable |
disable |
If enabled, VLAN group listeners are given priority over the wildcard forwarding listener 0.0.0.0/0. This must be disabled for vwire mode. |
connection.vlankeyed |
enable |
enable |
If enabled, asymmetrically-routed connections will fail. |
l2.virtualwire.multicast.bridging |
enable |
enable |
Enable/disable L2 virtual wire multicast bridging. |
l2.virtualwire.multicast.stats |
enable |
enable |
Enable/disable collection of L2 virtual wire multicast statistics. |
tm.rejectunmatched |
true |
false |
If set to true, BIG-IP will send a RST on unmatched TCP connections. |
The virtual-wire configuration must be defined before deploying a layer 2 topology. For an HA mode SSL Orchestrator configuration, virtual-wire must be defined from the console.
Virtual-Wire Configuration |
---|
The following commands will build a proper virtual-wire configuration: |
Optional - Create trunk interfaces as required. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.). Enable LACP or other features as needed. To enable LACP, add ‘lacp enabled’ to the end of the following commands. |
tmsh create net trunk internal_trunk interfaces add { <int 1> <int 2> }
tmsh create net trunk external_trunk interfaces add { <int 3> <int 4> }
|
Step 1 - Modify port-forwarding mode for interfaces that are part of the virtual-wire. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
tmsh modify net interface <int 1> port-fwd-mode virtual-wire
tmsh modify net interface <int 2> port-fwd-mode virtual-wire
|
Step 2 - Configure “tag” VLANs on the virtual-wire interfaces with the tag 4096 (“any” VLAN). These VLANs promiscuously bridge all tagged traffic. Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
These will create interfaces for tagged traffic tmsh create net vlan l2wire_vlan_4096_int tag 4096 interfaces add { <int 1> { tag-mode service tagged }}
tmsh create net vlan l2wire_vlan_4096_ext tag 4096 interfaces add { <int 2> { tag-mode service tagged }}
|
Step 3 - Create “notag” VLANs using 4094 as the tag. These VLANs bridge untagged traffic (ex. STP BPDUs). Where “<int>” is specified, replace with the physical interface (ex. 1.1, 1.2, etc.), or trunk. |
tmsh create net vlan l2wire_vlan_4094_int tag 4094 interfaces add { <int 1> }
tmsh create net vlan l2wire_vlan_4094_ext tag 4094 interfaces add { <int 2> }
|
Step 4 - Configure a VLAN group linking the virtual-wire interfaces |
tmsh create net vlan-group l2wire members add { l2wire_vlan_4096_int l2wire_vlan_4096_ext } mode virtual-wire
tmsh create net vlan-group notag members add { l2wire_vlan_4094_int l2wire_vlan_4094_ext } mode virtual-wire
|
Step 5 - Save the configuration |
tmsh save sys config partitions all
|
Note
Only two VLANs can be defined per virtual wire VLAN group, however, the VLAN itself can be built on top of a trunk interface which has multiple physical interfaces that support virtual-wire.
You can have multiple L2 virtual wire configurations on a single F5 BIG-IP. However, L2 and L3 SSL Orchestrator topologies cannot be applied to the same VLANs.
Once defined on a virtual-wire VLAN group, an interface and VLAN can no longer possess a self-IP.
Not all interfaces are eligible to participate in a virtual-wire configuration. To determine which interfaces can be used on your platform, please review: K59323455 (https://support.f5.com/csp/article/K59323455).
You should not define non-TCP and non-UDP protocol listeners when configuring virtual-wire. Non-TCP and non-UDP traffic (like ARP) must flow through the virtual-wire VLAN group bridge. This includes any L2 path discovery protocols (ex. STP, CDP). BIG-IP HA failover in virtual-wire mode requires the upstream/downstream nexthop devices to pass path discovery traffic through the BIG-IP. The path discovery traffic will be blocked at the VLAN group bridge on the standby BIG-IP device.
Not all interfaces on a virtual wire compatible platform (iSeries i5000+) can be used with virtual wire. L2 transparency requires that interfaces supporting L2-wire be mapped to logical ports 0-31 due to the destination port of the HiGig header being 5 bits. To understand which interfaces are mapped to logical ports 0-31, run the following command from the BIG-IP console shell:
guishell -c "select name,PHYSPORT from interface order by PHYSPORT"
Also note that the management port may be assigned to logical port 0, so only ports 1-31 can support virtual wire.
Topology Configuration |
User Input |
---|---|
An SSL Orchestrator topology configuration follows the same workflow path as corresponding layer 3 forward and reverse proxy topologies, except for the following differences. |
|
Topology Properties |
Select either L2 Inbound or L2 Outbound. |
Interception Rules |
VLAN selection is the only option here and must be either the client-facing virtual-wire VLAN, or server-facing virtual-wire VLAN, but not both. |
Egress Settings |
There are no egress settings for an L2 topology. |
Refer to the corresponding layer 3 outbound and reverse proxy inbound topology workflows for additional detail on configuring this topology. |
2.7.3. How it works¶
SSL Orchestrator layer 2 topologies employ a “virtual-wire” configuration to forward layer 2 headers across an otherwise full-proxy SSL Orchestrator configuration. This mechanism requires a hardware chipset only available on F5 BIG-IP i58x0 appliances and above, and not supported in vCMP and VE platforms environments. The virtual-wire performs two key functions.
It creates a layer 2 bridge across the defined interfaces. Any traffic that does not match a topology listener will pass across this bridge. In particular, devices on either side of the F5 BIG-IP will be in the same routing subnet and know each other by their layer 2 (MAC) addresses, as this traffic (ARP, BGP, STP, OSPF, etc.) will flow across this bridge.
An SSL Orchestrator topology will then define a specific traffic pattern, by protocol (TCP, UDP, or non-TCP/non-UDP). Any incoming traffic that matches this pattern will be consumed by the topology listener, which handles that traffic as a full proxy to support dynamic service chaining and access to layer 3 and above security services. Traffic entering the topology listener will have a destination IP address of the remote target resource, and a destination MAC address of its gateway routing device (that it learned via ARP or other routing protocol advertisement). After processing SSL and decrypted flows to the service chain, virtual-wire will then copy the client-side L2 headers to the server-side packets and forward to the next hop. This presents a “virtual” layer 2 mode that allows the SSL Orchestrator to be both a bump-in-the-wire, and still control dynamic traffic flows to layer 3 and above security products.
For additional information on configuring and troubleshooting an L2 vwire deployment, please see the following resource:
2.7.4. Additional Information¶
If Border Gateway Protocol (BGP) must flow through your SSL Orchestrator virtual-wire configuration, note that BGP is a TCP protocol. In some cases, attempting to pass BGP through a service chain can cause issues. The best way to avoid this is to manually create a separate forwarding virtual server to catch the BGP.
BGP Forwarding Virtual Server |
User Input |
---|---|
Type |
FastL4 |
Source |
Enter 0.0.0.0/0 here to allow all BGP traffic to pass through, or filter as required. |
Destination Address/Mask |
Enter 0.0.0.0/0. |
Port |
Enter port 179 for BGP. |
Protocol |
Select TCP. |
VLANs |
Select the appropriate VLAN(s). |
Address Translation |
Set to disabled. |
Port Translation |
Set to disabled. |
Either set a system route or define a gateway pool and apply to the above virtual server.
If Open Shortest Path First (OSPF) must flow through your SSL Orchestrator virtual-wire configuration, you may be required to create a separate forwarding virtual server to specifically handle OSPF. OSPF packets have a TTL value of 1. When traffic through any virtual server (apart for default virtual server _vlangroup) the TTL value will be decremented by 1 (as expected) which makes the TTL change to 0. This results in OSPF packets being dropped in the network. The solution here is to create a virtual server with FastL4 for OSPF and use the option to preserve the TTL. The default for a fastL4 profile is to decrement.
# tmsh list ltm profile fastl4 ospf
ltm profile fastl4 ospf {
app-service none
defaults-from fastL4
ip-ttl-mode preserve
}
# tmsh list ltm virtual
ltm virtual ospf_fastl4 {
creation-time 2021-02-05:20:33:15
destination 0.0.0.0:any
ip-protocol ospf
last-modified-time 2021-02-05:20:37:35
mask 255.255.255.255
profiles {
ospf { }
}
serverssl-use-sni disabled
source 0.0.0.0/0
translate-address disabled
translate-port disabled
vs-index 3
}