Tunnel Clients replcating

[KD4WLE]

Describe the bug

After switching some clients to Wireguard, unable to delete the old tunnel on the CLIENT. Old entry will reappear after removal or renaming. Seems to occur on multiple nodes.

Tunnel client(s) is on a Proxmox VM

• [Yes ] Does this issue still occur on the latest version? (Required)

Expected behavior

Old tunnel entry should be removed

Screenshots

Please include a screenshot of your system information (if possible) if the specific system environment is relevant to the bug.

[aanon4]

Can you clarify a few things:

1. You say the old entries reappear when deleted, but that seems different from what I see here which is that they get duplicated. Is it that when you delete an entry, you end up with two instead? If so, when do you see two? Immediately after the deletion/after you press save/after you refresh the page .. or something else?
2. Have you seen this on other nodes?
3. Does this only happen for legacy (non wireguard tunnels) or for all kinds?
4. Is it a specific entry which causes problems? Like maybe just the top one?
5. Can you provide detailed instructions to reproduce this? Step by step so I can do exactly what you're doing.
6. Please provide support data for the node immediately after a failed attempt to delete a tunnel.
   Thanks

[KD4WLE]

1 * Once I disable or delete the old entry and save, if I exit the screen and then come back, it will be back. (Refreshig wont cause the issue, only if you leave the Tunnel Client page and then return) * If I just disable the entry, once I leave the page, the disabled entry will be there along with another active (checked) entry. 2 * This seems to happen on Proxmox/x86 nodes. I’m not seeing it on a MikroTik hAP lite 3 * I have only seen it on legacy tunnels. 4 * Not 100% sure, I will need to create the situation and verify. 5 * I’ll enter the data in Tunnel Client for the new Wireguard tunnel Server,Password/Key and Network * Click ADD * Disable OLD tunnel * Enable NEW tunnel * Save Changes * Wait for the Wireguard tunnel to come up * Delete OLD tunnel * Save Changes * Goto ANY other page, IE – Mesh Status, check node entry shows as (wg,active) * Return to Tunnel Client All old tunnels removed [A screenshot of a server Description automatically generated] Exit page and return [A screenshot of a computer Description automatically generated] Edit out server name, save.. [A screenshot of a computer Description automatically generated] Returned to this [A screenshot of a computer Description automatically generated] Just disable save exit and return. [A screenshot of a computer Description automatically generated] And the client will attempt to connect to the server… Mon Mar 4 23:06:45 2024 daemon.info vtund[8950]: Connecting to titusvillemesh.kd4wle.net Mon Mar 4 23:06:45 2024 daemon.err vtund[8950]: Auth failed, server denied password for host N4TDX-SWARM-172-31-99-240 Mon Mar 4 23:06:45 2024 daemon.info vtund[8950]: Connection denied by titusvillemesh.kd4wle.net Mon Mar 4 23:06:50 2024 daemon.info vtund[8950]: Connecting to titusvillemesh.kd4wle.net Mon Mar 4 23:06:50 2024 daemon.err vtund[8950]: Auth failed, server denied password for host N4TDX-SWARM-172-31-99-240 Mon Mar 4 23:06:50 2024 daemon.info vtund[8950]: Connection denied by titusvillemesh.kd4wle.net Mon Mar 4 23:06:55 2024 daemon.info vtund[8950]: Connecting to titusvillemesh.kd4wle.net Mon Mar 4 23:06:55 2024 daemon.err vtund[8950]: Auth failed, server denied password for host N4TDX-SWARM-172-31-99-240 Mon Mar 4 23:06:55 2024 daemon.info vtund[8950]: Connection denied by titusvillemesh.kd4wle.net 6 * Two support files, first one was after I disabled and deleted the duplicate tunnel, then again when I left the page and returned. Just in case. From: Tim Wilkinson ***@***.***> Date: Monday, March 4, 2024 at 6:29 PM To: aredn/aredn ***@***.***> Cc: Sean Haga (KD4WLE) ***@***.***>, Author ***@***.***> Subject: Re: [aredn/aredn] Tunnel Clients replcating (Issue #1109) Can you clarify a few things: 1. You say the old entries reappear when deleted, but that seems different from what I see here which is that they get duplicated. Is it that when you delete an entry, you end up with two instead? If so, when do you see two? Immediately after the deletion/after you press save/after you refresh the page .. or something else? 2. Have you seen this on other nodes? 3. Does this only happen for legacy (non wireguard tunnels) or for all kinds? 4. Is it a specific entry which causes problems? Like maybe just the top one? 5. Can you provide detailed instructions to reproduce this? Step by step so I can do exactly what you're doing. 6. Please provide support data for the node immediately after a failed attempt to delete a tunnel. Thanks — Reply to this email directly, view it on GitHub<#1109 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGVV6IXRS6F7A3KZ2BFV4HTYWT7T5AVCNFSM6AAAAABEGC73Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGY2DONJYGI>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[aanon4]

So is this only happening when the server name is the same? I'm wondering ... you create a new tunnel with the same server before deleting the old one. Not saying that shouldnt work, but I'm wondering if that's key?

[aanon4]

PS. I didnt see any support files.

[KD4WLE]

Odd, attaching again From: Tim Wilkinson ***@***.***> Date: Tuesday, March 5, 2024 at 12:21 AM To: aredn/aredn ***@***.***> Cc: Sean Haga (KD4WLE) ***@***.***>, Author ***@***.***> Subject: Re: [aredn/aredn] Tunnel Clients replcating (Issue #1109) PS. I didnt see any support files. — Reply to this email directly, view it on GitHub<#1109 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGVV6IUN7NG5OPM44YVN3QDYWVI7FAVCNFSM6AAAAABEGC73Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHE4DQOJRGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[KD4WLE]

Yes, I am making the same server name before deleting the old one. From: Tim Wilkinson ***@***.***> Date: Tuesday, March 5, 2024 at 12:11 AM To: aredn/aredn ***@***.***> Cc: Sean Haga (KD4WLE) ***@***.***>, Author ***@***.***> Subject: Re: [aredn/aredn] Tunnel Clients replcating (Issue #1109) So is this only happening when the server name is the same? I'm wondering ... you create a new tunnel with the same server before deleting the old one. Not saying that shouldnt work, but I'm wondering if that's key? — Reply to this email directly, view it on GitHub<#1109 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGVV6IQU74UV6B6G5JECCY3YWVHYTAVCNFSM6AAAAABEGC73Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHE4DAMRQGM>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[KD4WLE]

supportdata-N4TDX-Mims-Swarm-202403042338.gz
supportdata-N4TDX-Mims-Swarm-202403042339[11].gz

[aanon4]

I've made a change which will provide me with tunnel information in the support data (it's not there today) dump. The change will be available tomorrow (March 6th). Could you update and re-run your steps to generate the error and reset the support data?
Also, because there's a process continually unsuccessfully trying to reconnect to the server, the log file fills up very quickly pushing out the more relevant information, so please gather the support data as quickly as you can after the delete fails.

[KD4WLE]

20240306-2cda75e applied. Support Data attached.

supportdata-N4TDX-Mims-Swarm-202403061655.tar.gz

[aanon4]

Thanks.
So at the top of the file /etc/config.mesh/vtun there is a 'config server' entry which doesn't have a name. I'm not sure how it got there because the code doesn't create these without names and the property order is not how the code creates them (which doesnt matter functionally, except it means it wasn't created by the current code).
Anyway, can you try deleting this by hand, run /usr/loca/bin/node-setup and reboot, and see if your node behaves correctly again?

[KD4WLE]

This appears to work, Any entry that did not have a name associated with it was removed. There were quite a few. Point of interest, n4tdx-mims-swarm, the node in question is fairly new and was built using aredn-20240206-4523eb3-x86-64-generic-ext4-combined.img and seems to occur on all my Promox nodes. From: Tim Wilkinson ***@***.***> Date: Wednesday, March 6, 2024 at 12:16 PM To: aredn/aredn ***@***.***> Cc: Sean Haga (KD4WLE) ***@***.***>, Author ***@***.***> Subject: Re: [aredn/aredn] Tunnel Clients replcating (Issue #1109) Thanks. So at the top of the file /etc/config.mesh/vtun there is a 'config server' entry which doesn't have a name. I'm not sure how it got there because the code doesn't create these without names and the property order is not how the code creates them (which doesnt matter functionally, except it means it wasn't created by the current code). Anyway, can you try deleting this by hand, run /usr/loca/bin/node-setup and reboot, and see if your node behaves correctly again? — Reply to this email directly, view it on GitHub<#1109 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BGVV6IVV72EOKUBFIOVQOTDYW5FOJAVCNFSM6AAAAABEGC73Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGM4DOMJRGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[aanon4]

I have a half dozen proxmox nodes, including tunnel server and supernodes, and I've not seen this problem on any of them (I just quickly checked all their config file and all the entries have names). Also, the tunnel code doesnt care in anywway about the hardware, so it's not clear why this would be confined to proxmox nodes. I'm going to assume your proxmox nodes are being made from scratch and not cloned?

So I'm closing this. Please reopen if you find a way to reproduce from a fresh install. I'll poke around in the code some more in case there's some other bit creating tunnels (I cant imagine there is).