24.02.004
Released on 29 February, 2024.
Client
Fixes
- At 24.01.001 an upgrade of a dependency caused changes in behavior on MacOS which meant the Bowtie icon appeared in the task switcher and the dock. This has been resolved.
Known Issues
- There is a known issue where the Bowtie tray application sometimes fails to start successfully on Windows. The Bowtie service will still be running, you may continue without the tray application. You can restart the tray application by searching for “Bowtie” in the windows menu, by clicking on C:\Program Files\Bowtie\24.02.004\bin\bowtie.exe or by restarting your computer.
Features
- When IPv4 Support is enabled on the controller for a given device, A
records are no longer dropped by default. DNS Strategies are designated
on the control plane, per managed name.
In prior versions, if a domain was set up with the DNS64 flag, and DNS returned an IPv4 address within a range set up with NAT64 rules, Bowtie would return 0 records for A requests and return DNS64 answers for AAAA requests.
This has been relaxed. Now, in the above scenario if the IPv4 address is routable, the A record response is not squashed.
- When IPv4 Support is enabled on the controller for a given device, A records are no longer dropped by default. DNS Strategies are designated on the control plane, per managed name.
- Bowtie now refuses to install IPv4 routes that conflict with local
system routes.
For instance, if you have a Bowtie site with a 192.168.4.0/22 network and you use it on a computer that is connected to a 192.168.4.0/22 network, Bowtie will not install routes to the Bowtie 192.168.0.0/22 network to ensure that it does not break local connectivity.
This also applies when the Bowtie network length is shorter than the local network. If the Bowtie site is 192.168.4.0/22 and the local network is 192.168.0.0/20 Bowtie will not install routes the Bowtie 192.168.0.0/22 to ensure that it does not break local connectivity.
Operating systems preferentially route to the most specific network so if the Bowtie site has a network length longer than the local network, Bowtie routes are installed. For example, if the Bowtie site is 192.168.4.0/22 and the local network is 192.168.5.0/24, Bowtie will install routes for 192.168.4.0/22. The operating system will route 192.168.5.0/24 to the local network, but the rest of the Bowtie network will be accessible.
Servers located on the Bowtie site network can be accessed via NAT64 if they are not accessible via IPv4.
Server
Fixes
- A write lock was erroneously held through a read operation which did not close the transaction. Additionally an error in rolling back that transaction causes an unrecoverable panic. In some cases this cascades through the cluster. The offending operation has been repaired.
- Fixed an issue that caused updated control plane web assets to be incorrectly cached, causing inconsistent behavior after updating Controllers.
Features
- Controller images are now available in AWS GovCloud. See the Bowtie downloads page for AWS for a list of regions including those hosted in GovCloud.
- The DNS configuration page can now be sorted and filtered.
- Beta policy evaluation tool in the policy area. This page is for debugging and understanding the policy engine. It will show you the current state of the policy engine, and allow you to see how it is evaluating a given request.
Enhancements
- Updated the base network Controller appliance operating system to
reflect the latest upstream package updates. This includes patch version
updates to Grafana as well as patches to recent CVEs in packages like
glibc.
This update includes an update from Linux kernel version 6.1.75 to 6.1.78. System services should continue to operate normally across kernel updates, but if you require that the system run on the newer kernel, you should follow-up with any update actions with a system reboot to run on the newer kernel, but this step is not required.
Helm Chart
Fixes
- Fixed an issue that caused the Bowtie server container to fail to emit its correct version string.
Features
- The Helm chart now accepts a list of environment variables to set under
the server.env key for arbitrary settings like changing RUST_LOG
to debug with a values file like the following:
server: env: - name: RUST_LOG value: debug