New release?

[AlexanderS]

Would it be possible to tag a release? The last tag is from long ago and does not contain the recent enhancements from last year. I would like to try to create a package for Debian and it would be nice to use a clean upstream version.

Thanks.

[r-pufky]

I will get this updated this week. Apologies -- life happened and got a bit busy with other things!

[AlexanderS]

No problem, I just created an addition PR. Would be great if this could be part of the new release, too.

[r-pufky]

Thanks - taking a look at it today.

[r-pufky]

@AlexanderS - quick question -

Given that this is now using a configuration file to set the adapter for initramfs, I can't see a reason not to just ingest a wireguard config from /etc/wireguard, with the initramfs config focused solely on:

• Identifying where that config file is.
• Additional key options (e.g. loading the preshared key, etc).
• Additional boot-time workarounds required for platforms (setting date for pi's, MTU's, etc).

This reduces the complexity of the scripts, leaves the configuration to a single place (while separating initramfs specific configuration), which is testable by the user before running initramfs generation, and keeps this focused solely on generating good results for boot configs (e.g. setting date for pi's, MTU's, etc).

I was consolidating all of the previous merges and testing functionality and it seems a large portion of it is now no longer needed with the addition of config file loading versus directly setting the interface in the early days.

Thoughts?

[AlexanderS]

I personally would still prefer a separate config in /etc/wireguard-initramfs/, but I see the advantages of adhering to the default WireGuard configuration file format.

My suggestion is to use:

• /etc/wireguard-initramfs/config for settings unrelated to the WireGuard tunnel itself (e.g., INTERFACE, DATETIME_URL, PERSISTENT, and optionally CONFIG for customizing the filename if the following file)
• /etc/wireguard-initramfs/<interface>.conf for the actual WireGuard tunnel configuration.

We could theoretically also set MTU in /etc/wireguard-initramfs/config, but since wg-quick already supports extracting it directly from the WireGuard config file (https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash#n59), it’s maybe better if we also use this information from there.

This approach ensures all settings are defined once, minimizes user configuration effort, and allows the WireGuard tunnel configuration to be tested independently (e.g., via wg-quick).

To integrate this cleanly, we could parse the WireGuard configuration during initramfs build-time and extend the shell config file with the required additional information (or generate a new one). This would simplify tunnel activation in the initramfs environment.

I think we would need at least Address, AllowedIPs, MTU, and maybe DNS from the interface configuration. wg-quick supports some other features, but I think it is fine to support only a subset if we document the supported features.

Any thoughts? I can prepare a pull request if you think that's a good approach.

[r-pufky]

I personally would still prefer a separate config in /etc/wireguard-initramfs/, but I see the advantages of adhering to the default WireGuard configuration file format.

My suggestion is to use:

• /etc/wireguard-initramfs/config for settings unrelated to the WireGuard tunnel itself (e.g., INTERFACE, DATETIME_URL, PERSISTENT, and optionally CONFIG for customizing the filename if the following file)
• /etc/wireguard-initramfs/<interface>.conf for the actual WireGuard tunnel configuration.

We could theoretically also set MTU in /etc/wireguard-initramfs/config, but since wg-quick already supports extracting it directly from the WireGuard config file (https://git.zx2c4.com/wireguard-tools/tree/src/wg-quick/linux.bash#n59), it’s maybe better if we also use this information from there.

I basically went down this path yesterday, keeping the initramfs configuration to strictly needed options to stand-up the link, and leaving the rest of the configuration to the actual wireguard config. Effectively:

initramfs settings:

• ADAPTER - path to wg config to use.
• DATETIME_URL - set local datetime.
• PERSISTENT - persist after boot.

Adapter settings that are copied from the config file:

• INTERFACE_ADDR_IPV4
• INTERFACE_ADDR_IPV6
• INTERFACE_MTU
• PEER_ALLOWED_IPS_IPV4
• PEER_ALLOWED_IPS_IPV6

everything else effectively gets removed because it is now configured by the user in the adapter config. IPV4 and IPV6 settings are kept separate to minimize regex parsing for IP identification and enabling dual-stack configurations.

To integrate this cleanly, we could parse the WireGuard configuration during initramfs build-time and extend the shell config file with the required additional information (or generate a new one). This would simplify tunnel activation in the initramfs environment.

I started playing with this last night too. There's a few issues:

• initramfs configuration - these are outside of the adapter configuration specifically related to how initramfs works.
• adapter configuration - these can either be generated by the user, parsed, or set in config.

The problem is that the wireguard adapter file is a form of .ini, with multiple repeated values, and a mix in of IPv4 and IPv6 specifications. When bringing up the links, IPv4 and IPv6 awareness is required for AllowedIps, as well as dual-stack installations.

The data from the configuration file itself would need to be pre-processed and stored in a file (which would not be the initramfs config, but a separate third file) that would be parsed during boot without support of more advanced tooling like sed and grep. So you're left in a bit of pickle where you need to generate a configuration file or statically set the bare minimum adapter configuration to stand-up the interface.

I think we would need at least Address, AllowedIPs, MTU, and maybe DNS from the interface configuration. wg-quick supports some other features, but I think it is fine to support only a subset if we document the supported features.

Any thoughts? I can prepare a pull request if you think that's a good approach.

I'll push the branch I was working on yesterday evening and tag it in this thread. It's cleaned up a bunch of stuff but hasn't gotten to the parsing of the config file yet (plan was to get the idea working and move to parsing complex configurations; effectively getting the initramfs configuration down to as minimal as possible; and then updating the migration script accordingly from a 2023-10-21 format to a new minimal (and would likely be, permenant format).

[r-pufky]

https://github.com/r-pufky/wireguard-initramfs/tree/migrate_config

As a side note, I've gotten a proof of concept that uses the installed wg-quick script and calls parse_options() to parse the wireguard adapter config.

[r-pufky]

@AlexanderS - heya, I just pushed the last change to the 'migrate_config' branch, which should:

• allow wg, wg-quick choice for managing wireguard
• move all adapter configuration to standard well know user location (/etc/wireguard/{adapter}.conf
• integrate previous merges after 2023-10-21 and resolve conflicts, many introduced bugs, etc.

Should effectively get the repo in a state where it is release ready, pending raspbeery pi testing (I don't have one).

Branch is located here: https://github.com/r-pufky/wireguard-initramfs/tree/migrate_config

I saw there were a few pull requests from you just now from a bit earlier today - would you like me to roll those into main before merging this branch, or re-apply after branch is merged?

[r-pufky]

@AlexanderS - everything is merged, tested, and updated to main. Please take a look. I don't have an Raspberry Pi to do that verification, but all other tests now pass.

Will push a new release if I don't here anything back by this weekend.