aMuled in a wireguard namespace - lowID

[MitraMai]

Hello!
I've setup aMuled on my homeserver.
aMule-flatpak is started within a wireguard namespace, and I've opened the relevant ports (both TCP/UDP) in both the VPN-provider dashboard (OVPN) and the firewall (iptables). Still aMule can not see the open ports.
I also have Transmission and slskd running in the same namespace, with open ports, which works just fine, and the aMule ports show as open when I test them with a port checker.
So, the difference between Transmission, slskd and aMule is that aMule is starts and runs within the namespace, while the other services start in the regular namespace, and then I connect to them in the wireguard namespace (if this now makes any difference). Reason for this is that I can't get flatpak-aMule to start and then connect/move over to the wireguard-namespace.
Now... this is not a catastrophe, since I still have around 15 mb download, which is a great improvement from the earlier versions of aMule. But it bothers me that I can't get it to work.
Is there someone here that can point me in the right directions? Using chat-GPT or similar just leads down the rabbit-hole.

EDIT: Forgot to mention that it happens that I get a HighID in Ed2k, but for the KAD-network the ports always appears as closed.

[got3nks]

The split you're seeing (ed2k HighID sometimes, Kad always firewalled) usually means only one of the two ports is actually reachable.

Unlike Transmission and slskd, aMule needs two ports, and by default they are different numbers:

• TCP 4662 - ed2k client connections. This is what decides HighID.
• UDP 4672 - client UDP and Kad. Kad uses the same UDP port as the client UDP setting.

Most VPN providers forward a single port, so ed2k can get a HighID while Kad never sees an incoming UDP packet. An external port checker won't contradict that, since those checks are effectively TCP-only.

Go to Networks -> Kad and look at these two rows:

• Connection State: - the TCP side
• UDP Connection State: - the UDP side

Each is either OK or Firewalled - open TCP/UDP port N in your router or firewall, and it prints the actual port number aMule is using. If TCP says OK and UDP says firewalled, that confirms the diagnosis above and tells you exactly which port number needs forwarding.

Worth trying: set both the TCP and the UDP port (Preferences -> Connection) to the single number your provider forwarded. The same number for both is fine, they're separate protocols, and it lets one forwarded port serve both. The numbers matter because aMule advertises the port it binds, so a forward that maps an external port to a different internal one won't work either. Also check UDP isn't disabled on that page.

If UDP still reports firewalled with the port genuinely forwarded, the remaining suspect is the VPN's NAT type: aMule determines its external Kad port by asking peers which source port they saw and needs 2 of 3 to agree. A provider that assigns a different source port per destination fails that, and aMule then stops trusting the port for firewall checks. That one is a property of the provider rather than something to configure locally.

[MitraMai]

Nah, sorry, perhaps I was unclear. My VPN-provider let me open five ports in total, which I've done. So I have the ports 59995, 59998 and 59992 (TCP+3, UDP) open. And then one for Transmission and one for slskd. I tried to set the TCP and the UDP to 59995. Did not work (both protocols are forwarded on 59995, and opened in iptables).
So I guess it is something with the VPN's NAT then. I had got HighID when I used OpenVPN though, same provider and the same ports. And then aMule did not run within a namespace.

[got3nks]

Thanks, that changes the picture - five forwarded ports and TCP=UDP already tried, so scratch my single-port theory.

The useful detail is the last line: same provider, same ports, OpenVPN and no namespace gave you a HighID. That mostly clears the provider's NAT and points at the namespace itself.

Two things that would narrow it down:

1. What do the two Kad rows actually say? In Networks -> Kad, Connection State: (TCP) and UDP Connection State: (UDP). If TCP says OK and only UDP is firewalled, that is a very different problem from both being firewalled, and worth knowing before changing anything else.

2. Take aMule out of the loop. Inside the namespace, listen on the forwarded port and send something to it from outside:

ip netns exec <ns> nc -u -l -p 59995

If nothing arrives, the problem is upstream of aMule - routing or filtering in the namespace - and no aMule setting will fix it. Same test with nc -l -p 59995 for TCP.

The usual culprit there is that iptables rules live per namespace. Rules added in the host namespace do not apply to traffic arriving on the wg interface inside the namespace; they have to be added with ip netns exec <ns> iptables .... Worth confirming which side yours are on.

One more, since it is release-visible: check the aMule log at startup for a line like

WARNING: configured network interface '...' was not found - traffic is NOT bound to it

If Preferences -> Connection has a network interface set, and that interface name does not exist inside the namespace, aMule says so at startup.

[MitraMai]

I created a namespace for aMule and OpenVPN which works and gives me HighID and KAD-access without the firewall-warning. If I give Wireguard and aMule another try, I'll try out what you suggests.
One question though, I can't find the option to set the interface in the GUI. Under connection I'm only able to set the ports, and the different options that comes with the port settings. I'm using the aMulegui though, to connect to my server.

[got3nks]

The option exists, but not in anything you can have installed yet: "Bind to network interface" was added after 3.0.1 was released, so no released build has it. It is on master, due in 3.1.0.

Two things worth knowing before you go looking for it:

• In amulegui it is a plain text box, not a drop-down. That is deliberate: the daemon's interfaces are not your GUI machine's interfaces, so there is nothing sensible to enumerate. On Preferences -> Connection you type the daemon-side name (tun0, wg0, eth0).
• Both sides need updating. The value travels to the daemon over External Connect, and that plumbing landed separately, so a new amulegui pointed at a 3.0.1 amuled would write into a field the daemon ignores. Update amuled on the server and amulegui.

If you want to try it now, here are the current development builds from master (3.0.1-788-gab4f3640a). These are snapshots, not a release - fine for testing, and worth keeping your config backed up.

Linux

Format	x86_64	aarch64
Flatpak (.flatpak bundle)	download	download
AppImage	download	download
Static tarball	download	download

Windows

Format	x64	ARM64
Installer (.exe)	download	download
Portable (.zip)	download	download

macOS

Format	Universal (Intel + Apple Silicon)
.dmg	download

Notes on those links: GitHub requires you to be signed in to download workflow artifacts, each download is a .zip wrapper around the file named above (GitHub always zips them), and they expire on 2026-12-01. The macOS .dmg contains both aMule.app and aMuleGUI.app.

Since your daemon is the Flatpak, the Flatpak bundle plus a matching amulegui for whatever you run the GUI on is the combination to test.