Networking

Building a Minimal HAProxy Load Balancer on Rocky Linux 10

A practical guide to building a small, hardened HAProxy load balancer on Rocky Linux 10 using Layer 4 TCP load balancing, TLS passthrough, multiple frontends and a separate DMZ interface. HAProxy is one of those tools that can look intimidating when you first open the configuration file. In reality, a basic Layer 4 load balancer can be surprisingly small and lightweight. I recently built a small, production-style HAProxy load balancer on a minimal Rocky Linux 10 installation. The server fronts several applications, including an application hosted in a DMZ, and passes HTTPS traffic through to the backend servers without terminating TLS. That last point is important. The HAProxy server doesn’t hold any certificates and doesn’t decrypt the application traffic. It simply accepts the TCP connection, selects a healthy backend and forwards the encrypted connection to it. TLS remains between the client and the application server. This guide documents the build from start to finish, including the networking, HAProxy configuration, SELinux, firewalld, logging, Active Directory integration, hardening, testing and — perhaps most importantly — the problems I encountered along the way. Everything in this article uses deliberately generic hostnames, IP addresses and account names. Replace them with values appropriate for your own environment. What we’re building The finished system is a single Rocky Linux 10 VM running HAProxy. Each application has its own frontend IP address and its own backend pool. HAProxy operates in TCP mode, so the encrypted HTTPS traffic is passed through without HAProxy terminating TLS. The certificates remain installed on the application servers. The basic design looks like this: The three application pools are: Pool Frontend Backends Production app 10.0.3.10:443 app-prod-01 (10.0.0.108), app-prod-02 (10.0.0.109) Test / API 10.0.3.11:443 app-test-01 (10.0.0.115), app-test-02 (10.0.0.124) DMZ web 10.0.16.251:443 web-dmz-01 (10.0.16.30), web-dmz-02 (10.0.16.31) Placeholder values Throughout this article I’ll use the following example values: Item Value Load balancer hostname lb01.corp.example.com Local fallback account localadmin AD domain corp.example.com Internal network 10.0.0.0/22 Internal gateway 10.0.3.254 DNS/NTP 10.0.0.11, 10.0.0.10 DMZ network 10.0.16.0/24 Admin workstation subnet 10.0.52.0/24 These are examples only. Don’t copy them into a production environment without adapting them to your own network. Why use TLS passthrough? There are two common ways of putting HAProxy in front of an HTTPS application. The first is TLS termination. HAProxy receives the HTTPS connection, decrypts it and then establishes another connection to the backend. The second is TLS passthrough. With passthrough, HAProxy doesn’t need to know anything about the application’s certificates. It operates at Layer 4 and simply proxies the TCP connection. For this particular deployment, TLS passthrough made sense for several reasons. No certificates on the load balancer The certificates remain on the application servers. That means there is another machine that doesn’t need certificate renewal, private-key protection or certificate deployment. Very low resource requirements HAProxy isn’t performing TLS encryption and decryption for client connections. It’s primarily moving TCP traffic between sockets. This makes it possible to run the load balancer on a very small VM. The downside: source IP visibility There is an important trade-off. From the backend server’s perspective, the TCP connection originates from the HAProxy server rather than directly from the client. HAProxy knows the original client address and can record it in its own logs, but the backend application won’t automatically see the client’s real source IP. If the backend needs that information, there are alternatives such as the PROXY protocol, provided the backend supports it, or terminating TLS on HAProxy instead. VM sizing The VM I used was deliberately small: For this type of workload, there’s little benefit in throwing a large amount of hardware at HAProxy. In my testing, HAProxy itself used only around 13 MB of RAM. Obviously, real resource requirements depend on connection counts, traffic levels, logging and configuration. Once you’re dealing with very large numbers of concurrent connections, memory and file descriptors become increasingly important, while network throughput can become the limiting factor. For this type of deployment, however, adding a second load balancer for availability is much more useful than simply making the first VM larger. One important virtualisation consideration Rocky Linux 10 and other RHEL 10-based distributions have newer x86-64 CPU requirements than some older Linux releases. If you’re installing the VM on an older hypervisor or with a deliberately old virtual CPU model, the installer may complain about unsupported CPU features. If that happens, expose a newer CPU model to the VM. On VMware, using the host CPU where appropriate is one option. Step 1 — Install Rocky Linux 10 Install Rocky Linux 10 using the Minimal Install profile. The goal here is to keep the server small. There is no reason to install a graphical desktop or a collection of applications that the load balancer doesn’t need. Once the operating system is installed, install the packages required for HAProxy and administration: If you’re not running VMware, open-vm-tools isn’t required. Enable the services: Check the HAProxy version: The build documented here used HAProxy 3.0.5 from AppStream. Your version may differ depending on the Rocky Linux repositories available at the time you build the server. Step 2 — Configure the network This server has two network interfaces: The internal interface carries the normal server traffic and hosts the production and test frontend addresses. The DMZ interface carries the DMZ frontend. The important thing here is that the DMZ interface must not become a second default route. Internal interface In this example, ens33 has two IP addresses: Configure the NetworkManager connection: Check that both addresses are actually present: Check the address before using it Before assigning an additional address to a server, make sure another device isn’t already using it. For example: No response doesn’t guarantee an address is unused, but it is a useful first check. Also check your DHCP scopes and IP address management system. An address that doesn’t answer an ARP request today can still be part of a DHCP scope and become a problem later. Configure the DMZ interface The second interface in this example is ens35. The DMZ network is:

Building a Minimal HAProxy Load Balancer on Rocky Linux 10 Read More »

Zyxel NWA50BE PRO Review: Upgrading from Cisco 240AC to Wi-Fi 7

After several years of running a three-pack of Cisco Business CBW240AC 802.11ac access points, I decided it was time for an upgrade. The Cisco 240ACs had served me well. They were reliable, offered good coverage throughout the house and, for their generation, delivered a solid wireless experience. However, wireless technology has moved on considerably since I installed them. My old Cisco access points were based on Wi-Fi 5 (802.11ac), whereas my replacement is the Zyxel NWA50BE PRO, a Wi-Fi 7 access point capable of up to BE6500 / 6.5Gbps of aggregate wireless throughput and equipped with a 2.5GbE Ethernet interface. Zyxel NWA50BE Pro Wi-Fi 7 Access Point This is the access point I purchased and installed as part of my upgrade from the Cisco 240AC to Wi-Fi 7. If you’re interested in the NWA50BE Pro, you can check the current price and availability on Amazon UK. Check Price on Amazon UK Affiliate Disclosure: This post contains Amazon affiliate links. If you purchase a product through one of these links, I may earn a small commission at no additional cost to you. I only recommend products that I have personally used or believe are worth considering. But there was another reason this particular upgrade was interesting for me. Stepping outside my comfort zone As an Infrastructure Engineering professional, I’ve spent much of my career working with enterprise networking and infrastructure products. Cisco, HPE, Aruba and other established enterprise vendors are the names I’m familiar with and, more importantly, the platforms I’ve trusted. So when I started looking for a replacement for my Cisco access points, moving to Zyxel wasn’t an obvious decision for me. I’ll be honest — I was nervous about it. Zyxel is a brand I’d obviously come across before, but it wasn’t a vendor I had personally relied on in the same way I had relied on Cisco and HPE in professional environments. I therefore spent quite a bit of time researching the NWA50BE PRO before making the decision. I looked at the specifications, management platform, firmware support, security features, VLAN capabilities, PoE requirements, cloud management and, importantly, what the real-world experience was like for people actually using the hardware. I also wanted to make sure that it would integrate properly with the network architecture I already had at home. That meant considering how it would work alongside my pfSense firewall, my network segmentation, multiple SSIDs and existing PoE switching infrastructure. There was a certain amount of hesitation before pressing the order button. Would it feel like a step backwards coming from Cisco? Would the management platform be good enough? Would the firmware and support be there? Would it actually perform as advertised? These were all questions I had before making the switch. As it turned out, I needn’t have worried. The Zyxel NWA50BE PRO has genuinely surprised me. In fact, after installing and configuring the three access points, I was amazed by how capable the product is. The hardware feels well thought out, the management experience is straightforward and the performance has been excellent. Most importantly, it doesn’t feel like I compromised by moving away from the enterprise vendors I’m accustomed to using. If anything, the experience has made me reconsider where Zyxel fits into the networking market. My Home Network Setup Before looking at the access points themselves, it’s worth explaining how I’ve built my home network. I’m a big believer in keeping the network properly segmented, even at home. Rather than putting every device onto a single flat network, I’m using my own custom pfSense firewall as the core of the network. The wireless network is separated into two distinct environments: These are presented to wireless clients using two separate SSIDs. My wireless setup SSID 1 – Trusted My primary wireless network for trusted devices. SSID 2 – Guest A separate guest network with restricted access to my trusted network. The Zyxel access points are therefore not simply providing wireless connectivity. They are sitting within a properly segmented network architecture, with pfSense handling the routing, firewalling and network separation. This is one of the reasons I particularly like using business-oriented networking equipment at home. It gives me the flexibility to build the network in the way I want rather than relying entirely on whatever functionality happens to be built into a consumer router. What You Need for a Similar Home Network Setup If you’re considering building something similar to my home network, here’s a rough idea of the equipment I’m using — or, more accurately, the type of equipment you would need. It’s important to point out that my own hardware has been in use for several years, and some of the exact models I have are no longer readily available. Rather than recommending obsolete hardware, I’ve included links to current alternatives that are similar in terms of functionality and capability. I’ve also deliberately gone for equipment that sits towards the higher end of what you might consider for a home network. You absolutely don’t need to spend this much to get good Wi-Fi at home. There are plenty of cheaper alternatives available, particularly if you don’t need VLANs, multiple SSIDs, PoE or advanced firewall functionality. However, if you’re interested in building a network similar to mine, these are the types of components I’d look at. 🛜 Wi-Fi Access Points The most important part of my upgrade is the three Zyxel NWA50BE PRO Wi-Fi 7 access points. I’m using three APs to provide coverage throughout my home, with the APs connected back to my wired network using Ethernet and powered via PoE. Zyxel NWA50BE PRO BE6500 Wi-Fi 7 Access Point Check Price on Amazon UK As an Amazon Associate, I earn from qualifying purchases. The three APs are configured to provide both my trusted and guest SSIDs, with the underlying network segmentation handled by pfSense. 🔥 Firewall / Router For the firewall, I’m using my own custom pfSense installation. This is probably the component that makes my setup more advanced than a typical home

Zyxel NWA50BE PRO Review: Upgrading from Cisco 240AC to Wi-Fi 7 Read More »

Alcatel OmniSwitch Useful CLI Commands: Practical Guide for Network Administrators

If you work with Alcatel OmniSwitch switches, sooner or later you’ll need to drop into the command line to troubleshoot a port, configure a VLAN, check a stack, manage PoE or investigate a network problem. I’ve put together this list of the Alcatel OmniSwitch CLI commands I find most useful, based on working with OmniSwitch equipment in real-world environments. The commands in this guide have been tested on Alcatel OmniSwitch 6400 and 6850 switches. They may also work on other OmniSwitch models, but command availability and syntax can vary depending on the switch model and AOS version. Important: Always check the command against your particular OmniSwitch model and AOS version before using it on a production switch. Some commands in this guide can be disruptive or destructive. Alcatel OmniSwitch CLI Basics OmniSwitch uses a command-line interface that is slightly different from Cisco IOS, so if you’re more familiar with Cisco switches, some of the syntax may look unfamiliar initially. One of the useful things about OmniSwitch CLI is that commands are generally quite descriptive. Once you become familiar with the structure, day-to-day configuration and troubleshooting becomes relatively straightforward. This guide covers: 1. Reset an OmniSwitch to Factory Defaults Use this with extreme caution. If you need to completely reset an OmniSwitch, the configuration files can be removed from the working and certified directories before rebooting the switch. The switch will reboot and come back without the previous configuration. After the reboot, you can verify that a new configuration has been created with: or: ⚠️ Important This is a destructive operation. Make sure you have a backup of the configuration before doing this. I would strongly recommend confirming that you’re connected to the correct switch before running the commands, particularly when working remotely. 2. Save the Switch Configuration One thing worth understanding with OmniSwitch is the distinction between the Working and Certified configurations. To save the current working configuration: To copy the working configuration to the certified configuration: For a stack containing multiple switches, you can synchronise the configuration across the slots: You can then check the current configuration and synchronisation state with: A healthy switch should show something similar to: Why this matters Saving the configuration to the working configuration isn’t necessarily the same thing as having a certified configuration ready for the next reboot. For production switches, I recommend checking show running-directory after making significant configuration changes. 3. Change the Switch Name Giving switches meaningful names makes life considerably easier when you’re managing multiple devices. For example: Replace Switch1 with whatever naming convention you use. For example: This changes both the system name and the CLI prompt. 4. Configure System Location and Contact Information You can also configure basic information describing where the switch is located and who is responsible for it. Check the configuration with: This is particularly useful in larger environments where a switch may be physically located somewhere different from the person administering it. 5. Configure DNS and NTP Configure a DNS server with: Configure the DNS domain: Configure an NTP server: Enable the NTP client: For production networks, accurate time is particularly important for troubleshooting and log correlation. If you’re investigating an issue across switches, firewalls and servers, having every device using the same time source makes a huge difference. 6. Check System and Hardware Information These are some of the first commands I use when connecting to an unfamiliar OmniSwitch. General system information Chassis information Stack topology CPU health Memory health These commands are particularly useful when troubleshooting performance or unexpected behaviour. 7. VLAN Configuration Create a VLAN To create VLAN 10 and give it a name: This creates VLAN 10 with the description Guest. Delete a VLAN To remove VLAN 10: Be careful: removing a VLAN can immediately affect any ports, interfaces or services using it. Configure an Access/Untagged Port To assign ports 1 through 24 on slot 1 to VLAN 10: This makes those ports untagged/default members of VLAN 10. For example, if VLAN 10 is your guest network, this could be used to place a group of access ports into that VLAN. Configure a Tagged Port To add port 1 on slot 1 to VLAN 10 as an 802.1Q tagged member: This is useful for trunk/uplink-style connections where multiple VLANs need to traverse the same physical interface. Remove VLAN Membership To remove the default VLAN membership: To remove tagged membership: Check a VLAN To display the configuration of VLAN 10: To see the ports associated with the VLAN: These are useful commands when troubleshooting VLAN-related connectivity problems. 8. Interface and Port Configuration Show Port Status To see the status of the switch ports: This is one of the first commands I’d use when troubleshooting a device that cannot connect to the network. Show Detailed Port Information This provides more detailed information about the interfaces. Check a Specific Port OmniSwitch identifies interfaces using a slot/port format. For example: This displays information for port 5 on slot 1. 9. Configure Port Speed and Duplex The following examples use port 1/5. Disable auto-negotiation To enable it again: Set duplex Set interface speed For example: ⚠️ Be careful with manual speed/duplex In modern Ethernet networks, auto-negotiation should generally be preferred unless there is a specific reason to manually configure speed and duplex. A mismatch can result in poor performance, errors or an unreliable connection. 10. Administratively Disable or Enable a Port To shut down port 1/5: To bring it back up: This is useful when troubleshooting a device or deliberately taking a port out of service. 11. Give a Port an Alias Adding a description to a port makes switch management much easier. For example: You could also use something more descriptive: I highly recommend doing this wherever practical. When troubleshooting months later, a useful port description can save a lot of time. 12. Configure a Management Interface You can create an IP interface on a VLAN for switch management. For example: In this example: Check the configured IP interfaces with: To remove the

Alcatel OmniSwitch Useful CLI Commands: Practical Guide for Network Administrators Read More »

Cisco 887VA BT VDSL2 / FTTC Configuration

If you have a Cisco 887VA sitting around and a BT/Openreach FTTC connection, you can use the Cisco router’s built-in VDSL2 modem to connect directly to the fibre broadband service. Unlike a traditional ADSL connection, BT’s VDSL2 service uses PPPoE over Ethernet, with the broadband service carried over 802.1Q VLAN 101. The Cisco 887VA can handle the VDSL2 connection itself, meaning you don’t necessarily need the separate Openreach modem or a BT Home Hub. This guide shows a practical Cisco IOS configuration for connecting a Cisco 887VA directly to a BT VDSL2/FTTC service. Important: This guide is specifically for VDSL2/FTTC. It does not apply to FTTP, where the WAN connection is presented to your router over Ethernet. What you need For this configuration you will need: The exact interface names and available commands can vary between Cisco 800-series models and IOS releases, so you may need to adjust the configuration for your particular hardware. How BT VDSL works There are three important pieces to the connection: The Cisco router establishes the physical VDSL2 connection using its built-in modem. The broadband traffic is then placed into VLAN 101 on the Ethernet-based VDSL interface. PPPoE runs over that VLAN and creates the PPP session on the Cisco Dialer0 interface. BT’s current documentation confirms that its fibre broadband uses PPPoE, while VLAN 101 is commonly required when configuring third-party equipment directly against the BT/Openreach VDSL service. Configure the VDSL controller Start by configuring the VDSL controller. A typical configuration is: On some Cisco IOS versions, the controller may be named differently. For example, you may see something such as: Use: or, depending on the platform: to identify the correct controller. You can also use the following command to check the current DSL state: The important thing at this stage is that the modem successfully synchronises with the VDSL line. Configure the VDSL Ethernet interface The Cisco 887VA presents the VDSL connection as an Ethernet Layer 2 interface. First configure the physical interface: We then create an 802.1Q subinterface for VLAN 101: The important line here is: This places the PPPoE traffic into VLAN 101. The following command associates the PPPoE client with dialer pool 1: That dialer pool will later be used by Dialer0. Disable the ATM interface The 887VA supports both ADSL and VDSL technologies, so you may see an ATM0 interface in the configuration. For a VDSL2-only configuration it isn’t required: This makes it clear that the router is using the Ethernet-based VDSL interface rather than attempting to establish the broadband session over ATM. Configure the PPPoE Dialer The PPPoE session is terminated on a dialer interface. Create Dialer0: Replace: with the credentials supplied by your ISP. Why MTU 1492? A normal Ethernet frame supports a 1500-byte IP packet. PPPoE introduces an additional 8 bytes of overhead, which normally reduces the usable IP MTU to: Therefore: is a sensible starting point for a standard PPPoE connection. The MSS adjustment: helps prevent TCP packets from being too large for the PPPoE path. Some providers and configurations support larger frames, sometimes referred to as “Baby Jumbo” frames, but there is no reason to introduce that complexity unless your service and downstream equipment support it. Add the default route Once the PPPoE session comes up, traffic needs a default route towards the Internet. You can use: Alternatively, depending on the IOS configuration, ppp ipcp route default can install the default route automatically. I prefer explicitly configuring the route when building a simple configuration because it makes the routing behaviour obvious. Complete basic configuration Putting the important pieces together, a basic BT VDSL configuration looks like this: You will obviously need to adapt this configuration to your own LAN, NAT, DHCP, firewall and routing requirements. Configuring NAT If the Cisco 887VA is also going to act as your Internet router, you will normally need NAT. For example, if your LAN is: configure the LAN interface: Then mark the PPPoE interface as the outside interface: Create a NAT access list: And configure PAT: Your traffic flow is then: Checking the VDSL connection Once the configuration is applied, the first thing to establish is whether the physical VDSL connection is working. Use: You want to see that the modem has trained and is operating in VDSL2 mode. Depending on the IOS version, useful information may include: If the modem hasn’t synchronised, don’t start troubleshooting PPPoE yet. The problem is at the DSL layer. Checking the PPPoE session Once VDSL has synchronised, check the dialer: You should see the interface as up/up and an IP address assigned by the ISP. For example: You can also check the PPPoE session: And check the dialer status: If VDSL is synchronised but Dialer0 isn’t coming up, the problem is likely to be related to PPPoE, VLAN 101 or authentication rather than the physical DSL connection. Useful troubleshooting commands These commands are particularly useful when troubleshooting the connection: For a quick overview of the interfaces: You should expect to see something similar to: VDSL is up but Dialer0 is down This is one of the most common situations. If the router has successfully synchronised with the VDSL line but the PPPoE session isn’t establishing, check the following: 1. Check VLAN 101 Make sure the subinterface contains: VLAN 101 is an important part of many UK BT/Openreach FTTC configurations. 2. Check the PPPoE configuration Make sure the subinterface contains: And make sure Dialer0 contains: These three settings tie the physical VDSL interface, PPPoE client and dialer together. 3. Check your username and password Incorrect PPP credentials will prevent the PPP session from completing. Make sure you haven’t accidentally copied a space or line break into the username or password. 4. Check the PPP negotiation If necessary, PPP debugging can provide more information: Be careful with debugging on a production router because it can generate a significant amount of console/log output. Disable debugging when finished: The VDSL modem won’t synchronise If: shows that the modem is not synchronised, PPPoE configuration is not yet

Cisco 887VA BT VDSL2 / FTTC Configuration Read More »