ANSWERED WireGuard constantly fails to connect

[ohshitgorillas 0]

I am running a kubernetes wireguard pod with an airvpn config, however, it takes many many tries to finally connect.

Here are the logs from the pod:

Uname info: Linux bittorrent-69db796885-q6lfl 6.2.0-39-generic #40-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:18:00 UTC 2023 x86_64 GNU/Linux
**** It seems the wireguard module is already active. Skipping kernel header install and module compilation. ****
**** Client mode selected. ****
[custom-init] No custom files found, skipping...
**** Disabling CoreDNS ****
**** Found WG conf /config/wg_confs/wg0.conf, adding to list ****
**** Activating tunnel /config/wg_confs/wg0.conf ****
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
Try again: `america3.vpn.airdns.org:1637'. Trying again in 1.00 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 1.20 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 1.44 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 1.73 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 2.07 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 2.49 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 2.99 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 3.58 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 4.30 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 5.16 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 6.19 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 7.43 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 8.92 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 10.70 seconds...
Try again: `america3.vpn.airdns.org:1637'. Trying again in 12.84 seconds...
Try again: `america3.vpn.airdns.org:1637'
Configuration parsing error
[#] ip link delete dev wg0
**** Tunnel /config/wg_confs/wg0.conf failed, will stop all others! ****
**** All tunnels are now down. Please fix the tunnel config /config/wg_confs/wg0.conf and restart the container ****
[ls.io-init] done.

The tunnel config is below with sensitive information redacted:

[Interface]
Address = 10.145.xxx.xxx/32, fd7d:76ee:e68f:xxxx:xxxx:xxxx:xxxx:xxxx/128
PrivateKey = <redacted>
MTU = 1320
DNS = 10.128.0.1, fd7d:76ee:e68f:a993::1
PostUp = DROUTE=$(ip route | grep default | awk '{print $3}'); HOMENET=192.168.0.0/16; HOMENET2=10.0.0.0/8; HOMENET3=172.16.0.0/12; ip route add $HOMENET3 via $DROUTE; ip route add $HOMENET2 via $DROUTE; ip route add $HOMENET via $DROUTE; iptables -A OUTPUT -d $HOMENET -j ACCEPT; iptables -A OUTPUT -d $HOMENET2 -j ACCEPT; iptables -A OUTPUT -d $HOMENET3 -j ACCEPT; iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = <redacted>
PresharedKey = <redacted>
Endpoint = america3.vpn.airdns.org:1637
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 15

this happens with ca3, america3, and europe3.vpnairdns.org

I am on the verge of needing a new vpn provider cause this is getting ridiculous, I can't connect at all

what's going on?

Edited ... by ohshitgorillas

[Staff 9767]

3 hours ago, ohshitgorillas said:

Quote

Configuration parsing error
...
Please fix the tunnel config /config/wg_confs/wg0.conf and restart the container

what's going on?

Hello!

According to WireGuard your configuration file can't be parsed. A probable cause of the parsing error is the PostUp line you created, as all the other directives seem correct and created by our Configuration Generator. Please comment it out or delete it and check whether the problem gets resolved or not. If so, you have the confirmation that the error is there. In this case execute manually the various PostUp commands (with the container connected to the VPN) and check whether any error is thrown out to discern a strictly related parsing problem from a problem caused by the failure of one of the commands.

Be aware that the VPN subnet (10.128.0.0/12) overlaps with one of the subnets (10.0.0.0/8) for which you want to create a route back to your host via $DROUTE. Also note that you don't have a PreDown line, which is strictly necessary when the system disconnects from the VPN to clean up the routing table and the firewall rules. Even when the parsing error is fixed, the missing clean up may prevent future connections, so we would recommend that you write proper commands (to be executed with PreDown) deleting your custom routes and firewall rules.

What is the exact purpose you want to achieve with that PostUp line?

Kind regards
 

[ohshitgorillas 0]

Just to follow up, I switched back to Docker where I used to host the containers before I moved them to Kubernetes, and it connected immediately. I think the problem is with Kubernetes networking.