Boundary worker 0.1.3 fails when using controller IPs

Boundary
#1

Boundary 0.1.3 is broken and needs to be pulled. While it might work with local sockets, it won’t work with any valid unicast controller IPs.

Dec 23 21:13:25 boundary-worker-1 boundary[377038]: Controller address "10.10.10.1" is invalid: cannot be a global unicast address
Dec 23 21:13:25 boundary-worker-1 systemd[1]: boundary-worker.service: Main process exited, code=exited, status=1/FAILURE

Details of the problem and a fix are in Reverse server's incorrect test for globalUnicast IPs by jorhett · Pull Request #843 · hashicorp/boundary · GitHub

#2

I realize that it’s holiday vacation, but I’m a little perturbed that a bug this impactful made it past testing, and has been left unattended for over a week.

#3

I am also facing the issue while hosting in GCP. At this point of time, looks like there is no workaround.

image
image1120×40 24.5 KB

#4

Thanks for raising this @jorhett, and apologies for the delay. Looking into this is a priority for the team. Myself or @jeff will be circling back with this thread early next week.

#5

FWIW, it’s actually quite simple: the code there was a brain fart while attempting to ward off global multicast addresses – and we don’t currently have a test harness using globally routable IPs, so none of our tests caught it. Such a test harness is on the way but it’s early days for Boundary.

As for being unattended for over a week, I’ll note that the company is on holiday shutdown and the code is fully open source. If rolling back to 0.1.2 is not possible, it’s pretty trivial to fix this yourself (as you did).

We’ll release a 0.1.4 this upcoming week with this addressed.