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 ideaof 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 192.168.1.66 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 192.168.1.250 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 192.168.1.168.39364 > 192.168.1.250.80: 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. 192.168.10.10) 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 networkinterface 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.
F5 BIG IP clone pooling
Hello We want to deliver to analyzer machine the bi-directional traffic from BigIP F5 via clone pools. But I think it seems like to setup incorrectly because I can see the real client ip address is what reaches the virtual server for request and can not see F5 self ip for response I attacted pcap file Is not need to see F5 self-ip ? https://www.cloudshark.org/captures/88b59721b74f There are only 23 Previous Segments Missing from the tcpdump. There are some malformed https packets as well, but overall your incoming traffic looks acceptable. The moral of the story we want to replicate server-side traffic (after address translation) to the clone pool member. What should I do ? Thanks in advance Kind Regards,
Clone Pool vs Interface Mirroring
Hi Guys, I am studying for the 301a exam, and I got to a part of clone pools and interface mirroring. I am trying to understanding the actual difference and advantages on using any of this features. For what I read both features have the same purposes; however, Interface Mirroring has too many caveats and disadvantages as opposed of clone pools. I've found the following F5 SOL that explains both features, but I am still not 100% clear on those. Configuring the BIG-IP system to send traffic to an intrusion detection system (11.x) https://support.f5.com/kb/en-us/solutions/public/13000/300/sol13392.html Can you guys help me to clarify it? Thanks.
