nahamu (LIBERA-IRC): Wow, I didn't think it would be this easy: `pkgin in tailscale` thank you so much for the effort you put into making WireGuard work smoothly on illumos

teutat3s: I'm glad it's working for you!!

jperkin did the packaging, and jclulow did the original port of wireguard-go, not to mention the original authors of Wireguard and Tailscale etc. etc.

But yeah, that smooth simplicity of use is why I've been willing to keep maintaining the fork and working on getting things upstream.

nahamu (LIBERA-IRC): To me it looks like your upstreaming effort is really close to getting merged, if there's anything I can contribute, like testing, lemme know

teutat3s: Honestly, the biggest help would be exercising the wireguard-go and wireguard-tools bits.

Exercising?

Should also be packaged in pkgsrc.

Try it out. See if it works or if there's an obvious bug I've missed.

Understood, will do and report back

It's not as easy as Tailscale, but even just a "I got it to work" or "I tried X and it should have worked but failed" would be great!

WireGuard/wireguard-tools #17 is the relevant PR. I can also sketch some documentation if you've never used wg-quick before.

There's some generic wg-quick related content in blog.shalman.org/wireguard-android-road-warrior

The existing code should be at least beta quality. If a few other people don't trip over anything obvious it should be good enough to get upstream to ship it.

That's convenient, I'm working on getting wireguard working on some smartos instances of mine this morning. I've been making linux instances and am cleaning up the number of VMs

nahamu jclulow thanks for all your work!

copec: let me know how it goes!

It just worked, when initially setting up manually (I just saw the packages in pkgin), it's pretty neat that wg works the same with wireguard-go

How do I set up a service with /opt/local/lib/svc/manifest/wireguard-tools.xml for say a tun0 instance?

I would name it something more meaningful and let wireguard-go allocate the specific instance.

Let me know if you need additional detail.

ah, thank you much

nahamu How do you get wg-quick to specify a (sacrificial) remote address? unaen.org/pb/7uv

hmmm

let me see what I have lying around

can you strip the keys out of your config file and paste it somewhere?

sure

perhaps just remove the "/32" from the address specifications?

Yeah, I would try removing the "/32"

Do you use those on Linux?

yeah, I use them on linux

Thank you for finding a bug!

Can you confirm for now whether things work if you remove them?

yeah, just tried, it is working now

I notice it uses the same ip for local and remote

and adds the route for each individual endpoint, nice

copec: WireGuard/wireguard-tools #17#issuecomment-1456664190

ty nahamu

thanks for kicking the tires!!

copec: I think I have a fix for you to test.

So my link to this instance seems to do about 250Mbit outside the tunnel, and 50Mbit inside the tunnel, and it doesn't appear the wireguard-go process is CPU limited. That is still sufficient for what I am doing, but I would enjoy tracing the performance aspects of it

if you can manually make that change to the wg-quick script and see if that fixes it for you, that would be helpful.

it seemed to fix things for me.

I'll try that now

If there's enough momentum to get this stuff upstream, the fix might not make it to the pkgsrc package until after the upstreaming.

copec: any luck?

yup, it is working, both with the /32 and without

Nice. Thanks!

danmcd: see that race in that gist for deploying to cloudapi ?

I didn't... sorry, hold on.

@Smithx10 it seems the "check-for-same-alias-as-user" is something that isn't concurrent against multiple simultaneous creations.

I know little about triton-go, and even less about terraform.

teutat3s: are you still using boringtun?

papertigers (LIBERA-IRC): yeah, but will test the pkgsrc wireguard-go version this week

I wonder if packaging boringtun in pkgsrc would make it somehow possible to choose the wireguard user space backend with something like wg-quick

I think the way I ported the wg-quick code you could pass it a different binary in an environment variable.

yeah, I'm even doing that in my example SMF manifest.

papertigers: are you still maintaining your boringtun fork and/or is your stuff upstream?

its not, but I was going through my gh notifications and I saw a question from copecog; which I am going to guess is copec?

Did you figure out your issue?

nahamu: I haven't used it in a long time, but teutat3s was keeping the branch up to date every so often

ah

papertigers I haven't figured out why it wasn't building yet

were you building it off of the branch in my fork of the repo?

copec: github.com/papertigers/boringtun/tree/illumos-eventports

But I also just noticed there's a PR that needs to be merged from teutat3s that does a more recent sync.

I was using that branch, but I was probably doing something wrong

I'll try it again

fwiw I haven't tried in awhile, if you can gist or put the build output somewhere I can try and find time to look. We probably should merge teutat3s's PR as I believe they have been using that since the PR was open in july without issue

danmcd: Yea, probably have to add that into cloudapi

I tried two VMAPI ones but one failed with colliding-alias. Gonna see if I can make them Go Faster at launch time.

Ahhh, there we go.

[root@shemp (kebecloud) ~]# vmadm list |grep kebe

187fc88f-1cea-4263-9b91-c676bdbaf180 OS 256 running kebetests

992da0fc-63df-4836-9563-38ef917929ed OS 256 running kebetests

[root@shemp (kebecloud) ~]#

I did it with two concurrently-started sdc-vmapi invocations.

So is this *really* going to be a big problem? Protecting against such races would cause some major-league slowdowns (esp in Manta).

Smithx10: Basically the workaround for that is you should name things `myvm-{{shortId}}` (i.e., literally the exact string {{shortId}}). Then {{shortId}} will be replaced with the zone uuid prefix.

Smithx10: e.g.,: 8bc86cde manta-shortener-8bc86cde base-64-lts⊙24 running - 29w

danmcd: and bahamat its not really a big problem

I was wondering it it may break anything down the line

TIL about `{{shortId}}`

I dont think so.... except for same DNS.

Using {{shortId}} is how to guarantee you're not going to race on alias names.

And I think you can only run into this when you have multiple workflow instances (but I may be wrong, you might still be able to do it with only one)

Yea, I just gotta tell the users / send a warning

Just wanted to make sure it wasnt just me

We are planning on centralizing the terraform deployments so I can probably check this before we go to CloudAPI too

Yeah, with terraform especially, I recommend using shortId

But...I don't know, terraform is often very brain damaged when it comes to that kind of thing. It *really* doesn't like the cloud filling in details for it.

Protip for testing:

I had to fight tooth and nail to get them to be ok with network pools existing.

"starting-pistol" protocol

Invoke multiple of whatever you want concurrently running either with:

low-res: (sleep <longtime> ; CMD )& (multiple times)

pkill sleep <and off to the races>

high-res: cat & (will suspend in background on tty input)

One of my main blockers for using terraform was that it wouldn't work with network pools. You'd provision something and on every pass it would destroy/create again because the interface uuid was the network not the pool and for weeks they refused to fix it.

(pwait $PID_OF_CAT ; CMD ) & (multiple times)

fg %1 (cat)

^D on cat <and off to the races>

Ultimately they said if I wanted it fixed it would need to be documented. I pointed them at the existing documentation and they complained about the way it was phrased, so I had to rewrite the doc to appease them, and finally the begrudgingly fixed it.

Wow.

Awfully nice of them. :upside_down:

It was maddening.

It was also very difficult to get them to fix their broken data storage in manta plugin so that we could have a shared terraform deployment.

bahamat (LIBERA-IRC): sadly they dropped support for the manta storage backend in 1.3

papertigers (LIBERA-IRC): yeah no issues here with that PR, been running it since then

teutat3s: cool! I will merge it

done

copec: ^ heads up if you want to redo your experiment with newer bits. Someone should find time to do another sync with upstream at some point.

yay, I'll give it a try

papertigers (LIBERA-IRC): Thanks! I always waited for a tagged release, but yeah, syncing with the master branch would also be possible

Feel free to keep it in sync with the strartegy you have been using

wondering if I should transfer these bits to the illumos github rather than my account

teutat3s: I'm not surprised, with how badly it was broken.

papertigers (LIBERA-IRC): I'd say yes, could make it more discoverable

jclulow: any thoughts on me transferring the boringtun fork to the illumos github org? Instead of having it live under my github

I'm not opposed per se, but who would look after it?

well, teutat3s has been it's primary user I belive and has done the most work keeping it up-to-date. But if they don't want the burden it can just stay under my gh. It's not a big issue

I can continue to look after it : )