I hope that the keys you've shared in this post are not real (or have been otherwise manipulated). If they're the real keys, they should be destroyed since they can now be assumed compromised due to exposure on the internet.
Meanwhile, this appears to be a 'client' type connection to a commercial VPN. I'm not sure why you would need to export this from OpenWrt, as it would not be useful as an exported entity. (I can understand the need to import, but export is meaningless here).
Can you describe specifically what your goal is here?
The keys are not working))) And yes. If you look from this angle, then maybe imports)))
Drag the file with the mouse onto the window in Luci.
Strange implementation. Usually a dialogue with opening a file is implemented, but here it’s drag and drop.
Also in 2 windows.
The function is there, but it doesn't work correctly.
Purpose of the post. If the function exists, it should work correctly so that you don’t have to enter this data manually later.
Also, very often after a connection break, the WG interface does not rise automatically or even manually. It says that the interface was not found. Although the WAN is up and running at this time without any problems.
A complete reboot of the router is required to restore operation.
Let’s review the config that you’ve got running now.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
But the data I wrote about in these lines was entered manually and naturally everything works.
The equipment to which this router is connected reboots once a day at the same time. After this, problems occur with the WG interface, but not every time.
You can use the file I posted for tests. Naturally, the VPN will not work due to fake keys, but how the Luci interface handles it in the plugin settings will be visible.
Because in your file the data for IPV4 and 6 is entered on one line, but in mine IPV4 and IPV6 are in separate lines. Likewise,
MTU is not processed as a separate line)))
No. This is a processing error by the plugin.
My file clearly states what this parameter is.
And where did you get the idea that your file is correct, and not mine? Because it coincided almost 100% with the plugin’s processing algorithm?
But that's not true.
MTU in a new line with an explicitly specified parameter in which line it should be imported, but this does not happen.
Line
Address =
Must write data in the plugin field of the same name, the following line
Address =
You must write the corresponding data in a new field of the same name.
And so on.
MTU to the MTU line, but this does not happen.
Mm yes.
My file is more correct than yours due to the fact that not all providers work with the IPV6 protocol.
Any user can remove them from my file before importing, but from yours only the one who knows what the IPV4 and 6 addresses look like and where one ends and the other begins.
In general, you need to repair the plugin.
list addresses '172.16.0.2/32'
list addresses '2606:4700:110:86f2:5088:3fb5:3f78:b843/128'
This is how it looks in the config, added manually through the plugin interface in Luci.
This can also be done by directly editing the file, I suspect that you have it all in one line, both IPV4 and IPV6, and it’s good if the plugin processes this correctly during its work, and not just when importing data.
And in your file there is no DNS address for IPV6, there is only for IPV4.
Is this also correct?)))
This is how it looks when I import my config and it is just as it expected
config interface 'wg_mullv_us'
option proto 'wireguard'
option private_key 'YGaBrMXXXXXX='
list addresses '10.68.89.7/32'
list addresses 'fc00:bbbb:bbbb:bb01::5:5906/128'
list dns '10.64.0.1'
config wireguard_wg_mullv_us
option description 'mullvad-us-bos-wg-101.conf'
option public_key 'oxJ2XXXXXXXXXXXXXX='
list allowed_ips '0.0.0.0/0'
list allowed_ips '::0/0'
option persistent_keepalive '25'
option route_allowed_ips '1'
option endpoint_host '149.40.50.98'
option endpoint_port '51820'
when I import my config file (well it is not mine it is actually one I get from Mullvad my VPN provider) in the standard Windows or Android client it is also imported and working
I understand why your file is imported almost “correctly” and I indicated where there are shortcomings in your file that are not related to the work of the plugin, but are related to the work of your VPN provider, where there is not enough IPV6 data for correct operation, but nevertheless it works according to IPV4.
list addresses '2606:4700:110:86f2:5088:3fb5:3f78:b843/128'
list addresses '172.16.0.2/32'
This should be added on import, but only one line is imported (which comes first) and the rest are ignored.
And in Luci’s web interface it is there and works.
P.S.
In your file, everything is written on one line, both IPv4 and IPv6. The plugin itself looks for the beginning and end of addresses and creates the correct lines in the config. In my case, these lines are already written separately (correctly), but the plugin ignores everything except the first one.
It appears to be a WARP config generated by wgcf (https://github.com/ViRb3/wgcf). It may have helped if the OP made note of that. In any case, setting up a WARP WG VPN on an OpenWrt device works here.
Lastly, IPv6 will need some form of NAT for IPv6 installed, as WARP only issues a single /128 IP for the peer config. IPv4 on the other hand can simply be configured to use masquerade. This is normal and expected behavior. IPv6 will only work on the OpenWrt otherwise.
This is all good, I can find someone who can configure the file for the plugin, but I want to find someone who can repair the plugin.
Be that as it may, the MTU parameter is not imported, but it should be. Maybe some other ones are not imported, but I don’t know about that yet.)))
