Clone Pool Across L3

Starting in TMOS 13.1 you can now perform a “remote” tcpdump using a GRE tunnel.  We can use the same idea of how the "remote" tcpdump feature works (send raw IP packets over GRE) to enable the F5 BIG-IP  “clone pool” feature to send a copy of network traffic over a L3 (routed) connection.

On F5 BIG-IP you can use the “clone pool” feature to copy traffic to an IDS and/or network monitoring device. The BIG-IP must be L2 adjacent (on the same subnet) as the target device when using this feature. It is possible to use a network tunnel (GRE/VXLAN) to leverage this feature across an L3 connection (connect to a different network via a routed network).

Remote tcpdump

On the BIG-IP when you run tcpdump -h on version 13.1 you’ll see a new command-line option for sending traffic to a remote host.

# tcpdump -h
                [ --remote-dest <ip>|<hostname> ]

Enter the desired remote IP of the host where you want to collect the traffic.

tcpdump -i 0.0 -s 0 --remote-dest port 80

Then you’ll need to configure a device to capture the traffic (the following examples is from a CentOS 7 device).

$ ip link add tun0 type gretap local any remote ttl 255
$ sudo ip link set tun0 up

Once you have created the tunnel you should be able to run tcpdump on the remote host and capture the output.

tcpdump -i tun0 -nnnn
07:11:37.989611 IP > Flags [P.], seq 1:79, ack 1, win 457, options [nop,nop,TS val 48441361 ecr 1062054207], length 78: HTTP: HEAD / HTTP/1.1

Full Proxy

The BIG-IP is a “Full Proxy” device, a separate clientside and serverside TCP connection is created on each connection. In the following illustration we are showing that we have separate traffic flows from the client to BIG-IP; and from the BIG-IP to the app. For example; this enables the BIG-IP to perform SSL/TLS encryption from the client to the BIG-IP using ECC TLS ciphers that can not be passively monitored, then between the BIG-IP and the app, utilize RSA TLS ciphers (using a shared RSA key) or no encryption between the BIG-IP and the app. Passive security devices are unable to monitor traffic that is using strong encryption and must rely on a shared RSA key, traffic that is decrypted, or take a performance hit of having to decrypt/re-encrypt traffic.

How does clone pool work?

The clone pool feature works by making a copy of network packets that are received on the BIG-IP and sending a copy of the traffic with the destination MAC (hardware address) changed. The following image is an example of two packets with only the destination MAC address modified.  The first packet was the original packet and the second packet the "cloned" traffic.

When you configure a clone pool on the BIG-IP you specify the L3 address (i.e. of the target device that is L2 adjacent to the BIG-IP, but that address is only used to obtain the MAC address from the ARP entries that are on the BIG-IP. If you try to configure an address that is not L2 adjacent it will not work.

Clone Pool Across L3

To enable a clone pool across an L3 connection (i.e. from one AWS VPC to another) you need to create a Network Tunnel on the BIG-IP. An example of using GRE would be to first create a GRE profile of type “Transparent-Ethernet-Bridging”. After setting up the associated Tunnel and Self IP you would need to create a static ARP entry and corresponding FDB entry.

Once you have created those FDB entries you can update your clone pool to point to the IP address that you associated with your static ARP entry. This adheres to the guidance in K17567 that an L2 FDB entry is required (in this case statically created).

The following is an example of a Wireshark capture where you can see the packets encapsulated by GRE. Similar to the earlier tcpdump example, you would want to create a virtual network interface to capture the packets without the encapsulation.

L2 isn’t always L2

Increasingly you cannot rely on having an L2 connection; whether it is the sprawl of an on-premises datacenter or the peculiarities of public cloud providers SDN networks. BIG-IP has tools that can help you circumvent these issues and provide greater visibility of your network.



Published May 10, 2018
Version 1.0

Was this article helpful?

No CommentsBe the first to comment