Skip to content

Conversation

@PRESFIL
Copy link
Contributor

@PRESFIL PRESFIL commented Oct 25, 2025

Description

Basic implementation of AmneziaWG protocol support.

Run vopono exec --protocol AmneziaWG --custom ./awg.conf 'curl ifconfig.me' to test it.

Closes: #335

"PersistentKeepalive",

// AmneziaWG extended parameters
"Jc",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, check could be simply invert — removing only those keys that you manually process
further down the function. Then there will be no need to keep this list up to date.

Also, wireguard_config.rs always prints:

WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: Jc
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: Jmin
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: Jmax
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: S1
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: S2
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: H1
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: H2
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: H3
WARN  vopono_core::network::wireguard_config  > Unknown key in [Interface] section: H4
WARN  vopono_core::network::wireguard_config  > Unknown key in [Peer] section: PresharedKey

Does it matter? Parsing should be implemented even if parameters are not used vopono directly?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can just use an if else here to only add the extra keys in the Amnezia case no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're talking about wireguard_config.rs, I'm not entirely clear where to add if-else.

In wireguard.rs, I tested changes from #336 (comment)
working as expected but not commited.

@PRESFIL
Copy link
Contributor Author

PRESFIL commented Oct 25, 2025

I recently noticed a connection stability issue that needs to be resolved
to merge the PR. But I'm not sure what to do yet.

The connection drops every minute, which can be seen by running ping 8.8.8.8:

dmesg
06:40 host kernel: amneziawg: vo_c_T9pdrpn: Sending keepalive packet to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
06:40 host kernel: amneziawg: vo_c_T9pdrpn: Sending handshake initiation to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
06:40 host kernel: amneziawg: vo_c_T9pdrpn: Sending dummy junk packets to 10 (XXX.XXX.XXX.XXX:SRV_PORT)
06:40 host kernel: amneziawg: vo_c_T9pdrpn: Receiving handshake response from peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
06:40 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 73 created for peer 10
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Retrying handshake with peer 10 (XXX.XXX.XXX.XXX:SRV_PORT) because we stopped hearing back after 15 seconds
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Sending handshake initiation to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Sending dummy junk packets to 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Receiving handshake response from peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 74 created for peer 10
07:12 host kernel: amneziawg: vo_c_T9pdrpn: Sending keepalive packet to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:38 host kernel: amneziawg: vo_c_T9pdrpn: Retrying handshake with peer 10 (XXX.XXX.XXX.XXX:SRV_PORT) because we stopped hearing back after 15 seconds
07:38 host kernel: amneziawg: vo_c_T9pdrpn: Sending handshake initiation to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:38 host kernel: amneziawg: vo_c_T9pdrpn: Sending dummy junk packets to 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:39 host kernel: amneziawg: vo_c_T9pdrpn: Receiving handshake response from peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
07:39 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 73 destroyed for peer 10
07:39 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 75 created for peer 10
07:39 host kernel: amneziawg: vo_c_T9pdrpn: Sending keepalive packet to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Retrying handshake with peer 10 (XXX.XXX.XXX.XXX:SRV_PORT) because we stopped hearing back after 15 seconds
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Sending handshake initiation to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Sending dummy junk packets to 10 (XXX.XXX.XXX.XXX:SRV_PORT)
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Receiving handshake response from peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 74 destroyed for peer 10
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 76 created for peer 10
08:05 host kernel: amneziawg: vo_c_T9pdrpn: Sending keepalive packet to peer 10 (XXX.XXX.XXX.XXX:SRV_PORT)
08:23 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 75 destroyed for peer 10
08:23 host kernel: amneziawg: vo_c_T9pdrpn: Keypair 76 destroyed for peer 10
08:23 host kernel: amneziawg: vo_c_T9pdrpn: Peer 10 (XXX.XXX.XXX.XXX:SRV_PORT) destroyed

awg-quick doesn't cause such issue. Here are the operations it performs, on set up interface:

[#] ip link add awg1 type amneziawg
[#] awg setconf awg1 /dev/fd/63
[#] ip -4 address add <internal_ip>/32 dev awg1
[#] ip link set mtu <MTU> up dev awg1
[#] resolvconf -a awg1 -m 0 -x
[#] awg set awg1 fwmark 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip -6 route add ::/0 dev awg1 table 51820
[#] ip6tables-restore -n
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] ip -4 route add 0.0.0.0/0 dev awg1 table 51820
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

On shutdown:

[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev awg1
[#] resolvconf -d awg1 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

All AmneziaWG options passed in to awg, I checked this by adding debug log:

Inverted check and config dump
diff --git a/vopono_core/src/network/wireguard.rs b/vopono_core/src/network/wireguard.rs
index 86e7c27..e79b1d3 100644
--- a/vopono_core/src/network/wireguard.rs
+++ b/vopono_core/src/network/wireguard.rs
@@ -76,43 +76,25 @@ impl Wireguard {
             // TODO: Maybe properly parse ini format
 
             // Valid keys for wireguard config (see wg(8):CONFIGURATION FILE FORMAT)
-            let allow_keys = [
-                "PrivateKey",
-                "ListenPort",
-                "FwMark",
-                "PublicKey",
-                "PresharedKey",
-                "AllowedIPs",
-                "Endpoint",
-                "PersistentKeepalive",
-
-                // AmneziaWG extended parameters
-                "Jc",
-                "Jmin",
-                "Jmax",
-                "S1",
-                "S2",
-                "H1",
-                "H2",
-                "H3",
-                "H4",
+            let parsed_keys = [
+                "Address",
+                "DNS",
+                "MTU",
             ];
 
             let mut f = std::fs::File::create("/tmp/vopono_wg.conf")
                 .context("Creating file: /tmp/vopono_wg.conf")?;
-            write!(
-                f,
-                "{}",
-                config_string
-                    .split('\n')
-                    .filter(|x| x
-                        .split_once('=')
-                        .map(|(key, _)| allow_keys.contains(&key.trim()))
-                        // If line doesn't include an =, don't filter it out
-                        .unwrap_or(true))
-                    .collect::<Vec<&str>>()
-                    .join("\n")
-            )?;
+            let content = config_string
+                .split('\n')
+                .filter(|x| x
+                    .split_once('=')
+                    .map(|(key, _)| !parsed_keys.contains(&key.trim()))
+                    // If line doesn't include an =, don't filter it out
+                    .unwrap_or(true))
+                .collect::<Vec<&str>>()
+                .join("\n");
+            println!("{}", content);
+            write!(f, "{}", content)?;
         }
         let config = Self::config_from_file(&config_file)?;
 

@PRESFIL
Copy link
Contributor Author

PRESFIL commented Oct 25, 2025

Similar issue: amnezia-vpn/amneziawg-linux-kernel-module#30

@PRESFIL
Copy link
Contributor Author

PRESFIL commented Oct 26, 2025

ping 8.8.8.8 in vopono -v exec --protocol None --provider None bash environment
(without vopono.conf, there are some bugs) doesn't cause packet loss. Bare awg-quick
also doesn't cause packet loss.

Looks like problem in namespace / routing, I'm not sure what to do next to find cause of
periodical disconnects of awg.

P.S. --no-kill-switch doesn't helps

@PRESFIL
Copy link
Contributor Author

PRESFIL commented Oct 26, 2025

I don't know how I came up with this idea 😄

  1. vopono -v exec --protocol None --provider None bash (without vopono.conf)
  2. Insider environment run sudo awg-quick up ~/.config/awg1.conf
  3. ping 8.8.8.8

Result: some ping responses come, but periodical disconnects / reconnects happens.

@PRESFIL PRESFIL force-pushed the feat-protocol-amneziawg branch from 5106e34 to 06fafd5 Compare October 30, 2025 22:14
@PRESFIL
Copy link
Contributor Author

PRESFIL commented Oct 30, 2025

The network issues I've been experiencing for the last month appear to
be related not to vopono, but to my local network/ISP (they occur on different
devices and different AWG implementations – amnezia-go, wireproxy-awg,
and the awg kernel module). Since the issue isn't with vopono, we can
continue with the PR.

@jamesmcm
Copy link
Owner

Thanks, I'll see if I can set it up to test on my VPS this weekend.

@jamesmcm
Copy link
Owner

jamesmcm commented Nov 2, 2025

LGTM, it'd be good to create a later PR with more details for the user guide (e.g. setting it up headlessly etc.) - it's a pain it requires so much set up with the kernel changes and so on.

@jamesmcm jamesmcm merged commit 7d4d9d4 into jamesmcm:master Nov 2, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature Request] Way to override wireguard-go and wireguard-tools

2 participants