• Search for:
    22 Jun, 2021
    Making WireGuard from Homebrew Work on an M1 Mac
    Cloud

    After writing the post on using WireGuard on macOS (using the official WireGuard GUI app from the Mac App Store), I found the GUI app’s behavior to be less than ideal. For example, tunnels marked as on-demand would later show up as no longer configured as an on-demand tunnel. When I decided to set up WireGuard on my M1-based MacBook Pro (see my review of the M1 MacBook Pro), I didn’t want to use the GUI app. Fortunately, Homebrew has formulas for WireGuard. Unfortunately, the WireGuard tools as installed by Homebrew on an M1-based Mac won’t work. Here’s how to fix that.

    The key issues with WireGuard as installed by Homebrew on an M1-based Mac are:

    • On an M1-based Mac, Homebrew installs (by default) to the /opt/homebrew prefix. By comparison, Homebrew uses /usr/local on Intel-based Macs. Some of the WireGuard-related scripts are hard-coded to use /usr/local as the Homebrew prefix. Because the prefix has changed, though, these scripts now don’t work on an M1-based Mac.
    • WireGuard has a dependency on Bash. Unfortunately, the version of Bash supplied by macOS isn’t supported by WireGuard (it’s too old). Without a very specific PATH configuration, even installing the Homebrew version of Bash—which is supported by WireGuard—won’t help. (You’ll have to install it anyway; Homebrew requires it to satisfy a dependency.)

    Fortunately, there is a way to work around these issues. The following steps should enable you to use Homebrew’s WireGuard on your M1-based Mac:

    1. Go ahead and use brew install to install the “wireguard-go”, “wireguard-tools”, and “bash” packages.
    2. Edit your shell startup file(s) to modify your PATH variable in such a way so that a personal directory—like $HOME/bin or similar—is listed first, followed by the /opt/homebrew/bin directory. (I think the order of the /opt/homebrew/bin directory in the PATH may not matter, but I need to do more testing before I’ll know for certain.)
    3. Copy the wg-quick script installed by Homebrew into the personal directory specified in the previous step. This is necessary because the script is read-only in the location where Homebrew installs it.
    4. Edit the shebang line of the wg-quick script to say #!/usr/bin/env -P/opt/homebrew/bin bash. Basically, you’re adding -P/opt/homebrew/bin to the shebang line, right before bash. (You can check man env to understand what the -P parameter does, but the “TL;DR” is that you’re limiting where env will search to find a bash binary.)
    5. On or about line 44, the script defines a variable named CONFIG_SEARCH_PATHS. Edit this line to add /opt/homebrew/etc/wireguard to the existing list of directories that the script will search for the WireGuard configuration files.

    Once you’ve done these steps, you can proceed with configuring WireGuard as outlined in a variety of articles and posts. Replace any references to /usr/local/etc/wireguard in these posts with /opt/homebrew/etc/wireguard.

    When you run sudo wg-quick up wg0 to activate the VPN, your shell will find your modified version of this script first (because of step 2 above). This means your changes to the script will be in effect. Your modified version of this script will find the Homebrew-installed version of Bash (because of the change made in step 4, limiting where env will look to find the bash binary), which is compatible with WireGuard and will allow the script to complete properly. Finally, because you added the /opt/homebrew/etc/wireguard directory to the list of paths that wg-quick will search for WireGuard configuration files, it will find your configuration files and appropriately configure the interface(s).

    The steps described above should get you a working WireGuard installation on an M1-based Mac. Hopefully, I can contribute these changes (or improved versions of these changes) back to the Homebrew project. If you have questions, or if I have made a mistake in my recommendations, please contact me on Twitter. I hope you find this useful!

    …

    Read MoreMaking WireGuard from Homebrew Work on an M1 Mac

    21 Jun, 2021
    Kubernetes Port Names and Terminating HTTPS Traffic on AWS
    Cloud

    I recently came across something that wasn’t immediately intuitive with regard to terminating HTTPS traffic on an AWS Elastic Load Balancer (ELB) when using Kubernetes on AWS. At least, it wasn’t intuitive to me, and I’m guessing that it may not be intuitive to some other readers as well. Kudos to my teammates Hart Hoover and Brent Yarger for identifying the resolution, which I’m going to call out in this post.

    This AWS Premium Support post outlines the basic scenario:

    • You’re running Kubernetes on AWS. The post references EKS, but as far as I know the issue is not limited to EKS, and should apply to self-managed Kubernetes clusters on AWS (assuming these clusters are configured with the AWS cloud provider).
    • You’ve published a Service of type LoadBalancer (which, in turn, creates a classic ELB). For self-managed clusters, this requires the AWS cloud provider to be installed and configured.
    • You want to terminate HTTPS traffic on the ELB. The post references the use of an ACM certificate, but I suspect it’s not limited to ACM certificates.

    Consider the following YAML, taken directly from the previously-referenced AWS Premium Support article:

    apiVersion: v1
kind: Service
metadata: name: echo-service annotations: # Note that the backend talks over HTTP. service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http # TODO: Fill in with the ARN of your certificate. service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:{region}:{user id}:certificate/{id} # Only run SSL on the port named "https" below. service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
spec: selector: app: echo-pod ports: - name: http port: 80 targetPort: 8080 - name: https port: 443 targetPort: 8080 type: LoadBalancer

    I’d like to draw your attention to the service.beta.kubernetes.io/aws-load-balancer-ssl-ports annotation provided in the YAML above. The value of the annotation is "https", which is the name commonly given to TCP port 443 (it’s how the port number is referenced in /etc/services, for example). The ports field, farther down in the spec, specifies port 443, so all should be golden, right?

    Sort of. This configuration works, certainly. The unintuitive thing here is captured, albeit ambiguously, in the comment directly above the annotation: Only run SSL on the port named “https” below. The “name” being referenced here isn’t the name that the port number is commonly given; no, it’s the name assigned in the Kubernetes Service definition itself. This example is ambiguous because “https” is the name most commonly associated with port 443.

    Let’s change the above YAML to make it more clear. Consider this Service definition—will it work?

    apiVersion: v1
kind: Service
metadata: name: echo-service annotations: # Note that the backend talks over HTTP. service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http # TODO: Fill in with the ARN of your certificate. service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:{region}:{user id}:certificate/{id} # Only run SSL on the port named "https" below. service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
spec: selector: app: echo-pod ports: - name: http port: 80 targetPort: 8080 - name: http-tls port: 443 targetPort: 8080 type: LoadBalancer

    If you said “No,” give yourself a hearty round of applause, because you’re correct! Although the Service is still referencing port 443 (commonly referred to and often considered “named” as HTTPS), the annotation is incorrect. In this case, the annotation needs to reference “http-tls”, which is the name assigned to the port in the Kubernetes Service definition. The correct annotation would be service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "http-tls". If the port had been named “green” in the Service definition, then the correct annotation would be service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "green".

    It seems obvious once you figure it out (as do most things), but it most certainly was not intuitive to me. Hopefully sharing this information here will help others avoid falling into a similar trap. Hit me up on Twitter if you have questions or comments.

    …

    Read MoreKubernetes Port Names and Terminating HTTPS Traffic on AWS