Can't for my life open port 51413 for Transmission

[raven-au]

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.

But iptables doesn't route, it filters, both routing (to get packets to go where they should) and filters (eg. masquerade when needed etc.) do just that filter and perhaps modify packets as they pass through or drop, or reject etc.

I don't know for sure but 384.15 should have the client split-tunnel functionality already so what's needed should already be present. The challenge is understanding what scripts are executed and when so that you can inspect them to see if you can identify where incoming packets/connections are being blocked.

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...

As I say I don't have a Merlin install available atm. but there is an option (a radio button, that I saw when I last looked) on the client VPN setup page in one of the sections toward the top whose text include words like "incoming" and "block". I can't remember the wording but it should stand out if you look for it. It certainly looked like it should be what's needed to allow incoming connections. Working out why it doesn't is probably the key to solving this problem.

Ian

 

[Salles]

But iptables doesn't route, it filters, both routing (to get packets to go where they should) and filters (eg. masquerade when needed etc.) do just that filter and perhaps modify packets as they pass through or drop, or reject etc.

I don't know for sure but 384.15 should have the client split-tunnel functionality already so what's needed should already be present. The challenge is understanding what scripts are executed and when so that you can inspect them to see if you can identify where incoming packets/connections are being blocked.



As I say I don't have a Merlin install available atm. but there is an option (a radio button, that I saw when I last looked) on the client VPN setup page in one of the sections toward the top whose text include words like "incoming" and "block". I can't remember the wording but it should stand out if you look for it. It certainly looked like it should be what's needed to allow incoming connections. Working out why it doesn't is probably the key to solving this problem.

Ian

Yes, in VPN Client the is setting for Inbound Firewall which I have now set to Allow. It was set to Block before. I moved Transmission to VPN Client 2 because of this. Most computer at home are routed via VPN Client 1 which has it set to Block. Figure I mention that if it matters.
Port 51413 is now forwarded for VPN Client 2 on Torguards website and it is still not working .
@Martineau , I know you are very busy with Unbound, but I was wondering if you could give me a tip?

 

[Martineau]

Yes, in VPN Client the is setting for Inbound Firewall which I have now set to Allow. It was set to Block before. I moved Transmission to VPN Client 2 because of this. Most computer at home are routed via VPN Client 1 which has it set to Block. Figure I mention that if it matters.
Port 51413 is now forwarded for VPN Client 2 on Torguards website and it is still not working .
@Martineau , I know you are very busy with Unbound, but I was wondering if you could give me a tip?

If you have already have the appropriate FORWARD/MASQUERADE rules then perhaps you may also need the OpenVPN iroute rule to explicitly expose the LAN subnet behind the OpenVPN Client?

 

[Salles]

If you have already have the appropriate FORWARD/MASQUERADE rules then perhaps you may also need the OpenVPN iroute rule to explicitly expose the LAN subnet behind the OpenVPN Client?

Thank you for replying @Martineau .
I did play around a bit with iptables in nat-start but nothing that results in an open port 51413.

This is what I have now in nat-start. Transmission is on VPN Client 2.

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

I do notice the following outbound block in the firewall regarding Transmission.

May 15 11:05:59 kernel: [BLOCKED - OUTBOUND] IN= OUT=tun12 SRC=192.168.50.10 DST=185.189.114.98 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=38846 DF PROTO=TCP SPT=52429 DPT=53512 SEQ=2537956459 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0063B43C0000000001030306)

May 15 11:06:01 kernel: [BLOCKED - OUTBOUND] IN= OUT=tun12 SRC=192.168.50.10 DST=185.189.114.98 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=38847 DF PROTO=TCP SPT=52429 DPT=53512 SEQ=2537956459 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0063B5060000000001030306)

I removed this part from nat-start since I could not download then.

#iptables -I INPUT -i tun12 -j REJECT

 

[nexus12345]

Did anybody get this up and working ? i.e forwarding a port through VPN Client intreface ?

Edit : Figure out how to make it work..

Create a script by enabling SSH on router and putting the file named 'nat-start.sh' in /jffs/scripts/ ( JFFS should be enabled )
you can create a file in ssh by typing 'vi /jffs/scripts/nat-start.sh'

Paste the content below and change ports / ip as needed

file content below ( ignore -- , do not paste --)
--
#!/bin/sh
touch /tmp/000nat-start
iptables -I FORWARD -i tun12 -p udp -d 172.16.0.78 --dport 49589 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 172.16.0.78 --dport 49589 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 49589 -j DNAT --to-destination 172.16.0.78
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 49589 -j DNAT --to-destination 172.16.0.78

--

change file permission so that it can be executed by typing 'chmod a+rx /jffs/scripts/* '

 

[Salles]

Did anybody get this up and working ? i.e forwarding a port through VPN Client intreface ?

Edit : Figure out how to make it work..

Create a script by enabling SSH on router and putting the file named 'nat-start.sh' in /jffs/scripts/ ( JFFS should be enabled )
you can create a file in ssh by typing 'vi /jffs/scripts/nat-start.sh'

Paste the content below and change ports / ip as needed

file content below ( ignore -- , do not paste --)
--
#!/bin/sh
touch /tmp/000nat-start
iptables -I FORWARD -i tun12 -p udp -d 172.16.0.78 --dport 49589 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 172.16.0.78 --dport 49589 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 49589 -j DNAT --to-destination 172.16.0.78
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 49589 -j DNAT --to-destination 172.16.0.78

--

change file permission so that it can be executed by typing 'chmod a+rx /jffs/scripts/* '

Interesting. I have tried that recently and it does not work for me.
I have the same code in nat-start, not nat-start.sh. I do not see how that can make a difference though.
nat-start also have been executed via chmod (I have other scripts in nat-start which works).
And I have port forwarding set for the correct external IP, with the correct ports at Torguard (port 51413 for both UDP and TCP).

Is there anything else to it? Are you getting this to work for Transmission, by giving Transmission an internal IP-address in the config file?

 

[eibgrad]

Interesting. I have tried that recently and it does not work for me.
I have the same code in nat-start, not nat-start.sh. I do not see how that can make a difference though.
nat-start also have been executed via chmod (I have other scripts in nat-start which works).
And I have port forwarding set for the correct external IP, with the correct ports at Torguard (port 51413 for both UDP and TCP).

Is there anything else to it? Are you getting this to work for Transmission, by giving Transmission an internal IP-address in the config file?

I don't understand how nexus12345's script makes the difference either. Merlin's event handler for nat requires a script by the name 'nat-start' in /jffs/scripts, NOT 'nat-start.sh'. The use of 'nat-start.sh' would only make sense if nexus12345 had created a 'nat-start' script that called 'nat-start.sh'. Maybe that was a detail he left out.

Regardless, there's been a change to the OpenVPN client over the past year that prevents inbound connection attempts by default called "Inbound Firewall". In order for port forwarding to work over the OpenVPN client, that has to be changed from Block to Allow.

 

[Salles]

I don't understand how nexus12345's script makes the difference either. Merlin's event handler for nat requires a script by the name 'nat-start' in /jffs/scripts, NOT 'nat-start.sh'. The use of 'nat-start.sh' would only make sense if nexus12345 had created a 'nat-start' script that called 'nat-start.sh'. Maybe that was a detail he left out.

Regardless, there's been a change to the OpenVPN client over the past year that prevents inbound connection attempts by default called "Inbound Firewall". In order for port forwarding to work over the OpenVPN client, that has to be changed from Block to Allow.

I have set the Inbound Firewall to Allow for VPN Client 2. Still for some reason, it does not work.
Are there more ways to figure out what is incorrect?

 

[eibgrad]

I have set the Inbound Firewall to Allow for VPN Client 2. Still for some reason, it does not work.
Are there more ways to figure out what is incorrect?

Make sure the rules you *think* are there actually got added. And if they are, check if any rules are getting hits (pkts field > 0).

iptables -t nat -vnL PREROUTING
iptables -vnL FORWARD

 

[Salles]

Make sure the rules you *think* are there actually got added. And if they are, check if any rules are getting hits (pkts field > 0).

iptables -t nat -vnL PREROUTING
iptables -vnL FORWARD

Thanks. Here is the output file for both commands. I am not really sure what to be looking for except that I see port 51413 in the table. However, I notice that no packets are being prerouted or forwarded . I have also tried port forwarding for other ports on my computer (in the table) which unfortunately do not work either.

 

[eibgrad]

Thanks. Here is the output file for both commands. I am not really sure what to be looking for except that I see port 51413 in the table. However, I notice that no packets are being prerouted or forwarded . I have also tried port forwarding for other ports on my computer (in the table) which unfortunately do not work either.

If there are no hits on the pkts for either the PREROUTING or FORWARD chain, it means nothing is reaching the firewall inbound from the OpenVPN client.

Who is your VPN provider? Do you know for sure they support VPN port forwarding (most do NOT)? And when they do, they often have stringent requirements, like limiting which ports you have access to on the VPN's public IP. In some cases, it's only a *single* port (e.g., PIA)! And PIA requires a convoluted API to even determine what that port is and to open it.

IOW, you need to tell me a *lot* more about what's happening here. So far, I was just assuming you had messed up the port forwards, and once fixed, it would just work. But now I have to call into question the entire setup.

 

[Salles]

If there are no hits on the pkts for either the PREROUTING or FORWARD chain, it means nothing is reaching the firewall inbound from the OpenVPN client.

Who is your VPN provider? Do you know for sure they support VPN port forwarding (most do NOT)? And when they do, they often have stringent requirements, like limiting which ports you have access to on the VPN's public IP. In some cases, it's only a *single* port (e.g., PIA)! And PIA requires a convoluted API to even determine what that port is and to open it.

IOW, you need to tell me a *lot* more about what's happening here. So far, I was just assuming you had messed up the port forwards, and once fixed, it would just work. But now I have to call into question the entire setup.

Thank you for taking your time.

The VPN provider is Torguard. They do allow Port Forwarding, which I have setup on their website, by requesting a port forward and receiving an accept of that port being forwarded.
- The IP on Torguards website corresponds to the Public IP on my VPN Client 2 setup in Asus WebUI, together with the protocol UDP and port 1195.
- The requested ports on Torguards website corresponds to the ports of Transmission 51413. I have requested both UDP and TCP to be open for port 51413.
- According to Torguards website, packets are being sent to the VPN IP of my VPN Client 2, but as stated in my previous post I cannot see any packets in Putty when typing the commands you gave me.
See attached pictures of VPN Client setup in the WebUI and the setup at Torguards website.

Is their anyway of checking if Transmission is really using the port 51413 as an external port, by for example checking which port is sending a lot of packages?

 

[eibgrad]

Is their anyway of checking if Transmission is really using the port 51413 as an external port, by for example checking which port is sending a lot of packages?

It's irrelevant at this point, since there are NO HITS on the PREROUTING chain of the nat table. IOW, according to your iptables dump, there is no remote access activity. And so whatever the ultimate target of your port forwarding may be (transmission, rdp, plex, etc.), it's irrelevant whether that service is listening on that port (at least until you get past this current problem).

At least according to the images you posted in your last two replies, everything seems correct. Of course, what I can't see is the actual traffic before it even gets to the firewall.

What you could try is dumping connection tracking to see if the remote access connection is entering the router AT ALL. I've been hesitant to take it this far given it's not the easiest thing to read/understand. But if I was there onsite, it's what I would be examining.

cat /proc/net/nf_conntrack

You can monitor it continuously using the watch command.

watch -tn5 'cat /proc/net/nf_conntrack'

What you're looking for is any signs of your public IP on the VPN coming into the WAN (your ISP's public IP) on the relevant port (51413). Of course, you need to "stir the pot" a little (try the port forwarding) to hopefully generate some relevant activity.

 

[Salles]

Thank you for your patience.
I have been in contact with Torguard. There was an issue with my config file. I had not specified which Public VPN address that I wanted to use in my config. I just port forwarded the public VPN IP address which I was given. Specifying a specific Public VPN on their site when creating a config file was needed for it to work. I have loaded new config file so this has now been corrected.

I am now receiving hits on the PREROUTING TABLE, but it does not seem to be forwarded in the FORWARDING TABLE (please see attached pictures).
https://portchecker.co/ is now saying that the port 51413 is forwarded.

Below you can see my nat-start. I have kept a few lines of iptables which as far as I understand are not necessary.
I do not know if I need to use them since Inbound Firewall is set to Allow.

#Used by Transmission to open port 51410:51414
#iptables -I FORWARD -i br0 -o tun12 -j ACCEPT
#iptables -I FORWARD -i tun12 -o br0 -j ACCEPT
#iptables -I FORWARD -i br0 -o vlan1 -j DROP
#iptables -I INPUT -i tun12 -j REJECT
#iptables -t nat -A POSTROUTING -o tun12 -j MASQUERADE
iptables -I FORWARD -i tun12 -p udp -d 192.168.50.10 --dport 51410 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 192.168.50.10 --dport 51410 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 51410 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 51410 -j DNAT --to-destination 192.168.50.10
iptables -I FORWARD -i tun12 -p udp -d 192.168.50.10 --dport 51411 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 192.168.50.10 --dport 51411 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 51411 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 51411 -j DNAT --to-destination 192.168.50.10
iptables -I FORWARD -i tun12 -p udp -d 192.168.50.10 --dport 51412 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 192.168.50.10 --dport 51412 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 51412 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 51412 -j DNAT --to-destination 192.168.50.10
iptables -I FORWARD -i tun12 -p udp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 192.168.50.10 --dport 51413 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 51413 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 51413 -j DNAT --to-destination 192.168.50.10
iptables -I FORWARD -i tun12 -p udp -d 192.168.50.10 --dport 51414 -j ACCEPT
iptables -I FORWARD -i tun12 -p tcp -d 192.168.50.10 --dport 51414 -j ACCEPT
iptables -t nat -I PREROUTING -i tun12 -p tcp --dport 51414 -j DNAT --to-destination 192.168.50.10
iptables -t nat -I PREROUTING -i tun12 -p udp --dport 51414 -j DNAT --to-destination 192.168.50.10

How do get the packets from being prerouted to forwarded?

 

[eibgrad]

Visually, the firewall looks correct. However, *technically* the FORWARD rules should be applied in the firewall-start script, NOT the nat-start script. I'm not sure if that's making the difference (does seem oddly coincidental the FORWARD rules are not being hit).

Frankly, I don't know why Merlin separates nat from other firewall rules, but whatever the reason, the fact he does suggests to me it's a good idea to apply the correct rules in the correct scripts (could be a red herring, but try it and see what happens).

 

[raven-au]

How do get the packets from being prerouted to forwarded?

Have you considered that you might need to set a port forward for the source IP address which these packets arrive on?

Let me try and explain, your VPN connection has several bits associated with it, the external public address, the VPN provider point to point end address, the router end point to point address and the interface (ie. tun12).

For TorGuard you know the external address which must be used in your VPN configuration.
Packets from that address get sent to the the VPN provider point to point end address and then appear on the the router end point to point address. The point to point addresses are typically 10.x.x.x addresses which you can see on a connected client in the router VPN GUI.

You have the filters setup which may or may not allow the packets you need through since there's nothing there about the router end VPN tunnel address.

How about try setting up a port forward in the router GUI with your target destination address (that looks like 192.168.50.10) and specify a source address of router end VPN tunnel address, the 10.x.x.x address you can get from the VPN page.

Because TorGuard requires you to use a specific server address those tunnel end point addresses will remain the same so you can use them in a forwarding rule.

The other thing that could be a problem is packets sent from the Transmission client that need to be sent to the listening port which need to go the the router end VPN tunnel address and not the WAN address.

A lot of network routing relies on not needing to setup routes because the default route will send packets to the right place that being the WAN address but in this case you want them to go to the router end VPN tunnel address.

Not sure if the GUI port forwarding, specifying a source address, will take care of that routing need ...

 

[raven-au]

Mmm ... tried the above myself, and a couple of other things, and I couldn't get it to work either ...

I have to wonder what's already setup by the VPN client and whether the "Inbound Firewall" set to allow actually works.

 

[eibgrad]

Not sure if the GUI port forwarding, specifying a source address, will take care of that routing need ...

The source field in the port forwarding of the GUI has nothing to do w/ routing (which seems to be what you're suggesting). It merely restricts the public IP(s) to which either the PREROUTING and/or FORWARD rule will result in a match. Nothing else.

In fact, the routing system doesn't even care about source IP. All the routing system cares about is how to get the current packet (irrespective of source) to the next destination based on the current routing table. If you want to affect the routing based on source, you actually have to implement split tunneling and use different routing tables for your various sources, which is exactly what PBR (policy based routing) does in the OpenVPN client GUI, only it's intended for the purposes of connections initiated from the router and outbound.

It only makes sense to use the VPN for remote access purposes if you can be assured the replies will be routed back out the same network interface. If you don't, you face the problem of RPF (reverse path filtering), which thanks to the stateful firewall, will *block* any attempt to route any given connection in from one network interface and out another. IOW, as long as the target of remote access in this case is also bound to the OpenVPN client for outbound purposes, it will work. If not, yeah, you have a problem. The same problem that would occur if that same target was remotely accessed over the WAN while bound to the OpenVPN client.

Whether any of these routing issues are relevant remains to be seen (I assume not until we reach that point). So far, we've yet to see this traffic make its way fully inbound, past the firewall. But it is something that has the potential to be a problem, of course.

 

[Salles]

Visually, the firewall looks correct. However, *technically* the FORWARD rules should be applied in the firewall-start script, NOT the nat-start script. I'm not sure if that's making the difference (does seem oddly coincidental the FORWARD rules are not being hit).

Frankly, I don't know why Merlin separates nat from other firewall rules, but whatever the reason, the fact he does suggests to me it's a good idea to apply the correct rules in the correct scripts (could be a red herring, but try it and see what happens).

I did an upgrade from 384.15 --> 384.19 which messed up a few things in my router settings. I have done quite a few dirty upgrades before this so I guess it was about time. So I did a complete reinstall of everything along with all scripts.

I put the iptables from post #54 in firewall-start instead. As before, I can see packages in the PREROUTING TABLE, but not in the FORWARDING TABLE. As for now portchecker says port 51413 is closed. Not really sure why it said the port was open before.
I am obviously a bit over my head here .
How can we find out how to get the packages from the PREROUTING TABLE to the FORWARDING TABLE?

 

[Salles]

Have you considered that you might need to set a port forward for the source IP address which these packets arrive on?

Let me try and explain, your VPN connection has several bits associated with it, the external public address, the VPN provider point to point end address, the router end point to point address and the interface (ie. tun12).

For TorGuard you know the external address which must be used in your VPN configuration.
Packets from that address get sent to the the VPN provider point to point end address and then appear on the the router end point to point address. The point to point addresses are typically 10.x.x.x addresses which you can see on a connected client in the router VPN GUI.

You have the filters setup which may or may not allow the packets you need through since there's nothing there about the router end VPN tunnel address.

How about try setting up a port forward in the router GUI with your target destination address (that looks like 192.168.50.10) and specify a source address of router end VPN tunnel address, the 10.x.x.x address you can get from the VPN page.

Because TorGuard requires you to use a specific server address those tunnel end point addresses will remain the same so you can use them in a forwarding rule.

The other thing that could be a problem is packets sent from the Transmission client that need to be sent to the listening port which need to go the the router end VPN tunnel address and not the WAN address.

A lot of network routing relies on not needing to setup routes because the default route will send packets to the right place that being the WAN address but in this case you want them to go to the router end VPN tunnel address.

Not sure if the GUI port forwarding, specifying a source address, will take care of that routing need ...

The router Web UI is only for port forwarding through WAN. I am not really sure how I would go about such a solution in IPTABLES .