What's new

Need help - NAT issues when using PIA openvpn client

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ghostwolf59

Occasional Visitor
Hi,
I am having issues with double NAT when connected to PIA where I configured my ASUS RT-AC66U router with a few openvpn clients (Merlin DDWRT firmware 380.70 (last release for this router *no more support offered on it :( )

My main issue that bugged me for some time is that transmission on FreeNAS always returned close ports.
Now setup the shell script to dynamically pic up the port provided by PIA for the server in question, but port still remain closed.

Then started to check my router configuration & setup.
Setup is this...
iinet TG-789 router/modem connected to NBN with VoIP capabilities.
TG-789 router connected via LAN port to my ASUS RT-AC66U router.

This setup clearly created a double NAT issue - tried to get around this port closed issue by port forwarding, but that didnt resolve the issue.
The tried to put the TG-789 router in DMZ mode - no change.

Then as a last resort I decided to put the TG-789 into Bridge mode.
Solved the issue, but lost my VoIP *that I still need*

But now with the Double NAT issue technically resolved I noticed that whenever I connect a client to a openvpn tunnel the traceout still suggest a Double NAT issue.
Without vpn, no issues.

The traceout reports hopes is this...

<code>
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 2 ms <1 ms <1 ms RT-AC66U-0E70 [192.168.2.1]
2 449 ms 431 ms 451 ms 10.63.10.1
3 426 ms 426 ms 434 ms vlan55.as053.buc.ro.m247.com [185.210.218.97]
4 426 ms 460 ms 441 ms 172.30.255.137
5 425 ms 424 ms 467 ms 172.30.245.53
6 499 ms 478 ms 445 ms vlan3006.bb1.bud.hu.m247.com [193.9.115.133]
7 451 ms 441 ms 450 ms bix.google.com [193.188.137.163]
8 459 ms 467 ms 470 ms 74.125.242.225
9 444 ms 455 ms 447 ms 72.14.233.75
10 459 ms 440 ms 429 ms dns.google [8.8.8.8]

Trace complete.
</code>

The second traceout hop lists the local 10.63.10.1 ip address. I have no idea what this is - Its not within my network, yet its an internal lan ip address.

Same thing when checking the openvpn client status
This ip is listed there - why and what is it?

Is it my TG-789 router *currently in Bridge mode* or what??
How can I get around this?

Would also appreciate if someone could tell me how I could get this to work and still get my VoIP phone to work? Would it be possible to connect a dedicated VoIP modem/router to my ASUS router and get the VoIP up or...?

Really want this Double NAT issue resolved somehow
icon_sad.gif


double nat.jpg
openvpn client.jpg
asus-rt-668u.jpg
.
 
The second traceout hop lists the local 10.63.10.1 ip address. I have no idea what this is - Its not within my network, yet its an internal lan ip address.
It's the address of one of your ISP's internal routers. It's perfectly normal and has nothing to do with NAT.
 
It's the address of one of your ISP's internal routers. It's perfectly normal and has nothing to do with NAT.

The 192.168.... is local lan ip.
the 10.63.10.1 seen on second hop is also a local ip *but nothing known to me* - hence creating a double NAT!

The traceout should give me my local ip followed by the external one immediately - if not, its a double nat state *that creates issues with close ports

Below is the same trace without a openvpn tunnel - see the difference.... *second hop direct to external ip

Transmission on the vpn reports port as closed as a result of using vpn tunnel - can only see this is due to double nat.

If I am wrong, please provide me a viable explanation to why a local ip is shown on the second hop.

not double nat.jpg


If you have a solution that would allow me to use VoIp I would be greateful as well

The modem/router closest to my NBN gateway *that now sits in Bridge mode* cant be used for VoIP.
I do have another modem/router that support VoIP that I thought I could use inside the bridged connection, but so far I cant figure out how to set it up to work for that.
Tried to hook it up via lan port between second router *the one inside the TG-789 *that is in bridge mode*
Can access the roters gui but WAN is obviously not up and VoIP in this setup does not work.
Someone suggested hooking up the new VoIP router/modem using the routers WAN to a LAN port, but the socket on WAN in different to normal RJ45 sockets on WAN. No idea how or if its even possible to get this working the way I thinking.
transmission.jpg
not double nat.jpg
 
Last edited:
OK I see my confusion. In your first post you have two traceroutes which I thought you were saying were taken with the VPN disabled.

The 10.63.10.6 address is just your VPN interface address and 10.63.10.1 is the VPN gateway. There's no reason to believe that there is any additional NAT happening on 10.63.10.1 just because it's a private address. Of course there will always be the NAT created on the PIA server in addition to the NAT created by your router. That's unavoidable.

Transmission will always show the port as closed when using a VPN. See the numerous reports of this in these forums.
 
Last edited:
OK I see my confusion. In your first post you have two traceroutes which I thought you were saying were taken with the VPN disabled.

The 10.63.10.6 address is just your VPN interface address and 10.63.10.1 is the VPN gateway. There's no reason to believe that there is any additional NAT happening on 10.63.10.1 just because it's a private address. Of course there will always be the NAT created on the PIA server in addition to the NAT created by your router. That's unavoidable.

Transmission will always show the port as closed when using a VPN. See the numerous reports of this in these forums.
Actually there is a possible exception when using PIA, some of its servers support single port forwarding. But you need to enable that in their app and then manually configure Transmission to listen to that port.
 
OK I see my confusion. In your first post you have two traceroutes which I thought you were saying were taken with the VPN disabled.

The 10.63.10.6 address is just your VPN interface address and 10.63.10.1 is the VPN gateway. There's no reason to believe that there is any additional NAT happening on 10.63.10.1 just because it's a private address. Of course there will always be the NAT created on the PIA server in addition to the NAT created by your router. That's unavoidable.

Transmission will always show the port as closed when using a VPN. See the numerous reports of this in these forums.

PIA that I am connected to, indeed support port forwarding *but only via a few selected servers*
I have the script that picks up the port offered whenever a new tunnel is created. That is automatically fed to transmission that start using this port.
Works perfectly.
But transmission still report the port as closed.
The 10.63.10.1 ip on the second hop puzzles me - I do not expect an foreign internal ip to be reported back - I would if anything expect the ip used by the tunnel to be reported back.

As per my no vpn traceout, the ip goes straight out.

IF(!) this local ip (10.63.10.1 (or whatever *different ip for each tunnel) is ok, why is the port still closed?
It shouldnt be!
 
Actually there is a possible exception when using PIA, some of its servers support single port forwarding. But you need to enable that in their app and then manually configure Transmission to listen to that port.

If you use this script with transmission and set up a cron task, then the port returned in between vpn tunnels *assuming you use one of the vpn servers PIA support port forwarding for*, your transmission interface would be updated automatically - works!
 

Attachments

  • transmission-port-forward.sh.txt
    2.5 KB · Views: 277
IF(!) this local ip (10.63.10.1 (or whatever *different ip for each tunnel) is ok, why is the port still closed?
That depends on how exactly Transmission is determining whether the port is open or closed (I don't know as I don't use Transmission). Remember that you are running it on the NAS not the router (where the VPN client is). So any unsolicited incoming connections on port 57129 will get as far as the router but no further because the router has no way of knowing where it's meant to forward them.

It shouldnt be!
The numerous other posts reporting this behaviour suggests otherwise.
 
That depends on how exactly Transmission is determining whether the port is open or closed (I don't know as I don't use Transmission). Remember that you are running it on the NAS not the router (where the VPN client is). So any unsolicited incoming connections on port 57129 will get as far as the router but no further because the router has no way of knowing where it's meant to forward them.

The numerous other posts reporting this behaviour suggests otherwise.

Ok, so lets assume the router dont know - If so, then shouldn't a port forwarding on the router to the destination ip resolve the issue then?
Not practical, but at least a way to check if this is the problem.
Yea, heaps of post about transmission and closed ports, but also many posts stating that they sorted it with *at least in part* using the script I posted earlier.
As for transmission it works - transmission is given the port returned. If *due to me using router level openvpn clients, is the problem, then I would at least have expected that a port forwarding would resolve the issue - but it wont! :(

I used to have openvpn setup within the jail on my FreeNAS server, but found it way more convenient setting it up on the router. If this becomes an issue with transmission, then I have no issues going back to how I used to have it.
But again, if the router defs indeed is the problem, then a port forwarding on the router ought to resolve the issue - right?
 
Ok, so lets assume the router dont know - If so, then shouldn't a port forwarding on the router to the destination ip resolve the issue then?
No, because the port forwarding rules on the router only effect the WAN interface and not the VPN interface.

Yea, heaps of post about transmission and closed ports, but also many posts stating that they sorted it with *at least in part* using the script I posted earlier.
I suspect message about the port being closed is false because of the kind of test it's doing. It's the same if I use qBittorrent, it works fine with the VPN it's just that external tests will fail.
 
No, because the port forwarding rules on the router only effect the WAN interface and not the VPN interface.

No way around this or...?

Dont seem to have achieved anything other than loosing my VoIP by putting my router in Bridge mode! Seem to have the same issues and nothing improved doing so when looking at transmission using openvpn :(

A creeping frustration @ my end atm ;)
 
Apart from the message saying the port is closed what actual problem do you have with Transmission?
 
Apart from the message saying the port is closed what actual problem do you have with Transmission?

It bogs down to speed, trackers and peers you connect to *I think* - To effectively use torrents you should be able to use port forwarding and the port should be open.
PIA made some changes a few years back as I understand it - never used to be a problem, where they now only offer a few selected servers that offer port forwarding. But to complicate matters you dont know what port each tunnel offer - hence this script being created that would query the tunnel within 2 minutes of being created. As for the script, it does what its meant to do and its convenient that it automatically updates transmission to use this new port.
So outstanding task @ my end is to see this port open as well ;)
 
Using BitTorrent clients behind double NAT and/or a VPN has been common for a long time. As such current BitTorrent clients know how to work around it. Like I said, in my experience it's not a problem (like it used to be years ago). YMMV of course.
 
It will require a full reset of the router after flashing and a complete minimal and manual configuration to secure the router and connect to your ISP, but I would suggest you flash john9527's RMerlin fork and stop using such an outdated firmware. :)

https://www.snbforums.com/threads/fork-asuswrt-merlin-374-43-lts-releases-v43e6.18914/

Not only does it have the latest security updates, but it is also almost feature-compatible with the latest RMerlin firmware too with regards to amtm and scripts support.

I can't say for sure, but it may even help with your PIA concerns too.
 
Using BitTorrent clients behind double NAT and/or a VPN has been common for a long time. As such current BitTorrent clients know how to work around it. Like I said, in my experience it's not a problem (like it used to be years ago). YMMV of course.

Its not as it dont work with Double NAT, but the speed of up/download changes.

I have decent NBN network and I noticed a significant difference in speed since ports are closed - still work, but slow *much slower*

Hence me today finally wanted to resolve the issue - but so far all I achieved is a lost land line VoIP phone :(
 
It will require a full reset of the router after flashing and a complete minimal and manual configuration to secure the router and connect to your ISP, but I would suggest you flash john9527's RMerlin fork and stop using such an outdated firmware. :)

Outdated firmware - true, but little I can do since they ceased further development on my ASUS router - using the latest released.

Other option is to buy another router such as RT-AC68U, but even this being a better router its still getting old now.
Seem to be limited support on latest routers *ASUS *like them and will probably stick to the brand* - Would have been nice if they had firmware for Asus ROG Rapture GT-AC2900, but to my knowledge theres nothing available for them
 
If Transmission has it disable μTP protocol.
Dont know where to look for that, but transmission is a well proven and possible the most commonly used torrent tool that dont require a client.
I dont need to worry about anything - FreeNAS installation of transmission sort it for me. Im way passed using a client to download stuff.
... and with radarr, sonarr and jacket in the mix its a breeze ;)
 
Similar threads
Thread starter Title Forum Replies Date
M Help Me Understand OpenVPN VPN 5

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top