Can't for my life open port 51413 for Transmission

[QuikSilver]

Thanks, but it still doesn't work.

You didn't read the article it seems.....Since that's the case this is my last reply.....Delete the last profile (51413). Edit the top one and change the "local port" to be 51413 not 11167. The outside port 11167 needs to be open......which internally will point to 51413 (on 192.168.1.28 it seems). The answers have been given to you but your not following.

 

[ColinTaylor]

I think we're confusing different things now.

Port forwarding in the router's GUI only effects the router's WAN interface. It has no effect on the VPN connection.

 

[QuikSilver]

I think we're confusing different things now.

Port forwarding in the router's GUI only effects the router's WAN interface. It has no effect on the VPN connection.

Your right. I forget that Dave found another post regarding VPN.


Sent from my iPhone using Tapatalk

 

[Salles]

I also have a problem with the Transmission port 51413 being closed.
I have read through the forum and this topic seems to be the closest to my issue.

I have Asus RT-AC86U with firmware 384.15 with a hard drive connected to the router via USB and used as a NAS.
I have Transmission 3.00+ running Transmission through Debian, according to this setup.
Transmission is routed through VPN-client 1 (using Torguard) on the local IP-address 192.168.50.10 through this setup.
I have enabled port forwarding of port 51413 on Torguards website.

However, Transmission shows in the settings that port 51413 is closed. This testsite also shows that the port is closed.
I do not seem to be able to figure out myself what the issue is in my setup, so I am asking for help.

FYI. I have also tried putting the following in the nat-start script and making that executable. However, that resulted stopped downloads and uploads. I am doing something wrong .

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
iptables -I FORWARD -i tun11 -p udp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 51413 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 51413 -j DNAT --to-destination 192.168.50.10

 

[raven-au]

I had similar problems when I tried to setup deluge over a vpn.

It sounds like there's a need to understand what's happening and work out a way to verify each part of the packet traversal. The first part would be to verify the provider port is being forwarded. You might be able to verify that by setting something up on Windows using the provider VPN app to check the port is forwarded.

Once you know the port is forwarded consider what you have, an external address and port, <unknown, 11167>, connecting to the VPN provider with packets being sent to the VPN internal address (provider) end to port 11167, forwarded to the VPN client end to port 51413.

I guess that should get you packets on the router bridge with a destination port of 51413 so forwarding <anything, 51413> to the IP of the Transmission client should work assuming the VPN client config incoming firewall has been disabled.

Whether you need to forward from the VPN network device (or IP, that you probably can't rely on the always be the same) to br0 at all is another question, not sure about. It looks like you should but the VPN client should setup routes to do that and this is internal to the router, not external, so firewall rules probably shouldn't be needed at all. So check the route table after establishing the VPN and ensure your getting packets, maybe your VPN configuration is not pulling all the configuration or is not setting everything up properly.

Perhaps a host route from the VPN client device to the IP address of the Transmission client is enough.
iptables rules to ensure the incoming port traffic can't go anywhere else would probably be wise but, AFAICS, shouldn't be needed.

But I also couldn't get this to work and ended up setting up a container that included the torrent client and openvpn so that everything is local to that instance, and the container developer sets up the (fairly simple) iptable rules needed and that worked. The one I used was based on one originally done for Transmission.

Ian

 

[raven-au]

Perhaps a host route from the VPN client device to the IP address of the Transmission client is enough.
iptables rules to ensure the incoming port traffic can't go anywhere else would probably be wise but, AFAICS, shouldn't be needed.

Mmm … so I see that there's a Merlin wiki page for manual setup of split tunnel VPN client routing which is needed for the RT-N66U. I think you mentioned you already tried that, putting the wiki script into firewall-start.

Looks like it takes care of the routing and adds needed iptables rules, including those needed to masquerade the output from the client. But those rules might not be allowing incoming connections, not sure, perhaps someone else can explain exactly what that script does so you can verify if it should do what you want.

 

[Salles]

Mmm … so I see that there's a Merlin wiki page for manual setup of split tunnel VPN client routing which is needed for the RT-N66U. I think you mentioned you already tried that, putting the wiki script into firewall-start.

Looks like it takes care of the routing and adds needed iptables rules, including those needed to masquerade the output from the client. But those rules might not be allowing incoming connections, not sure, perhaps someone else can explain exactly what that script does so you can verify if it should do what you want.

I am using Policy Based Routing in the WebUI, which works fine.
I am also using this script i firewall-start (and have for some time) in order to route and incoming VPN-server through my VPN-client when connecting from e.g. a phone or computer outside of my network and route it through the VPN-client. It do not see have it could affect this.

# Allow pass-thru for a connecting OpenVPN Server client to use Selective Policy routing RPDB out via VPN Client
iptables -D POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE
iptables -I POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE

 

[Salles]

I had similar problems when I tried to setup deluge over a vpn.

It sounds like there's a need to understand what's happening and work out a way to verify each part of the packet traversal. The first part would be to verify the provider port is being forwarded. You might be able to verify that by setting something up on Windows using the provider VPN app to check the port is forwarded.

Once you know the port is forwarded consider what you have, an external address and port, <unknown, 11167>, connecting to the VPN provider with packets being sent to the VPN internal address (provider) end to port 11167, forwarded to the VPN client end to port 51413.

I guess that should get you packets on the router bridge with a destination port of 51413 so forwarding <anything, 51413> to the IP of the Transmission client should work assuming the VPN client config incoming firewall has been disabled.

Whether you need to forward from the VPN network device (or IP, that you probably can't rely on the always be the same) to br0 at all is another question, not sure about. It looks like you should but the VPN client should setup routes to do that and this is internal to the router, not external, so firewall rules probably shouldn't be needed at all. So check the route table after establishing the VPN and ensure your getting packets, maybe your VPN configuration is not pulling all the configuration or is not setting everything up properly.

Perhaps a host route from the VPN client device to the IP address of the Transmission client is enough.
iptables rules to ensure the incoming port traffic can't go anywhere else would probably be wise but, AFAICS, shouldn't be needed.

But I also couldn't get this to work and ended up setting up a container that included the torrent client and openvpn so that everything is local to that instance, and the container developer sets up the (fairly simple) iptable rules needed and that worked. The one I used was based on one originally done for Transmission.

Ian

Could you explain what port 11167 has to do with anything in my setup (and here a bit of the knowledge gap )?

I do not really reboot my router so the VPN-IP will probably be the same for a long time, but of course I will need to check that in the future (once I get this to work ).

Since my nat-start script does not seem to work, I will need to play around more. Is there away to manually restart nat-start scripts? Does firewall restart do this or does that only restart the script firewall-start?

 

[faria]

Port 11167 is your front door in this case, if you dont open it how is mister vpn client supposed to get in?
Once you open the front door then it will lead the traffic to port 51413 as long you follow post #21.

Also service firewall_restart

 

[raven-au]

I am using Policy Based Routing in the WebUI, which works fine.

But @AnnaX has an RT-N66U so it will be necessary for her to setup the Policy Based Routing infrastructure manually.

I am also using this script i firewall-start (and have for some time) in order to route and incoming VPN-server through my VPN-client when connecting from e.g. a phone or computer outside of my network and route it through the VPN-client. It do not see have it could affect this.

# Allow pass-thru for a connecting OpenVPN Server client to use Selective Policy routing RPDB out via VPN Client
iptables -D POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE
iptables -I POSTROUTING -t nat -s $(nvram get vpn_server1_sn)/24 -o tun1+ -j MASQUERADE

Umm, right, maybe not.

Above you mentioned you were using a script very similar to the one in the Merlin manual setup Wiki but IIUC that should already be done for you in Merlin releases that have Policy based routing included.

The question is are incoming connections allowed by the policy based routing setup.
Certainly I couldn't get it to work.

Someone more familiar with iptables will need to explain what the built in scripts are doing and what the wiki scripts are doing to verify whether incoming connections should work or not. In particular what change is made to the built in scripts when setting the incoming firewall to off in the VPN client config and for the wiki manual config why incoming connections should be allowed by the rules in the Wiki.

My casual glance makes me wonder how incoming connections can get through this:

iptables -I INPUT -i tun11 -j REJECT

which looks like it blocks everything for VPN client 1 but there are so many different paths through the various rule sets I don't know what this actually means.

 

[raven-au]

Could you explain what port 11167 has to do with anything in my setup (and here a bit of the knowledge gap )?

The OP is using that external port with her VPN provider forward.
If you hijack a thread you probably need to expect comments that relate to the OP as well as your own.

I do not really reboot my router so the VPN-IP will probably be the same for a long time, but of course I will need to check that in the future (once I get this to work ).

Since my nat-start script does not seem to work, I will need to play around more. Is there away to manually restart nat-start scripts? Does firewall restart do this or does that only restart the script firewall-start?

Don't know but before looking into anything else it's necessary to establish if what's used in the two cases, the included Policy Based Routing and the manual method scripts should work. Only then is it worth looking further.

 

[Salles]

Port 11167 is your front door in this case, if you dont open it how is mister vpn client supposed to get in?
Once you open the front door then it will lead the traffic to port 51413 as long you follow post #21.

Also service firewall_restart

Could you please explain where I can read that port 11167 is the front door in my case?
It is the case of the OP.
How can I tell which is the external port in my case? Is there a way to determine through which external ports all the packages are being sent for Transmission (or in general so I could see through which ports large amount of data is being transferred)?

 

[Salles]

My casual glance makes me wonder how incoming connections can get through this:

iptables -I INPUT -i tun11 -j REJECT

which looks like it blocks everything for VPN client 1 but there are so many different paths through the various rule sets I don't know what this actually means.

I do not really understand it either, since this code stops the downloading.

The OP is using that external port with her VPN provider forward.
If you hijack a thread you probably need to expect comments that relate to the OP as well as your own.

True, could have explained even more.

 

[faria]

Could you please explain where I can read that port 11167 is the front door in my case?
It is the case of the OP.
How can I tell which is the external port in my case? Is there a way to determine through which external ports all the packages are being sent for Transmission (or in general so I could see through which ports large amount of data is being transferred)?

Sorry my mistake , got confuse here, in your case the front door is port 51413 , you need to forward it to 192.168.50.10

 

[raven-au]

Sorry my mistake , got confuse here, in your case the front door is port 51413 , you need to forward it to 192.168.50.10

That is confusing because I'm pretty sure the standard port forwards relate to traffic coming in via the public IP of the WAN port whereas this traffic is coming in via the VPN interface, bypassing the WAN interface, and ending up on the internal network.

 

[maxbraketorque]

Have you had your VPN provider direct th

I also have a problem with the Transmission port 51413 being closed.
I have read through the forum and this topic seems to be the closest to my issue.

...

Have you had your VPN provider point port 51413 to your VPN connection? You seem pretty knowledgeable about networking, so I'm guessing that you've already done this, but still thought I should mention it.

 

[Salles]

Have you had your VPN provider direct th


Have you had your VPN provider point port 51413 to your VPN connection? You seem pretty knowledgeable about networking, so I'm guessing that you've already done this, but still thought I should mention it.

Yes. I have enabled port forwarding of port 51413 on Torguards website.
No, unfortunately I am not that knowledgable. Most things I know from networking I have learnt from this great forum.

 

[Salles]

Sorry my mistake , got confuse here, in your case the front door is port 51413 , you need to forward it to 192.168.50.10

Ok. So I have forwarded 51413 from Torguard VPN.
Unfortunately, I do not understand is what I should type in nat-start or firewall-start to get transmission to return the connection through the VPN .
Do you have any idea what is wrong here?

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
iptables -I FORWARD -i tun11 -p udp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 51413 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 51413 -j DNAT --to-destination 192.168.50.10

 

[raven-au]

Ok. So I have forwarded 51413 from Torguard VPN.
Unfortunately, I do not understand is what I should type in nat-start or firewall-start to get transmission to return the connection through the VPN .
Do you have any idea what is wrong here?

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
iptables -I FORWARD -i tun11 -p udp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport 51413 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun11 -p udp --dport 51413 -j DNAT --to-destination 192.168.50.10

That's the big question isn't it.
The above are filtering rules but routing is what directs packets to where they should go.

But all this must depend on what version of the Merlin firmware your using.
Recent releases should do all the filtering and routing setup for you as long as you use Policy Rules and specify the device ip in the policy section, and disable the incoming firewall. I can't remember the exact option now and don't have a Merlin install around to look.
Next thing to do would be to work out what scripts are called for the given VPN client and inspect them to try and work out what's preventing the incoming packets reaching the client or preventing replies being sent to where they need to go.

 

[Salles]

That's the big question isn't it.
The above are filtering rules but routing is what directs packets to where they should go.

But all this must depend on what version of the Merlin firmware your using.
Recent releases should do all the filtering and routing setup for you as long as you use Policy Rules and specify the device ip in the policy section, and disable the incoming firewall. I can't remember the exact option now and don't have a Merlin install around to look.
Next thing to do would be to work out what scripts are called for the given VPN client and inspect them to try and work out what's preventing the incoming packets reaching the client or preventing replies being sent to where they need to go.

I am on 384.15 for now on my RT-AC86U. Perhaps I should upgrade to 384.17 then .
I see, the routing rules via iptables would then be reduntant.
Well, I am certain that the policy section is set accordingly. Would you mind explaining what you mean by disable incoming firewall an internal ip-address? Perhaps I am missing something here...