Project

General

Profile

Issue #3168

Transmission (downloader via torrent) peer port is closed when strongSwan is on

Added by Tom Hsiung 9 months ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.6.2
Resolution:
No change required

Description

Hello, sir / madam

I use transmission 2.94 to download files via torrent. However, when I connect to my strongSwan server in the manner of roadwarrior mode, the peer port is shown as closed. Without the IPsec on, the peer port is on. I want to know how to solve this issue.

Thank you

Tom

History

#1 Updated by Tobias Brunner 9 months ago

  • Status changed from New to Feedback

What do you mean exactly? Are you talking about some kind of port-forwarding to the client? If so, just configure such a thing on the server.

#2 Updated by Tom Hsiung 9 months ago

Hello, Tobias.

I think the software use automatic method to make the server reachable from outside (such that other peers could find my machine). Interestingly, on my NAT gateway, I don't set up any port-forwarding iptables rules (to let outside initiators able to connect my client behind the NAT gateway). I only set up NAT rules (so that my client initiators behind the NAT gate could connect Internet).

I also set up NAT rules for my remote strongSwan servers. But I don't know why this issue happened.

Tom

#3 Updated by Tom Hsiung 9 months ago

I think something is wrong with the NAT-PMP / UPnP technology. Some thing must broken after I turn on the strongSwan, which makes the NAT-PMP / UPnP of the software on clients behind NAT gateway not working.

So, manual NAT port forwarding iptables rule(s) is plausible. But, my clients connected to strongSwan server don't have fixed virtual IP addresses. How to deal with this issue?

Thank you

Tom

#4 Updated by Tobias Brunner 9 months ago

I think something is wrong with the NAT-PMP / UPnP technology. Some thing must broken after I turn on the strongSwan, which makes the NAT-PMP / UPnP of the software on clients behind NAT gateway not working.

These methods are mostly intended to work in LANs. PCP (NAT-PMP's successor) is more flexible, but that definitely requires additional configuration and a daemon (or plugin) on the VPN server (to handle requests on UDP port 5351 and install those firewall rules) to even have a chance of working (whether the client application would actually do so via VPN is another question).

So, manual NAT port forwarding iptables rule(s) is plausible. But, my clients connected to strongSwan server don't have fixed virtual IP addresses. How to deal with this issue?

Via updown or vici event script.

#5 Updated by Tom Hsiung 9 months ago

Do some technologic methods exist, for example, to assign virtual IP address based on the physical network card's MAC?

It's difficult, because of the following complicated cases:

1) It's roadwarrior mode, because my gateway to Internet gets a public IP address from my ISP and the IP is dynamic. So a site to site IPsec connect might be impossible.
2) I have more than one clients, which I use to connect my strongSwan server. These clients all have jobs to download files via transmission, a peer-to-peer torrent downloader.
3) storngSwan assigns dynamic (virtual) IP addresses to clients, which makes manual DNAT iptables rules difficult to identify a specific client.
4) Even if strongSwan is able to assign fixed IP address to a particular client (via MAC-to-IP pertinent one-to-one mapping), the NAT gateway (on which strongSwan is running) has troubles to manually set iptables rules that could distribute traffic flows from outside to correct client, i.e., two clients are communicating with the Internet simultaneously to download, and there are traffic initiating from outside to both clients.

#6 Updated by Tobias Brunner 9 months ago

Do some technologic methods exist, for example, to assign virtual IP address based on the physical network card's MAC?

The client's MAC address has absolutely no relevance in regards to IPsec (the VPN server will never see it, unless it is in the same LAN). But some backends allow the assignment of virtual IPs based on the client's identity (see VirtualIP).

#7 Updated by Tobias Brunner 8 months ago

  • Category set to configuration
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

#8 Updated by Tom Hsiung 8 months ago

I think I partially figured it out. I notice that the issue is caused by the IPsec gateway. Something related to UPnP or NAT-PMP has to be installed on the IPsec gateway, so that the port could be access from outside. This is what I did and it works for transmission.

apt install transmission-daemon

Additional packages will be installed, for which I think are critical for port opening.

The following NEW packages will be installed:
  libminiupnpc10 libnatpmp1 transmission-common transmission-daemon

After that, the peer port is open on clients in the software of transmission. Now that the daemon of transmission-daemon is associated, which means if you stop the daemon of transmission-dademon, the port on clients would be closed.

Tom

Also available in: Atom PDF