This comprehensive guide will walk you through everything you need to know, from selecting the right cable and connectors, to crimping, testing, and troubleshooting your custom cables.

Why Make Your Own Ethernet Cable?

There are several advantages to building your own network cables:

• Custom Lengths: No more coiled-up mess or cables that come up just short. Instead, you can make cables the exact length you need.
• Cost Savings: Bulk ethernet cable and connectors are far cheaper per foot than buying pre-made cables.
• Better Quality Control: You choose the cable type, shielding, and connectors, therefore avoiding cheap copper-clad aluminum (CCA) cables.
• Skill Building: This is a useful DIY skill for anyone interested in networking, home labs, or IT work.

Tools and Materials Needed

Here’s what you’ll need to make DIY ethernet cables successfully:

• Ethernet Cable (Cat6, Cat6a, or Cat5e): Prefer solid copper rather than CCA for best performance and compliance with standards. Cat6 bulk cable on Amazon
• RJ45 Connectors: Choose connectors rated for your cable type (Cat6, Cat6a, or Cat5e). Passthrough connectors are easier for beginners. Cat6 RJ45 passthrough connectors
• RJ45 Crimping Tool: Used to secure connectors to the cable. Most crimpers also include a wire cutter and stripper. RJ45 crimp tool
• Cable Tester (Recommended, but optional): Ensures your wiring is correct and detects any faults. Basic cable tester or advanced network tester
• Strain Relief Boots (Recommended, but optional): Add durability to the connector ends. Strain relief boots
• Wire Cutters/Scissors: For trimming cable and internal wires. Wire strippers/cutters

Tip: Avoid “Cat7” or “Cat8” cables sold cheaply online. These are not officially recognized Ethernet standards and often use questionable materials.

Step 1: Measure and Cut Your Cable

Pull the amount of cable you need from the box, then add roughly 30 cm (about 1 foot) of extra length for trimming and flexibility. Cut the cable cleanly using the crimper’s cutting blade or a pair of wire cutters.

Step 2: Strip the Outer Jacket

Use the stripping blade on your crimping tool (or a dedicated wire stripper) to remove 5–10 cm (2–3 inches) of the outer jacket from both ends of the cable. Be careful not to nick the internal wires.

After that, remove the internal string, if present.

At this stage, slide on the strain relief boots if you’re using them—forgetting them is a common mistake. Therefore, it’s best to add them now. You want the larger side facing outward from the end of the cable on both sides.

Step 3: Untwist and Arrange the Wires

Inside the jacket are four twisted pairs of wires (8 total). Untwist the pairs and straighten them.

Then, arrange them in either T-568A or T-568B wiring order. Use the same standard on both ends.

T-568A Wiring Order:

1. White/Green
2. Green
3. White/Orange
4. Blue
5. White/Blue
6. Orange
7. White/Brown
8. Brown

T-568B Wiring Order (Most Common in North America):

1. White/Orange
2. Orange
3. White/Green
4. Blue
5. White/Blue
6. Green
7. White/Brown
8. Brown

Lay the wires flat and keep them in the correct order. Finally, flatten them gently with your thumb for easier insertion.

Step 4: Trim Wires to Length

For non-passthrough connectors, trim the wires so that they are just long enough to reach the end of the connector when inserted. Cut them evenly so they line up perfectly.

For passthrough connectors, leave them a bit longer since the ends will protrude and be trimmed after crimping.

Step 5: Insert Wires Into the RJ45 Connector

Slide the wires into the connector carefully, ensuring they remain in the correct order. Push firmly until:

• Each wire reaches the very end of the connector.
• The outer jacket passes the strain relief tab for a strong connection.

For passthrough connectors, the wires should stick out slightly from the other side.

As soon as you confirm the order, you’re ready to crimp.

Step 6: Crimp the Connector

Place the connector into the crimping tool and squeeze firmly until the pins press down into the wires and the strain relief tab locks onto the outer jacket.

Additionally, for passthrough connectors, trim the wire ends flush with the connector after crimping.

Then, repeat this entire process for the other end of the cable!

Step 7: Test Your Cable

Use a cable tester to confirm that all eight wires are connected in the correct order.

The lights on both ends should flash in sequence.

If any wires are misaligned, cut off the connector and repeat the process on that side.

Once confirmed, your custom ethernet cable is ready for use!

Cat6 vs Cat6a vs Cat5e: Which Should You Choose?

Not all Ethernet cables are created equal. Therefore, here’s a quick comparison to help you decide:

Recommendation: Use Cat6 for most home setups, Cat6a if you want to future-proof or need maximum performance for longer runs, and Cat5e only if you already have it on hand or are working with very low-cost builds.

Frequently Asked Questions

Q: Can I mix T-568A on one end and T-568B on the other?
A: Only if you are intentionally creating a crossover cable. Otherwise, use the same wiring standard on both ends.

Q: How long can an Ethernet cable be?
A: Standard twisted-pair Ethernet cables (Cat5e, Cat6, Cat6a) are rated for up to 100 meters (328 feet) in total length. This includes patch cables at both ends. Beyond this length, you may experience signal loss or reduced speeds.

For 10 Gbps on Cat6, keep runs under 55 meters; use Cat6a for longer 10 Gbps runs.

Q: Do I really need a cable tester?
A: While optional, it saves time and frustration by catching miswires before you plug into your network.

Q: Should I ever use CCA cable?
A: No. Instead, always use solid copper cable for performance, safety, and compliance with Ethernet standards.

Troubleshooting Common Issues When Making Ethernet Cables

• Tester Shows Miswired Pair: Re-check wiring order on both ends, re-crimp if needed.
• Cable Doesn’t Click Securely: Ensure the strain relief tab is pressed down properly during crimping. Also ensure that the release tab covers on your strain relief boots aren’t too stiff and pressing down on the release tabs of the RJ45 connectors as a result. You may want to work the rubber of the strain relief boots with your thumbs a bit to stretch and break them in.
• Poor Network Speeds: Test on another device and verify that you’re using solid copper cable, not CCA.

Final Remarks

Learning how to make ethernet cables saves money, eliminates clutter, and gives you full control over your network setup. Whether you’re wiring a home office, building a home lab, or just need a few short patch cables, this DIY approach is a game changer.

Practice a few times and you’ll be making professional-quality network cables in minutes!

If you prefer a video guide, you can watch my video guide below.

The post How to Make Ethernet Cables: A Complete Step-by-Step Guide appeared first on TechOpt.

In this guide, you’ll discover how to set a static IP in Ubuntu and define custom DNS settings, including nameservers and search domains. Additionally, we’ll explain how to keep DHCP while specifying DNS servers for better control.

Why Should You Set a Static IP on Ubuntu Server?

Assigning a static IP ensures your server retains the same address across reboots. This reliability is essential for servers running web services, databases, or acting as internal network resources.

Step 1: Identify Your Ubuntu Server Network Interface

To begin, list your network interfaces:

ip link

You’ll usually see names like eth0, ens33, or enp0s3.

Step 2: Edit the Netplan Configuration

Netplan configurations are stored in /etc/netplan/. View the files with:

ls /etc/netplan/

Next, edit the YAML file (replace with your actual file name):

sudo nano /etc/netplan/50-cloud-init.yaml

Here’s an example static IP configuration for Ubuntu Server:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

Replace eth0 with your interface name. Adjust the IP, gateway, and DNS to match your network.

Important: Some older guides might mention using the gateway4 parameter. However, gateway4 has been deprecated. It’s better to use the routes section, as demonstrated above, for better compatibility with future Ubuntu versions.

Step 3: Apply the Static IP Ubuntu Configuration

Once you have finished editing, apply the changes with:

sudo netplan apply

To confirm your new settings, run:

ip a

This command will display your active IP address. To confirm your DNS configuration is working, you can run:

apt update

This will refresh the built-in software repositories, and as long as it’s successful you know that your DNS configuration is working.

Alternative: Keep DHCP but Configure DNS in Ubuntu Server

If you prefer to use DHCP for IP assignment but still want to control DNS servers, use this configuration:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: yes
      dhcp4-overrides:
        use-dns: no
      nameservers:
        search: [yourdomain.local]
        addresses:
          - 1.1.1.1
          - 1.0.0.1

This method allows the server to receive its IP address from the DHCP server, while your specified DNS servers handle name resolution.

Conclusion

To sum up, netplan is the modern, recommended tool for configuring a static IP Ubuntu setup. You should avoid older methods like resolvconf or editing /etc/network/interfaces, as they are deprecated in the latest Ubuntu versions. Whether you need a full static IP or simply want to control your DNS while keeping DHCP, netplan makes the process clear and manageable.

If you would like to learn about all the configuration options for netplan, you can read the official Netplan documentation.

If you would prefer to view this guide in video form, I’ve created a video explaining these instructions on the TechOpt.io YouTube channel, which you can watch below:

The post Setting a Static IP Address and DNS in Ubuntu Server appeared first on TechOpt.

Warning

Use this method at your own risk. Modifying HTML responses through Nginx can easily break your webpage if not handled carefully. Always test changes in a controlled environment before deploying them to production.

Nginx is not designed for content manipulation, and this approach should only be used as a last resort. Before proceeding, exhaust all other options, such as modifying the source code, using a built-in integration, or leveraging a client-side solution.

How to Add a Script to HTML Using Nginx

If you need to add a script, or any other HTML to an HTML file using Nginx, you can use the sub_filter module to modify response content on the fly. By leveraging this, we can insert a <script> tag before the closing </head> tag in the HTML document.

Configuration Example

To achieve this, add the following to your Nginx configuration:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        proxy_buffering off;

        sub_filter '</head>' '<script src="https://example.com/analytics.js"></script></head>';
        sub_filter_types text/html;
        sub_filter_once on;
    }
}

Explanation

• sub_filter '</head>' '<script src="https://example.com/analytics.js"></script></head>': This replaces </head> with our script tag, ensuring it appears in the document head.
• sub_filter_types text/html;: Ensures the filter applies only to HTML responses.
• sub_filter_once on;: Ensures that the replacement happens only once, as </head> should appear only once in a valid HTML document.

Adding an Nginx Proxy for Script Injection

To implement this solution without modifying the existing helpdesk software, I set up another Nginx instance in front of it. This new Nginx proxy handles incoming requests, applies the sub_filter modification, and then forwards the requests to the helpdesk backend.

Here’s how the setup works:

1. The client sends a request to example.com.
2. Nginx intercepts the request, modifies the HTML response using sub_filter, and injects the script.
3. The modified response is then sent to the client, appearing as if it were served directly by the helpdesk software.

This approach keeps the original application untouched while allowing script injection through the proxy layer.

Remarks

• Nginx is primarily a proxy and web server, not a content manipulation tool. Modifying content in this way should be a last resort after exhausting all other options, such as modifying the source code, using a built-in integration, or leveraging a client-side solution. Overuse of sub_filter can introduce unexpected behavior, break page functionality, or impact performance.
• sub_filter requires proxy_buffering off;, which may degrade performance, especially for high-throughput sites, by preventing response buffering and increasing load on the backend.
• If you’re adding multiple scripts or need flexibility, consider using a tag manager such as Google Tag Manager instead.
• You can use this method to modify or inject any HTML, not just scripts.

The post Adding a Script Tag to HTML Using Nginx appeared first on TechOpt.

Understanding Zigbee and Wireless Interference

Zigbee operates in the 2.4 GHz band using channels numbered from 11 to 26. Meanwhile, Wi-Fi networks (802.11b/g/n) also use the 2.4 GHz band, which can create potential interference with Zigbee signals. Other sources of interference include Bluetooth devices, microwaves, and cordless phones.

Here’s a breakdown of how Zigbee and Wi-Fi channels overlap:

• Zigbee Channel 11 (2405 MHz) – Overlaps with Wi-Fi channels 1-3 (high interference potential).
• Zigbee Channel 15 (2425 MHz) – Slightly overlaps with Wi-Fi channels 6-7 (a much better choice).
• Zigbee Channel 20 (2450 MHz) – Slightly overlaps with Wi-Fi channels 9-11 (another good option).
• Zigbee Channel 25 (2475 MHz) – Sits near Wi-Fi channel 13 (a solid choice in some cases, but not all devices support it well).
• Zigbee Channel 26 (2480 MHz) – Least interference but has reduced transmission power in some regions.

To visually see the overlap between Wi-Fi and Zigbee channels, you can consult the graph below:

Recommended Zigbee Channels

Based on interference patterns, the best Zigbee channels to use are:

1. Channel 15 (2425 MHz)

This channel is one of the best choices because it avoids heavy overlap with common Wi-Fi channels like 1, 6, and 11. It provides a stable connection for most Zigbee devices.

2. Channel 20 (2450 MHz)

Another great option, channel 20, minimizes interference while maintaining strong signal strength. If you experience issues with channel 15, this is a great alternative.

3. Channel 25 (2475 MHz) – With Caution

Channel 25 can work well in environments where interference is a problem, as it avoids most of the congestion. However, some Zigbee devices may not fully support this channel, leading to inconsistent performance.

You should test each device individually with Channel 25 and make sure that you aren’t experiencing any issues. If everything seems okay, channel 25 should work for you.

Zigbee Channel 11: Why You Should Avoid It

Zigbee channel 11 is the default for many devices, but it overlaps heavily with Wi-Fi channels 1, 2, and 3. If you leave your Zigbee network on channel 11 in a busy environment, you may experience dropped connections and slow response times.

Remarks

• Best Channels: Zigbee channel 15 and 20 provide the best balance of performance and minimal interference.
• Channel 25 Consideration: If your devices support it, channel 25 can work well in certain environments but may not be compatible with all devices. Test your devices for compatibility.
• Avoid Channel 11: Due to its heavy overlap with Wi-Fi, channel 11 is not recommended unless necessary.
• Check Your Network: Use tools like Zigbee2MQTT or Home Assistant’s network map to analyze and optimize your Zigbee network.
• Interference Sources: Besides Wi-Fi, other wireless signals such as Bluetooth, microwaves, and cordless phones can also impact Zigbee performance.
• Multiple Zigbee Networks: If you have more than one Zigbee network, use different channels to avoid interference. For example, I have my Philips Hue on channel 15 and my Home Assistant Zigbee2MQTT network on channel 20.
• Wi-Fi Channel 13: Depending on your region, Wi-Fi channel 13 may not be a concern. In Europe and most parts of Asia, channel 13 is allowed and commonly used, whereas in North America, its use is restricted. This means that interference from Wi-Fi channel 13 may not be an issue depending on where you live.

The post Best Zigbee Channel to Use: Avoiding Interference appeared first on TechOpt.

OPNsense was forked from pfSense in 2015. The development team actively updates it and has given it a modern UI. Over time, OPNsense has deviated from pfSense and matured into its own operating system, led by its own team of developers and decision-makers. This makes it similar to, but not identical to pfSense.

As such, migration does require some planning, since not everything in OPNsense is identical to pfSense.

Motivations for Migrating from pfSense to OPNsense

pfSense was great and modern when I first started using it, but over the years it became very clunky. Updates to the Community Edition also seem to have slowed. The interface is dated. There was also a bit of a scandal with their original WireGuard implementation. This left a bit of a bad taste for me, considering I already used OpenVPN frequently through pfSense and would have liked to setup WireGuard as well.

Unfortunately, because OPNsense has deviated from pfSense so much, there is no direct way to migrate from pfSense to OPNsense. This means you must port pretty much all configuration manually. This may or may not be a big deal, depending how much you rely on services running on your pfSense box.

Planning the Migration

In my case, I relied on my pfSense box for the following services:

• Router
• Firewall
• Squid caching HTTP proxy
• HAProxy reverse proxy for many services, both internal and external
• OpenVPN
• WireGuard
• ACME Client (SSL Renewal)

I needed to port the configurations of each service to OPNsense. I also had a few (loose) requirements for the migration:

• The migration shall appear transparent to all other clients on the network.
• Behaviour of services shall remain unaffected before and after the migration.
• Clients shall not have to do any reconfiguration.
• There shall be minimal downtime, ideally less than 30 minutes. My household loves our internet!

Migrating from pfSense to OPNsense

These are the steps I took to migrate my pfSense box to OPNsense. You can use this as a guide, but some steps will vary depending on your setup and the tools you have available.

The steps I took involved creating a virtual machine and installing OPNsense, configuring OPNsense in the virtual machine and exporting the configuration as an OPNsense configuration file. This way, I could install OPNsense on my bare metal router box and simply import the configuration, all ready to go.

1. Creating an OPNsense Virtual Machine

To start, I created a virtual machine in Proxmox to simulate my router box. The important thing was to give it 2 network interfaces, so I could simulate the WAN and LAN ports on the physical box.

Next, I installed OPNsense in the virtual machine. By default, OPNsense assigns a new subnet on the LAN interface after installation. To access the OPNsense configuration page, I needed to give the LAN interface a static IP address in my current network range.

My pfSense box has an IP address of 172.16.0.1, so I decided to give my OPNsense VM LAN interface an IP address of 172.16.0.201 so I could easily remember it. This interface will eventually take over the IP address of the pfSense box when porting is complete.

2. Using Both Admin Panels to Convert pfSense Configuration to OPNsense Configuration

First, I logged into both my pfSense box at 172.16.0.1, and my OPNsense virtual machine at 172.16.0.201. I checked which external software packages I had installed on my pfSense box and installed the equivalents on OPNsense.

Next, I started going through each relevant pfSense configuration page, finding the corresponding page in OPNsense and manually porting the configuration values. I started with basic network configuration such as hostname and routing, then firewall rules, and finally external software packages.

This was a long and tedious process with so much network configuration and so many service configurations to port. Since OPNsense is a fork of pfSense after all, a lot of the configuration pages are almost identical, but with a new look.

However, there were some notable mentions where the configuration pages did differ quite a bit and I had to figure out the equivalent configuration from pfSense to OPNsense. This was especially true for HAProxy, which I left until last, since I knew it would be the biggest pain.

I’ll outline my general experience with each configuration and service I ended up porting.

2.1. Hostname, Interfaces, DHCP, Routing & Firewall

These categories were super easy since the structure of the configuration pages for hostname, interfaces, DHCP, routing and firewall are almost identical between pfSense and OPNsense. I set the hostname, turned off DHCP (I have another DHCP server on my network), recreated all static routes in my route table (which weren’t many), and recreated all firewall rules (again, not many).

2.2. Squid Caching HTTP Proxy, WireGuard, OpenVPN and ACME Client

This category of configurations was relatively easy to port as well, with the only caveat being that some of the options were separated into different tabs and hidden under an Advanced flag. Still, they were all pretty easy to work with.

The WireGuard page was notably slightly different, mostly due to the scandal I mentioned above, but the equivalent options were easy enough to find.

2.3. HAProxy Reverse Proxy

This one was the biggest pain. I had about 20 different services running through this proxy using pfSense. The way HAProxy is configured on pfSense is totally different from the way it’s configured on OPNsense. My configuration on pfSense was already pretty elaborate.

The OPNsense HAProxy configuration does a better job of separation of concerns over pfSense’s implementation. Different pages are used for rules and checks, whereas these are defined with your frontend configuration in pfSense.

This also did make configuration on OPNsense a bit more tedious, but a lot cleaner in the long run. Overall, I spent about an hour porting everything and making sure it worked correctly.

2.3.1. Testing the HAProxy Configuration

Testing the services proxied by HAProxy and making sure SSL worked correctly was also a bit of a pain, but since I run Linux I was able to temporarily edit my /etc/hosts file to point to 172.16.0.201, the LAN IP of my OPNsense VM, for whichever service I was testing as I ported each one.

If you do this, just make sure you are familiar with /etc/hosts and know what you’re doing.

3. Exporting the OPNsense Configuration File

Finally, I exported the OPNsense configuration file, saved it to my computer and my USB drive (just in case) and shutdown the virtual machine.

At this point, I also exported my pfSense configuration file, just in case something was to happen and I had to quickly revert to pfSense for the time being.

It’s important to note that these two files are not interchangeable and it’s important not to mix them up.

4. Installing OPNsense on my Hardware Router Box

I added the OPNsense ISO to my Ventoy USB and booted the installer on my hardware router box. After installation, I gave the router LAN address an IP address of 172.16.0.1, the same IP address that the router was assigned when it ran on pfSense.

5. Applying the New OPNsense Configuration

Next, I went to back to my computer and went to the OPNsense configuration page at 172.16.0.1. From there, I simply applied the configuration file I had downloaded to my computer earlier, gave it a moment and logged back into the OPNsense configuration page at 172.16.0.201.

Note that the IP address I’m using to login is still the IP address I assigned the LAN interface in the VM, because that’s what it was in the exported configuration file.

I changed the LAN IP address to 172.16.0.1 from the configuration page and rebooted.

After a few minutes, I went to the admin page at the new IP address of 172.16.0.1. I just needed to manually install all the packages in the OPNsense VM from the plugins page. The UI highlights the missing plugins, allowing you to easily reinstall them.

Thankfully the configuration for all these plugins is saved in the OPNsense configuration file, so I gave the router one last reboot to make sure everything was up and running correctly.

6. Fully Testing the Migration of pfSense to OPNsense

That was it! We had internet access. I was able to access all my internal HAProxy services with SSL working using the original URLs as expected.

To test external HAProxy services, WireGuard and OpenVPN, I used my data connection on my phone. All were working as expected.

Conclusion

All in all, it took me about 2 hours to port all the configuration from pfSense to OPNsense manually using the admin panels, and then about 20 minutes of internet downtime to install OPNsense and restore the configuration file on my bare metal router box. Not bad! It’s not a hard process once you figure out a good plan, just tedious.

I also suggest you pick OPNsense over pfSense Community Edition for a new build, since it’s much more modern and updated more regularly.

Remarks

• I used Proxmox for my OPNsense virtual machine used to create my configuration, but you can do the same thing with VirtualBox or Hyper-V.
• If you’re having trouble accessing the OPNsense administration page after restoring your configuration file on your router box, you should try both the IP address you assigned in the VM, and the IP address you assigned via the console upon first boot on your actual hardware (172.16.0.201 and 172.16.0.1 in my case, respectively).
• If you were wondering about the hardware in my router box, it’s made from some old PC parts mounted in a server rack: an AMD A8-6600K CPU, 8 GB of RAM and a 120 GB SSD with an Intel dual NIC. Nothing fancy by today’s standards, but even so it’s still a bit overkill for this purpose.

The post pfSense to OPNsense Migration of a Router/Firewall appeared first on TechOpt.