I’m thrilled to announce the launch of DevBrief, your new go-to source for quick, impactful tech insights. Whether you're a busy professional, tech enthusiast, or business owner, DevBrief is here to keep you updated on all things tech without the fluff.

What’s DevBrief All About?

At DevBrief, the focus is on delivering concise, well-researched content that cuts straight to the chase. From software development and product reviews to NAS servers, you’ll find a variety of topics that cater to your tech curiosity. Plus, if you’re into NAS servers, especially Synology and custom builds, there’s plenty of in-depth coverage coming your way.

Who’s Behind DevBrief?

I’m Matthew Pomar, a Lead Salesforce Developer and Technical Architect with over 12 years in Salesforce development and architecture, 27 years in other software development, and 32 years of total IT experience. With a passion for technology and a knack for making complex topics accessible, I’ve created DevBrief to share reliable and engaging tech content with you.

What to Expect

Here’s a sneak peek at what you can expect from DevBrief:

• Software Development: Tips, tutorials, and best practices for various programming languages and frameworks.

• Product Reviews: Unbiased reviews of the latest software, tools, and services to help engineers and IT professionals.

• Guides and How-Tos: Step-by-step guides to help you navigate new technologies and solve common tech problems.

• NAS Servers: Detailed coverage on NAS servers, with a special focus on Synology, but also including other brands.

Make Sure to Subscribe

Stay ahead of the curve by subscribing to DevBrief on Substack. By subscribing, you’ll enjoy:

• Exclusive Content: Access articles, guides, and reviews that are only available to subscribers.

• Regular Updates: Get notified whenever new content is posted, so you never miss out on the latest insights.

• Community Engagement: Participate in discussions, ask questions, and connect with fellow tech enthusiasts through Substack’s Chat and DM features.

Don’t miss out on the valuable content designed to make your tech journey smoother and more informed. Subscribe now and become a part of the DevBrief community!

Subscribe now

Join the Community

I invite you to join the DevBrief community by subscribing to the newsletter on Substack, following on social media, and participating in the discussions. Together, let’s learn and grow in the ever-evolving world of technology.

Get in Touch

Got questions, suggestions, or just want to say hi? Reach out via Substack’s Chat or DM.

Thank you for being a part of this exciting journey. Stay tuned for your daily dose of succinct tech insights for the busy software engineer and IT professional!

Best,

Matthew Pomar

The Cloudflare-Substack Redirect Challenge

I recently faced an interesting challenge when migrating my Retrothusiast WordPress blog to Substack. The main issue arose from the difference in URL structures between WordPress and Substack. While my WordPress posts were accessible at URLs like https://www.retrothusiast.com/awesome-blog-post, Substack appends a /p/ prefix to all post URLs, resulting in https://www.retrothusiast.com/p/awesome-blog-post.

This discrepancy meant that all my existing links would break unless I implemented proper redirects. Naturally, I turned to Cloudflare, a popular content delivery network and DNS provider, to handle these redirects. However, I quickly encountered a significant roadblock.

Substack's DNS Recommendations

Substack's documentation explicitly recommends setting the "www" CNAME record to "DNS Only" when configuring Cloudflare. This setting disables Cloudflare's proxy features, including the ability to use Workers and other redirect features.

Here's what Substack's support AI had to say about using Cloudflare's proxy:

When using Cloudflare for your custom domain on Substack, it's important to set the “Proxy status” of your CNAME record to “DNS only.” This setting ensures that the DNS record is not proxied through Cloudflare's servers, which can interfere with the proper functioning of your Substack publication.

This recommendation posed a significant challenge to my initial plan of using Cloudflare's features for redirects.

Understanding the Risks of Proxying

Before diving into solutions, it's crucial to understand why Substack recommends against proxying through Cloudflare. After extensive research and discussions with Substack support, I identified several potential issues that could arise from using Cloudflare's proxy with a Substack publication:

1. SSL/TLS Certificate Errors: The SSL configuration between Cloudflare and Substack could potentially cause certificate errors, leading to security warnings in browsers.

2. Caching Issues: Cloudflare's caching mechanisms might serve outdated content, causing problems with dynamic content like new posts or updates.

3. Email Deliverability: The proxy could affect how the domain's DNS records are handled, potentially causing issues with email deliverability if SPF, DKIM, and DMARC records are not correctly set.

4. Performance Issues: While Cloudflare generally improves site performance, misconfigurations could lead to increased load times or errors during high traffic periods.

5. Redirection Loops: Incorrectly configured redirects in Cloudflare could cause redirection loops, making the site inaccessible.

These risks, while manageable for an experienced developer, could indeed cause significant issues for the average Substack user. It became clear why Substack recommends the "DNS Only" setting as a safer default option.

Exploring Cloudflare Solutions

Despite Substack's recommendations, I decided to explore Cloudflare's features to see if I could find a workable solution for implementing redirects. My focus landed on Cloudflare Bulk Redirects, a feature available even on the free Cloudflare plan.

Implementing Cloudflare Bulk Redirects

To set up Bulk Redirects, I followed these steps in the Cloudflare UI:

1. Logged into my Cloudflare dashboard.

2. Navigated to the "Rules" section.

3. Clicked on "Bulk Redirects".

4. Created a new Bulk Redirect List.

5. Added my redirect rules, specifying the source URL and the target URL for each redirect.

I made sure to include redirects for all my important posts and categories.

Setting Up the Bulk Redirect Rule

After creating the Bulk Redirect List, I set up a rule to apply these redirects:

1. In the Bulk Redirects section, I clicked on "Create rule".

2. I named the rule "Retrothusiast Redirects".

3. Under "When incoming requests match...", I set:

   • Field: Hostname

   • Operator: equals

   • Value: retrothusiast.com

4. Under "Then, apply matching URL redirects from the following list...", I selected my created redirect list.

5. I reviewed the settings and clicked "Save".

This configuration allows Cloudflare to apply the redirects when requests match my domain, ensuring that old URLs are properly redirected to their new Substack counterparts.

The DNS Only Dilemma

Even with Bulk Redirects set up, I still faced the dilemma of Substack's "DNS Only" recommendation. Cloudflare's redirect features, including Bulk Redirects, require the domain to be proxied through Cloudflare (orange cloud icon). This put me at a crossroads: adhere strictly to Substack's recommendation or implement the necessary redirects.

Weighing the Options

After careful consideration, I found myself facing four distinct options, each with its own set of pros and cons:

1. Use a custom domain with DNS Only: This option would adhere strictly to Substack's recommendations, but it meant living with 404 errors for all my old URLs and losing valuable backlinks.

2. Use a custom domain with a subdomain: By setting up something like substack.retrothusiast.com, I could potentially keep my backlinks and avoid 404 errors. However, this would mean changing my main URL structure, which could confuse regular readers.

3. Don't use a custom domain: Running my blog directly off the Substack domain (retrothusiast.substack.com) would be the simplest solution technically, but it would mean losing my established brand presence and starting from scratch in terms of SEO.

4. Use a custom domain with Cloudflare's Proxy feature: This option would allow me to implement the necessary redirects and maintain my backlinks, but it goes against Substack's recommendations and could potentially lead to issues.

After weighing these options carefully, I ultimately decided to go with option 4: using a custom domain with Cloudflare's Proxy feature enabled. This decision was not made lightly, and I committed to closely monitoring the site for any issues that might arise.

Here's why I chose this path:

1. Preserving SEO and User Experience: By implementing redirects, I could maintain my SEO value and ensure that users following old links would still reach the correct content.

2. Leveraging Cloudflare's Features: The Bulk Redirects feature offered a manageable way to handle the URL structure change without diving into complex server configurations.

3. Balancing Risk and Reward: While this approach goes against Substack's recommendations, the potential benefits of maintaining my site's integrity outweighed the risks in my specific situation.

4. Commitment to Monitoring: I set up thorough monitoring to quickly catch and address any issues that might arise from this configuration.

This decision underscores an important lesson in web development and site migrations: sometimes, you have to make calculated decisions that balance best practices with practical necessities. However, it's crucial to do so with a full understanding of the potential risks and a solid plan for mitigation.

Take Away

This decision underscores an important lesson in web development and site migrations: sometimes, you have to make calculated decisions that balance best practices with practical necessities. However, it's crucial to do so with a full understanding of the potential risks and a solid plan for mitigation.

Conclusion

Implementing redirects for a Substack blog using Cloudflare while adhering to Substack's recommendations is a challenging task that requires careful consideration of various factors. While there's no one-size-fits-all solution, a combination of limited use of Cloudflare Bulk Redirects, strategic use of Substack's import tools, and constant monitoring can achieve a workable balance.

Remember, every website has unique requirements, and what worked for me might not be the perfect solution for everyone. Always test thoroughly and be prepared to adjust your approach as needed.

If you've faced similar challenges or have alternative solutions to share, I'd love to hear about them. Let's continue the conversation and help each other navigate the ever-evolving landscape of web development and content platforms.

Join the Community

Did you find this article helpful? There's plenty more where that came from! Subscribe to DevBrief for regular doses of practical tech insights tailored for busy software engineers and IT professionals. Join our growing community on Substack Chat to discuss this topic further, share your experiences, and connect with like-minded individuals. Let's learn and grow together!

Subscribe now

In this guide, I'll show you how I broke free from these limitations using SSH Port Forwarding and Tailscale on Ubuntu, allowing me to securely access my Proton Mail account from any device or location, all while maintaining the strong encryption and privacy that drew me to Proton Mail in the first place.

Setting Proton Mail Free

Let me start by saying I love Proton Mail. I love the security and privacy (of course), I love the clean UI design, and I love that it works for both personal and business use cases. I love that it has a great Calendar that works with multiple domains, Drive, Password Manager, and now Standard Notes is joining the fold. I love the support team. I love the company mission and leadership. There is so much to love.

However, the security benefit is also a double-edged sword. I have to use the Proton apps to access my email and calendar. I can use the Proton Mail Bridge, but it's only available via localhost (127.0.0.1). I want to be able to use any email client on my phone or desktop computer, and I want to continue to access IMAP using help desktop software like FreeScout.

The good news, I can do all of these things and still maintain strong security and encryption. By using SSH Port Forwarding and Tailscale on Ubuntu (could also work on other operating systems), I have setup port forwarding between Proton Mail Bridge listening on localhost to a local network IP address as well as a Tailscale VPN address. Doing this allows me to access my email via IMAP and SMTP on my local network and over the Tailscale network, setting Proton Mail free to be used as I like.

How To Set It Up

I'm no Ubuntu guru. Most of what I did here was done with heavy help from ChatGPT. There may be better ways to do this, or easier ways, or just different ways. I am just saying this is how I set it up and how you might set this up as well if you are interested.

Here's what you need:

• Ubuntu installed on a VM or physical machine.

• Proton Mail Bridge installed and configured.

• Tailscale installed and configured.

• Know your way around on a terminal command line at least a little.

Now, let's dive into the process of setting this up on an Ubuntu system.

Setting Up the Environment

Before we dive into the nitty-gritty of SSH port forwarding, let's ensure we have all the necessary components in place.

Installing ProtonMail Bridge

First things first, we need to install ProtonMail Bridge on our Ubuntu system. Here's how (check the Proton Mail website for latest and greatest instructions):

1. Download the .deb package from the ProtonMail website.

2. Open a terminal and navigate to the directory containing the downloaded file.

3. Run the following command:

sudo apt install ./protonmail-bridge_<version>_amd64.deb

Replace <version> with the actual version number of the downloaded package.

If you encounter any dependency issues, you can resolve them by running:

sudo apt --fix-broken install

Installing Tailscale

Tailscale is a crucial component of our setup, allowing for secure remote access. Here's how to install it on Ubuntu (check the Tailscale website for latest and greatest instructions):

1. Add Tailscale's package repository:

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list

2. Update the package list and install Tailscale:

sudo apt-get update
sudo apt-get install tailscale

3. Start Tailscale and authenticate:

sudo tailscale up

This command will provide a URL. Open this URL in your web browser to authenticate and connect your device to your Tailscale network.

4. Verify Tailscale is running:

tailscale status

This should display your Tailscale IP address and other connected devices in your Tailscale network.

Remember to note your Tailscale IP address, as you'll need it when configuring the SSH port forwarding for Tailscale.

Setting Up SSH

Next, we need to ensure SSH is properly configured on our Ubuntu system:

Install OpenSSH Server:

sudo apt update && sudo apt install openssh-server

Verify that the SSH service is running:

sudo systemctl status ssh

You should see output indicating that the service is active and running.

Configuring SSH Port Forwarding

Now that we have the basic components in place, let's set up SSH port forwarding to expose the ProtonMail Bridge service.

Creating a Systemd Service for Local Network

We'll start by creating a systemd service that handles port forwarding for our local network:

1. Create a new systemd service file:

sudo nano /etc/systemd/system/ssh-port-forwarding-local.service

2. Add the following content to the file:

[Unit]
Description=SSH Port Forwarding for Local Network
After=network-online.target
Wants=network-online.target

[Service]
User=your_username
ExecStart=/usr/bin/ssh -i /home/your_username/.ssh/id_rsa -N \
    -L 192.168.x.x:1143:localhost:1143 \
    -L 192.168.x.x:1025:localhost:1025 \
    your_username@localhost
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Make sure to replace your_username with your actual username.

3. Save the file and exit the text editor.

4. Reload the systemd daemon to recognize the new service:

sudo systemctl daemon-reload

Enable and start the service:

sudo systemctl enable ssh-port-forwarding-local
sudo systemctl start ssh-port-forwarding-local

This service will forward the ProtonMail Bridge IMAP (1143) and SMTP (1025) ports from your local IP address to localhost.

Setting Up Tailscale Port Forwarding

Now, let's set up a separate service for Tailscale port forwarding. This will allow us to access ProtonMail Bridge remotely:

1. Create a user-level systemd service file:

mkdir -p ~/.config/systemd/user/ nano ~/.config/systemd/user/ssh-port-forwarding-tailscale.service

2. Add the following content to the file:

[Unit]
Description=SSH Port Forwarding for Tailscale Network
After=network-online.target
Wants=network-online.target

[Service]
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/ssh -i /home/your_username/.ssh/id_rsa -N \
  -L 100.100.x.x:1143:localhost:1143 \
  -L 100.100.x.x:1025:localhost:1025 \
  your_username@localhost
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

Replace your_username with your actual username and 100.100.x.x with your Tailscale IP address.

3. Save the file and exit the text editor.

4. Reload the user systemd daemon:

systemctl --user daemon-reload

5. Enable and start the user service:

systemctl --user enable ssh-port-forwarding-tailscale
systemctl --user start ssh-port-forwarding-tailscale

Overcoming Challenges

During the setup process, I encountered a few challenges that required some creative problem-solving. Here are some of the issues I faced and how I resolved them:

Boot and Login Delays

Initially, I tried to use a sleep command (ExecStartPre=/bin/sleep 10) in the systemd service to ensure all necessary services were up before starting the port forwarding. However, this caused significant delays in boot and login times.

Solution: I removed the sleep command and instead relied on the After and Requires directives in the systemd unit files to ensure proper service dependencies.

Port Conflicts

I ran into issues with port conflicts, particularly with the ProtonMail Bridge already using ports 1143 and 1025 on localhost.

Solution: Instead of binding directly to these ports, I set up the SSH port forwarding to listen on the specific IP addresses (both local network and Tailscale) and forward to the localhost ports. This allowed the ProtonMail Bridge to run normally while still providing remote access.

Tailscale Connectivity Issues

Initially, the Tailscale port forwarding wasn't working reliably after system reboots.

Solution: I created a separate user-level systemd service for Tailscale port forwarding. This service starts after login, ensuring that the Tailscale network is fully established before attempting to set up the port forwarding.

Fine-Tuning the Setup

After getting the basic setup working, I made a few additional tweaks to optimize the configuration:

Separating Local and Tailscale Services

By creating separate services for local network and Tailscale port forwarding, I ensured that local access would always be available immediately after boot, while Tailscale access would become available after login. This separation provides a good balance between immediate local access and secure remote access.

Handling Network Changes

To make the setup more robust, I added the Restart=always and RestartSec=10 options to both service files. This ensures that if there are any network interruptions or changes, the port forwarding will automatically attempt to re-establish itself.

Testing and Verification

After setting up the port forwarding, it's crucial to test and verify that everything is working as expected. Here are some steps I took to ensure the setup was functioning correctly:

1. Check Service Status: Use the following commands to verify that both services are running without errors:

sudo systemctl status ssh-port-forwarding-local
systemctl --user status ssh-port-forwarding-tailscale

2. Verify Port Bindings: Use the ss command to check if the ports are correctly bound:

sudo ss -tuln | grep 1143
sudo ss -tuln | grep 1025

3. Test Local Access: Configure your email client to connect to the local IP address (e.g., 192.168.x.x) using ports 1143 for IMAP and 1025 for SMTP.

4. Test Remote Access: From a device on a different network, use the Tailscale IP address to connect to your ProtonMail Bridge.

Take Aways

This project taught me several valuable lessons about network configuration and service management in Linux:

1. Understand Service Dependencies: Properly managing service dependencies is crucial for a reliable setup, especially when dealing with network-related services.

2. Separate Concerns: Splitting the port forwarding into two services (local and Tailscale) provided more flexibility and reliability.

3. User-Level Services: Utilizing user-level systemd services for non-critical components can help avoid boot-time issues and provide better isolation.

4. Iterative Problem Solving: Don't be afraid to iterate on your solution. My initial attempts had issues, but through persistence and tweaking, I arrived at a robust configuration.

5. Documentation is Key: Keeping detailed notes throughout the process not only helped me troubleshoot issues but also allowed me to create this guide to help others.

Wrap Up

Setting up SSH port forwarding with Tailscale for ProtonMail Bridge access was a challenging but rewarding project. It provided me with a secure and reliable way to access my ProtonMail account from anywhere, while also deepening my understanding of Linux networking and service management.

This setup has significantly improved my workflow, allowing me to seamlessly access my secure email whether I'm on my local network or working remotely. The combination of SSH's security and Tailscale's ease of use has proven to be a powerful solution for remote access needs.

Remember, while this guide provides a detailed walkthrough, always ensure you understand each step and consider the security implications for your specific setup.

Happy port forwarding!

Join The Community

Did you find this article helpful? There's more where that came from! Subscribe to DevBrief.com for more in-depth technical insights and join our vibrant community on Substack Chat. Let's grow together as developers and IT professionals!

Subscribe now