Implementing SSL Orchestrator - L2 Service Configuration (Palo Alto)
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on configuring a 3rd party, inline Layer 2 security device and everything you need to know about it. This article covers the configuration of a Palo Alto NGFW running PAN-OS version 9.0.3. Please forgive me for using SSL and TLS interchangeably in this article. The simplest Palo Alto deployment is in Layer 2, or Virtual Wire mode.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. From the Palo Alto UI go to the Network tab > Interfaces. Click the name (ethernet1/X) of the interface you wish to configure. Set the Interface Type to Virtual Wire and the Security Zone to trust.Click OK. Do the same for the next interface. Click the name of one of the interfaces configured previously.Click Virtual Wire > New Virtual Wire. Give it a name.Select the 2 interfaces configured previously.Click OK and OK. You will need to Commit the changes for them to take effect. Note: setting the Security Zone to trust is needed for the F5 Health Monitors to work. Summary In this article you learned how to configure a Palo Alto NGFW in Layer 2 mode. Configuration of Palo Alto NGFW can be downloaded fromherefrom GitLab. Next Steps Contact Palo Alto Networks if you need additional assistance with their products. Click Next to proceed to the next article in the series.
Load-Balancing Client/Server on same subnet
Hi all, I’m working on a customer's issue where the VIP, pool members and clients are all on the same subnet (lets say 10.1.1.0/24) and no SNAT on the VIP. I'm seeing an issue related to ARP that only affects one of the 6 servers. All servers are Dell. Client – 10.1.1.12 VIP – 10.1.1.4:25 Member Servers 1-6 – 10.1.1.5-19:25 I would expect the flow to go from Client to VIP to Member Server directly back to the client and break communications, but 5 out of 6 servers actually go right back through the F5 and work fine. If you look at the ARP cache on these boxes, it only has one or two entries pointing to the F5 - none for the client (10.1.1.12). The server that does not work does have an ARP entry for the client IP and the return traffic goes directly back to the client. No static ARP setup on the working servers as far as I can tell. Nothing in the F5 configs about mac spoofing/masquerading. Creating a static arp entry for the client IP to point to the F5 mac on the server that's not working fixes this server. I'm a little confused on any of the servers are working at all. Any insight into how this is supposed to work without SNAT would be extremely helpful. Thanks in advance! ChintanImplementing SSL Orchestrator - L2 Service Configuration (Firepower)
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on configuring a 3rd party, inline Layer 2 security device and everything you need to know about it. This article covers the configuration of Cisco Firepower running version 6.4. Please forgive me for using SSL and TLS interchangeably in this article. A common Firepower deployment mode is in Layer 2, using “Inline Sets”.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. Firepower Management Center must be used when configuring this because Firepower Device Manager does not support the configuration of Inline Sets. From the Firepower Management Center click Devices.It should look like the following. Double click the Name of the Firepower device you want to configure. This should bring you to the Interfaces screen.We will be configuring Ethernet 1/3 and 1/4.Click the pencil on the right to edit Ethernet 1/3. Enable the interface and give it a name, “frombigip11” in this example.Click OK. Repeat these steps for Ethernet 1/4, giving it a unique name too. It should look like the following. Notes: when configuring for High Availability repeat these steps for another Ethernet pair, like 1/5 and 1/6. Go to the Inline Sets tab and click Add Inline Set. Give it a Name, inlineset11 in this example.The Interface Pair should appear on the left.Select it and click Add to move it to the right.Then click OK. Notes: when configuring for High Availability repeat these steps for the other Interface Pair. Click Save and then Deploy. Check the box next to the Firepower device you configured and click Deploy.This process may take several minutes. When done, the screen should look like this. Summary In this article you learned how to configure Cisco Firepower in Layer 2 mode. Configuration of Cisco Firepower can be downloaded from here in GitLab. Next Steps Click Next to proceed to the next article in the series. Contact Cisco if you need additional assistance with their products.
MAC Masquerading for VIPs on VLANs on the same Layer2 Network
Hello Guys, we've got a customer with a grown and old network design which causes some headache and i am evaluating possible solutions. During a manually triggered failover for a hotfix installation some of the 180 VS didn't accept traffic. I guess the switch thought that the sudden amount of GARPs might be an attack and dropped some advertisements. After around 15min everything was working fine again. So to prevent something like this in the future i had the idea of using mac masquerading on the traffic group, but i am uncertain on the possible pro and cons. The BIG-IP has two vlans configured, internal and external. Each vlan is on a dedicated physical interface (1.1 and 1.3) and each is untagged, so basicly both vlans are on the same layer2 network. What will happens once mac masquerading would be enabled? From my understanding each IP associated with an VS, each floating self ip will have the same MAC address in the traffic group, which seems like an bad idea for me in the given scenario. I'd appreciate your input on this. Best regards DavidPacket Analysis with Scapy and tcpdump: Checking Compatibility with F5 SSL Orchestrator
In this guide I want to demonstrate how you can use Scapy (https://scapy.net/) and tcpdump for reproducing and troubleshooting layer 2 issues with F5 BIG-IP devices. Just in case you get into a finger-pointing situation... Starting situation This is a quite recent story from the trenches: My customer uses a Bypass Tap to forward or mirror data traffic to inline tools such as IDS/IPS, WAF or threat intelligence systems. This ByPass Tap offers a feature called Network Failsafe (also known as Fail-to-Wire). This is a fault tolerance feature that protects the flow of data in the event of a power outage and/or system failure. It allows traffic to be rerouted while the inline tools (IDS/IPS, WAF or threat intelligence systems) are shutting down, restarting, or unexpectedly losing power (see red line namedFallbackin the picture below). Since the ByPass Tap itself does not have support for SSL decryption and re-encryption, an F5 BIG-IP SSL Orchestrator shall be introduced as an inline tool in a Layer 2 inbound topology. Tools directly connected to the Bypass Tap will be connected to the SSL Orchestrator for better visibility. To check the status of the inline tools, the Bypass Tap sends health checks through the inline tools. What is sent on one interface must be seen on the other interface and vice versa. So if all is OK (health check is green), traffic will be forwarded to the SSL Orchestrator, decrypted and sent to the IDS/IPS and the TAP, and then re-encrypted and sent back to the Bypass Tap. If the Bypass Tap detects that the SSL Orchestrator is in a failure state, it will just forward the traffic to the switch. This is the traffic flow of the health checks: Target topology This results in the following topology: Problem description During commissioning of the new topology, it turned out that the health check packets are not forwarded through the vWire configured on the BIG-IP. A packet analysis with Wireshark revealed that the manufacturer uses ARP-like packets with opcode 512 (HEX 02 00). This opcode is not defined in the RFC that describes ARP (https://datatracker.ietf.org/doc/html/rfc826), the RFC only describes the opcodes Request (1 or HEX 00 01) and Reply (2 or HEX 00 02). NOTE:Don't get confused that you see ARP packets on port 1.1 and 1.2. They are not passing through, the Bypass Tap is just send those packets from both sides of the vWire, as explained above. The source MAC on port 1.1 and 1.2 are different. Since the Bypass Tap is located right behind the customer's edge firewall, lengthy and time-consuming tests on the live system are not an option, since it would result in a massive service interruption. Therefore, a BIG-IP i5800 (the same model as the customer's) was set up as SSL Orchestrator and a vWire configuration was build in my employers lab. The vWire configuration can be found in this guide (https://clouddocs.f5.com/sslo-deployment-guide/chapter2/page2.7.html). INFO:For those not familiar with vWire: "Virtual wire … creates a layer 2 bridge across the defined interfaces. Any traffic that does not match a topology listener will pass across this bridge." Lab Topology The following topology was used for the lab: I build a vWire configuration on the SSL Orchestrator, as in the customer's environment. A Linux system with Scapy installed was connected to Interface 1.1. With Scapy TCP, UDP and ARP packets can be crafted or sent like a replay from a Wireshark capture. Interface 1.3 was connected to another Linux system that should receive the ARP packets. All tcpdumps were captured on the F5 and analyzed on the admin system (not plotted). Validating vWire Configuration To check the functionality of the F5 and the vWire configuration, two tests were performed. A replay of the Healthcheck packets from the Bypass Tap and a test with RFC-compliant ARP requests. Use Scapy to resend the faulty packets First, I used Wireshark to extract a single packet from packet analysis we took in the customer environment and saved it to a pcap file. I replayed this pcap file to the F5 with Scapy. The sendp() function will work at layer 2, it requires the parametersrdpcap(location of the pcap file for replay) andiface(which interface it shall use for sending). webserverdude@tux480:~$ sudo scapy -H WARNING: IPython not available. Using standard Python shell instead. AutoCompletion, History are disabled. Welcome to Scapy (2.5.0) >>> sendp(rdpcap("/home/webserverdude/cusomter-case/bad-example.pcap"),iface="enp0s31f6") . Sent 1 packets. This test confirmed the behavior that was observed in the customer's environment. The F5 BIG-IP does not forward this packet. Use PING and Scapy to send RFC-compliant ARP packets To create RFC-compliant ARP requests, I first sent an ARP request (opcode 1) through the vWire via PING command. As expected, this was sent through the vWire. To ensure that this also works with Scapy, I also resent this packet with Scapy. >>> sendp(rdpcap("/home/webserverdude/cusomter-case/good-example.pcap"),iface="enp0s31f6") . Sent 1 packets. In the Wireshark analysis it can be seen that this packet is incoming on port 1.1 and then forwarded to port 1.3 through the vWire. Solving the issue with the help of the vendor It became evident that the BIG-IP was dropping ARP packets that failed to meet RFC compliance, rendering the Bypass Tap from this particular vendor seemingly incompatible with the BIG-IP. Following my analysis, the vendor was able to develop and provide a new firmware release addressing this issue. To verify that the issue was resolved in this firmware release, my customer's setup, the exact same model of the Bypass Tap and a BIG-IP i5800, were deployed in my lab, where the new firmware underwent thorough testing. With this approach I could test the functionality and compatibility of the systems under controlled conditions. In this Wireshark analysis it can be seen that the Healthcheck packets are incoming on port 1.1 and then forwarded to port 1.3 through the vWire (marked in green) and also the other way round, coming in on port 1.3 and then forwarded to port 1.1 (marked in pink). Also now you can see that the packet is a proper gratuitous ARP reply (https://wiki.wireshark.org/Gratuitous_ARP). Because the Healthcheck packets were not longer dropped by the BIG-IP, but were forwarded through the vWire the Bypass Tap subsequently marked the BIG-IP as healthy and available. The new firmware resolved the issue. Consequently, my customer could confidently proceed with this project, free from the constraints imposed by the compatibility issue.
