Ok, but what was the net result? Did the connection simply die and you needed to restart it? Did it eventually recover and continue on, and the external port remained open?
It would appear based on the following in the log that it died, but I want to be sure.
Code:
Jul 13 12:05:32 DD-WRT daemon.notice openvpn[2243]: SIGTERM[soft,auth-failure] received, process exiting
Just died, I had to reboot by hand, for that I want to use a watchdog, bad idea?
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sat Jul 13, 2019 18:24 Post subject:
@eibgrad no problems here.
I saw in the log of @chryses that the connection was reset due to inactivity
I am running a ping every 2 minutes or my residential gateway goes down.
One thing I noticed when testing your kill SIGUSR1 is that the connection is trying to restart but it hangs with TCP reconnect. I attributed it to my residential gateway but maybe it is a bug.
About cipher, I've only followed the pia configuration page to configure the router, maybe is old and have to be updated?
I'll increase the verbosity to better see what happens. Do you think is better to write to external log? If yes I've to modify your script in order to parse the log and not the syslog?
I saw in the log of @chryses that the connection was reset due to inactivity
I am running a ping every 2 minutes or my residential gateway goes down.
One thing I noticed when testing your kill SIGUSR1 is that the connection is trying to restart but it hangs with TCP reconnect. I attributed it to my residential gateway but maybe it is a bug.
Anyway I have a stable connection without soft reset
Maybe this's the key! Now I've a watchdog running, we'll see what happen next!
Many VPN providers have out-dated tutorials, I see it all the time. In the end, what matters is what the actual OpenVPN server demands, not what's in the tutorials.
What I'm more interested in is whether you get these same messages at the time the initial connection is made. Because as I keep saying, the most recent log appears to be the VPN provider intentionally killing the connection. And one way to do that is suddenly have the server return a mismatch on a settings, or have authentication fail, esp. the latter. As you can see from that log, once authentication failed, the OpenVPN client process exited because it knows to continue is futile (the credentials are not going to change).
Quote:
I'll increase the verbosity to better see what happens. Do you think is better to write to external log? If yes I've to modify your script in order to parse the log and not the syslog? What do you think?
Seems like you're not listening to what I'm saying. The most recent log has NOTHING to do w/ the script. It's failing because the OpenVPN provider is killing the connection. IOW, it wouldn't matter whether you were or weren't attempting to use the PIA API and open an external port. It would still fail. So making changes to my script is irrelevant. You should either be complaining to the VPN provider (as I suggested in that link over at SNB, and what *I* would do if it was happening to me), or use some sort of watchdog to restart it if you detect a failure. At that point, my script would kick in again because it would detect the new process ID.
Now whether a "ping" like the one egc is using would help in this particular scenario seems unlikely since the VPN provider is purposely killing the connection. It's not really a "legitimate" soft reset/restart due to inactivity, but the VPN provider *forcing* a restart, so he can kick you off. IOW, he changes the authentication process to fail your username/password (even though it's correct), then purposely fails to respond to the OpenVPN client until it triggers the soft reset/restart, at which point there's no way to keep the connection alive.
So again, how you choose to deal with *that* particular problem is up to you. But my script is NOT the place to do it.
When it comes to the prior log, that seemed more legitimate, and perhaps just a normal inactivity timeout (esp. since it recovered the connection, although the external port was closed). And that's why I had you add those two directives. And so far, we have no proof one way or the other whether those directives helped to solve that problem. Instead, we have this *new* problem of the VPN provider intentionally killing the connection. And until that stops, we're not going to know if those directives are working.
You're obviously free to mess w/ the script all you want. But from what I'm seeing, it seems the wrong approach. This problem shouldn't be happening in the first place (and in the case of egc, he has no similar problems). Perhaps his "ping" is helping to avoid the problem found in the prior log, where for you, it recovered the connection after a soft reset/restart, but dropped the external port. Perhaps his ping is making sure he never gets an inactivity timeout, and thus *that* is the solution, and NOT messing w/ the script, logs, etc.
Again, do NOT confuse the prior log and what caused it (a true inactivity event), to the most recent log, which appears to have been done intentionally to kill the connection. These are different scenarios. And until the VPN provider stops killing the connection, you're only option is use a watchdog to restart the process. If you then add a ping as well, then perhaps this will avoid any future soft reset/restart that's NOT related to the VPN provider purposely killing the connection.
So, in summary…
1. Add a watchdog to restart the VPN process should it be killed by the VPN provider (or perhaps change servers, maybe that one is commonly overloaded).
2. Add a ping to keep any legitimate inactivity timeouts from occurring.
3. Add those two directives (persist-local-ip and persist-remote-ip) in the config, just in case you get a legitimate inactivity timeout anyway, for some unexpected reason.
None of this involves changes to the script. That shouldn't be necessary. My script is simply falling victim to other things that are either killing the connection, or failing to maintain the same configuration across a soft reset/restart.
Maybe I express myself in a wrong way. I don't mean that your script is wrong or have to be changed in order to try to resolve pia problems, I think your script is great. I mean that your script scrape the syslog
Code:
for file in /var/log/messages*; do
# search file (from newest to oldest entries)
sed '1!G;h;$!d' $file | \
grep -qi "\[$curr_pid\].*[i]nitialization sequence completed" && break 2
done
What is I add
Code:
log /tmp/openvpncl/openvpncl.log
This break your functionality? I mean, if I tell to the openvpn to write log inside this file, maybe the openvpn client don't write any to syslog? If this happen your script never know that the connection are made and won't start.
So I only ask to you if is safe to add
Code:
log /tmp/openvpncl/openvpncl.log
with "verb 4" in order to better see what happen.
Like you said, you don't have a full picture of what is on my side and I want to give you all log that maybe can help you, and I agree with you when you said that first must try all before change the script.
My actual configuration is like you said
1. watchdog for vpn restart if some go wrong, this also include the ping so point 2 is done
3. I alredy added your directive.
Btw tonight the ip is changed and the port is still open! But I don't have any log to provide.
I'll add a "verb 4" and I try with the external log, hoping that don't break your script
I also see some mtu problem, do you think is better to set mtu in a proper way? I don't know if this can help to mantain a better and stable vpn connection.
@eibgrad
I make a log with verb 4 and I wrote it on an external file, and what I thought is right, your script never see the "Initialization Sequence Completed" so never continue. Maybe is better to write this into the instruction?
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sun Jul 14, 2019 11:10 Post subject:
Possible explanation is that your watchdog is only killng the VPNclient, the /tmp/var/run/openvpncl.pid is not deleted and the restarted OVPN client uses the same pid and therefore the port forward script is not triggered.
What you might do is set the watchdog to reboot the whole router and then it will work, I think.
Mind you, as you are using PBR the built in watchdog checks the WAN and not the VPN, so you should use the watchdog from @Sploit or do something like this (added benefit it keeps your connection alive):
(
while sleep 120; do
while ! ping -qc1 -w6 8.8.8.8 -I tun1 > /dev/null 2>&1; do
logger "No ping through tunnel, rebooting"
reboot
done
done
)
I have no idea the full implications of using the log directive. I don't use it, and never have. For one thing, it doesn't provide the process ID, so I don't know if I'm looking at *all* previous OpenVPN client processes (because it concatenates the file), or only the most recent process (because it reinitializes it w/ each new OpenVPN client process). So it's just not all that useful. I assume it does NOT affect what gets written to the syslog, but I don't know that for sure. If you insist on using it, you do so at your own risk.
I used the log directive only to have a log file to post to you, otherwise the only log I can post is the one from the router gui, I don't know if is complete.
Like I said the log directive break your script, I think because your script can't see "Initialization Sequence Completed" and maybe other reasons, the fact is that if the log directive is present (maybe some other guy want to have this directive) the script can't works like expected. For this I said to you if you want to add this reminder inside your instruction, maybe I wrong, I only want to help.
… it appears you are restarting the OpenVPN process from within my script, which I don't recommend. Once you start messing w/ my script, I have no idea how you may have changed the workflow. That's why I provide a UI, so you don't have to touch the script, at all. But once you do, as w/ the log directive, you do so at your own risk.
When it comes to using a ping, watchdog, etc., all this should be done *outside* my script because it has nothing to do w/ my script.
Nope I don't have even touched your script, I don't want to!
I'm using this one
Code:
version: 2.1.1, 11-jul-2019, by eibgrad
I only killed the openvpnclient and I waited the re-connection, the watchdog do this, if the tun1 is not up restart the client. If you see the log of the vpn you can see that the connection was established before
Code:
Sun Jul 14 12:05:25 2019 us=119984 Initialization Sequence Completed
and your script endlessly try to wait the connections
Code:
Jul 14 12:06:05 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:06:27 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:06:48 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:06:53 DD-WRT user.notice clientvpn_watchdog.sh: 0/6 ping failed. All systems are functioning within normal parameters.
Jul 14 12:07:03 DD-WRT user.notice root: pbr no change detected yet, old: 10.3.11.5 , new: 10.3.11.5
Jul 14 12:07:10 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:07:31 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:07:53 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root 3500 S openvpn --config /tmp/openvpncl/openvpn.conf --route
But this due the fact that the log directive is not good!
So now I'm in the same situation you said before, with your script untouched, without log directive and with watchdog running, plus egc pbr script.
eibgrad wrote:
Many VPN providers have out-dated tutorials, I see it all the time. In the end, what matters is what the actual OpenVPN server demands, not what's in the tutorials.
What I'm more interested in is whether you get these same messages at the time the initial connection is made. Because as I keep saying, the most recent log appears to be the VPN provider intentionally killing the connection. And one way to do that is suddenly have the server return a mismatch on a settings, or have authentication fail, esp. the latter. As you can see from that log, once authentication failed, the OpenVPN client process exited because it knows to continue is futile (the credentials are not going to change).
Do you find some in the verb 4 log that I post to you? All started with cipher question.
If you look at the post above this it has my post with most or all of what you need. I have been using this for a long time now and I always get a port no issue.
Chryses wrote:
The NAS running transmission client and all others programs
You would use a setup much like mine and instead get the script to target transmission on the NAS.
This is the script that gets the port, edits and saves it in as $port and in a text file and then sends it to transmission. You will need the "transmission-remote" binary, so install transmission on the router with entware. "192.168.3.1" is the address for my router where transmission is running so transmission-remote can find it. Just change that to your NAS ip. Don't forget to add your sha256sum to the script where "#insertyour sha256sum from calc here#" is.
Chryses wrote:
Now I've some question about this script, because I think I not fully understand the script itself
This is the code to understand. It grabs the port and saves it as the value $port which can then be used.
eibgrad wrote:
PIA has made this ridiculously complex. And even *I* can't tell you the answer to all these *good* questions. They limit the port forward to specific servers, and don't tell you if you will consistently get the same external port number, esp. if you change servers. Again, all good questions, but PIA doesn't provide any information in this regard, as far as I know.
It is actually not that complicated. The command to grab the port is quite simple. PIA have stated and it is the case that connecting to the same server while using the same SHA will usually result in the same port.
Chryses wrote:
Ok thanks. I tried but I think I do some bad configuration.
My router is 10.0.0.1 and my nas is 10.0.0.100
Transmission is configured with port 54321
So I configured ddwrt-pia-port-forward.startup to have
/jffs/etc/config/ddwrt-pia-port-forward.sh --ip 10.0.0.100 --port 54321 --debug
But if I test the port from transmission, I got error, port closed
I've made no change to ddwrt-pia-port-forward.sh
to any BEGIN OPTIONS available, so internal port is
INTERNAL_PORT="80"
The funny is that if I put port 80 inside transmission (without reboot any) I got the port open
Ps, I don't have to put the script in Startup field on the router, right?
What I miss?
My post above your first post. It had everything you needed.
Chryses wrote:
PIA client on my pc, then connected to swiss server, with port forward enabled, then I installed transmission on pc and configured the port that pia say, cheched the status and port open!
... my post
eibgrad wrote:
Like egc, I'm not a user of transmission, so I'm not familiar w/ its configuration.
... my post!
egc wrote:
Set that port number in transmission.
... my post!!
egc wrote:
I do not use transmission but I guess it is advertising its port to the internet but this is a different port from what PIA gives you and hence it will not work because the port transmission advertises is not open.
Luckily PIA gives you the same port when using the same client id, so once you know it you enter that port in transmission.
But not a fool proof solution.
What you can do is on your NAS which is Linux based (regarding your static rule) you can make a script which queries the html page on the router with the port PIA has opened for you (as defined by the script from @eibgrad) and then start Transmission from the CLI of your router with this port.
Make a loop to check every 60 seconds or so and if altered kill transmission and start again with the new port.
Can be done with a few lines of code.
If you get it working please publish it for further use
(state your NAS)
I am not at home so cannot test anything but I have a QNAP 453 Pro which can use scripts like this without a problem
... my post!!!
Chryses wrote:
so I make this little sh script to check and change the actual transmission port, according to the pia one.
WHAT DO THIS SCRIPT?
The purpose of this script is to run on a remote machine that hold transmission-daemon so it simply checks if transmission is active then check the pia port from the router and if different stop transmission, change the port, then restart transmission
REQUISITE:
jq (apt install jq)
transmission start/stop with systemd
some linux basi skills
if systemctl is-active --quiet $SERVICE; then # service active
[[ "$LOG_ENABLE" == "1" ]] && echo "service is active ..." >> "$LOG_PATH/${0##*/}.log"
PIA_PORT=$(curl -sf $PIA_EXT_PORT | grep -o '[0-9]*' | tail -n1) # get the pia port
if [[ ! -z $PIA_PORT ]] && [[ ! -w "$TMP_LOCK_FILE" ]]; then # I get the pia port
ACTUAL_TRANSMISSION_PORT=$(cat $TRANSMISSION_SETTINGS | jq '."peer-port"') # get the actual transmission port
if [[ $ACTUAL_TRANSMISSION_PORT == $PIA_PORT ]]; then # pia port is the same that that the transmission port
[[ "$LOG_ENABLE" == "1" ]] && echo "Transmission port is already the good one, nothing to do, see you later!" >> "$LOG_PATH/${0##*/}.log"
else # transmission use a different port
[[ "$LOG_ENABLE" == "1" ]] && echo "Transmission port is not the right one, I'll change it" >> "$LOG_PATH/${0##*/}.log"
touch "$TMP_LOCK_FILE"
systemctl stop $SERVICE # stop the service
sleep 1
jq --arg NEW_PORT "$PIA_PORT" '."peer-port" = $NEW_PORT' "$TRANSMISSION_SETTINGS" > tmp.$$.json && mv tmp.$$.json "$TRANSMISSION_SETTINGS" # change the port inside the settings.json file
systemctl start $SERVICE
sleep 1
rm "$TMP_LOCK_FILE"
fi
else # I can't find the pia port
[[ "$LOG_ENABLE" == "1" ]] && echo "I can't find the PIA port from $PIA_EXT_PORT make sure that exist and is reachable" >> "$LOG_PATH/${0##*/}.log"
fi
else
[[ "$LOG_ENABLE" == "1" ]] && echo "service is not active" >> "$LOG_PATH/${0##*/}.log"
fi
Before start this script please:
1. Specify the correct SERVICE, in my case is "transmission-daemon.service"
2. Set the right PIA_EXT_PORT, in my case the dd-wrt router is under 10.0.0.1
3. Set the right TRANSMISSION_SETTINGS, where is the settings.json of transmission?
4. In you need log set LOG_ENABLE to 1 and adjust LOG_PATH with your desired path
5. So, download the script, make it executable and place wherever you prefer
6. Cronize this script in order to execute every minute or so
This is a very basic script, I'm not a programmer so maybe can be improved! Any suggestion is appreciate
But with PIA you do not know the port which is opened for you that is the problem IMHO.
I am strugling with the more or less the same problem I want to connect to my VPN server via my PIA VPN client (I have to because I am behind a residential gateway)
To connect to my VPN server via the PIA VPN I have to know the port which PIA has opened for me, the script translates the open port to my VPN servers 1194, but if I do not know the open port (and the external IP address of course) I can not reach the VPN server.
PIA tells you the port when you get it. You can execute your script after you get the port so you know it...my post...
eibgrad wrote:
From the day some dd-wrt member asked for a script to support the PIA port forwarding API, I knew it would be nothing but problems.
Works fine for me, no issues ever. Took a bit to work out the correct script, main issue was timing.
eibgrad wrote:
I find it hard to believe that if PIA requires *dynamic* allocation of an external port on their end of the tunnel, that *they* don't publish it. Seems obvious to me that it's totally impractical to expect some internal device (beit the router or the PIA app running on some internal client) to make this known to clients outside the WAN.
PIA goes to some interesting methods to protect anonymity. There is means to their ways.
They do publish the port when the ask for it. It is your job to save it. If they saved it who knows they may have to log something etc.
eibgrad wrote:
I'm not a fan of scraping the webpage for this information either.
And there is no need, you can save the port where ever. You can even push the port straight into transmission where ever and while it is running.
Chryses wrote:
I love the fact that in the second script the port can be changed without restart transmission, on the fly!
You definitely missed my post it is interesting how long this thread has gone when essentially the post RIGHT BEFORE your first post had what you were seeking .....
Chryses wrote:
But I think is always the same situation, pia vpn must be on the same device with transmission.
No
eibgrad wrote:
Also, the link describes their script as using cron to have it rerun and check if the external port has changed. Since you can only retrieve the external port within the first two (2) minutes of the connection being established, that makes no sense. Within any given on-going connection, it should NOT change. If the OpenVPN client is restarted, then yes, I see the need. But depending on a cron job every two hours is very unlikely to meet the two minute requirement. To really make that work, any such script would need to run continuously, detect the restart, then run through the entire process again, getting the external port, establishing the port forwards again, etc.
Let me stop you there before it gets even more carried away!! OVPN can run scripts on events like route up or route down and more. You see when the route is up you then have a window to get your port, you can also run a script or scripts, whatever you feel.
PIA has explained their reasoning for the limited window to get a port. I can't remember exactly but I guess it taxes the server some how.
eibgrad wrote:
Once again, the fact the external port can change under certain conditions (not all of which are known) is the big headache.
The port will only change on a slim chance with a reconnect or definitely with a SHA change. Both are not a headache and easily accounted for.
eibgrad wrote:
Of course, there's always another option; find a better OpenVPN provider who assures you of a fixed, known, and reliable external port!
(note to self; don't use PIA if you need port forwarding over the VPN)
PIA is quite good. There will be reasons for limiting ports the way they do. I have no issues getting a port or using it with PIA.
Chryses wrote:
Like you said there's a big problem, what if the port change without any re-connection?
Not a problem or big. Really you should read the last post in a thread next time.
Chryses wrote:
The only good solution is to constantly check the port from pia every minute
Not a solution or good or the only. Run your script but preferably my script from OVPN route-up.sh
eibgrad wrote:
It's bad enough if the external port can change on a reboot, restart of the OpenVPN client, etc. At least I can detect it. But if it can change *during* a given connection, it's time to throw in the towel. Because that's just plain crazy. No one should be expected to constantly reconfigure their running application/service to deal w/ an ever changing external port. And AFAIK, the PIA API never even suggests this could happen.
Changing with connection is no issue and usually doesn't happen. Changing during connection is not meant to happen and has never happened to me with connections running for weeks. What is likely happening is OVPN is reconnecting and then a new port is given. Which is easy to solve. This whole thread has gone absurd.
eibgrad wrote:
As I said, let's not get ahead of ourselves until we know there is no other solution.
.....sigh
kinda waiting till one you actually reads the thread, eh.
OK to avoid the above long rant and get to the point!
THIS PROBLEM HAS BEEN SOLVED !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Chryses, Chryses, Chryses. Next time read the post before you post. My post before your first post in this thread should have in it all you seek!
You guys have essentially gone on now for 6 pages off on a tangent when the solution was sitting right there in the thread! Wow
If you have any questions, or need help understand why and what I did, if I can remember lol I will try pop in over the next few days.
I just solved my SMR drive debacle with problems for transmission, proftpd and kodi. Wow now that was a problem, unlike this. SMR drives are just a little retarded.
I am sorry you all have disappointed me quite a bit.
I get you are interested in a general solution, but by ignoring/missing what I have posted you have so called reinvented the wheel and not a very good one. The problems you had and still have I found solutions to. For example curl not working is merely a timing issue. I am using 17seconds of sleep + execution time for other parts of the script after route is up.
Yes there are problems using the route-up.sh. But guess what I solved them too. They involve restrictions the openvpn process puts on running certain things from inside the process. I use multiple scripts and a choice of certain programs, as I guess as some sort of exploit to get around it.
I am telling you I am reliably using the thing as now for 10 month without as a single hiccup. Yes I had issues at the start and guess what I resolved them all. I had to debug many steps and work out what was wrong and find a work around.
I wasn't aware the PIA forums were running again? Hmm seems like they sort of are, interesting. I will have a read of the link. At the end I see one mention of curl failing and not much on why. That post is before I came to my solution.
I really don't think that ports change while connected. PIA says they don't and I have never had it happen, but then my longest run with the router up is like 2-3 weeks. Now I have resolved my SMR issue I could go longer but I doubt I would have power that long. It is much more likely the vpn tunnel is reconnecting and then changing ports. I would not notice this as my script will just update the port on transmission while it is running.
You need to execute curl after the tunnel is constructed that is what the route-up script is for. Route-up = tunnel constructed. There is problems with running certain things from the route-up script. I got around that but jumping through scripts.
Eibgrad no doubt you know more about many things with ddwrt and linux than me, much more. All I can say is what I have done works, been using it for 10 months with no issue. I had many issues getting it to work. I resolved them all , one by one.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Tue Jul 23, 2019 12:14 Post subject:
@portsetup first of all thanks for your contributions, it is appreciated.
As @eibgrad said he makes a more general solution which in my case works very well.
I have written my own callback script which updates IP and port number to DDNS to retrieve from that and get a connection to my VPN server.
The VPN connection to PIA is solid maybe because I ping to keep my connection open.
So no complaints on that part, however as internet in France is overloaded in summer, Internet occasially disconnects, the watch dog kicks in and everything is restored, however I noticed that the port number from PIA does change and I am using the same hash (checked it is in nvram and used), so I am very happy with the current setup.
I could have hacked it all together myself but working with (and learning) from @eibgrad, for a more general solution, was fun and informative
I don't know exactly where to start, so there's so many things in here!
I start from the end:
The eibgrad approach is the more flexible and practical one. With just few parameter you can have a pretty limitless application, this thanks to the callback.
This don't mean that the portsup approach was not good!!!
A 6 can be a 9, depending on side, so if you're right won't mean that I necessary wrong. So both solution works, each user can make his choice.
Personally I read your reply and, this's my very big fault, because my inexperience of routing (egc can confirm, I ask him a lot of times some regarding postrouting iptables and so many routing problems!!! Is hard to me to understand other that basic network). So because I found your solution quite hard for me, I just ask, then from there you can see all 6 pages!
Personally I'm not a programmer, so when I watch eibgrad code is always a try to learn, my code is much heavy! So I tried to find how to fix this problem but always because my inexperience I forgot your solution!
Personally I think at the end that is a quite good solution, maybe is not so portable (actually I'm trying to port this script to openwrt, is done but is not yet tested).
Like you do, I tried to use a up or route-up script but never worked like expected, I don't know why it stuck during a curl, like if the connection is not active. Btw I don't like in your approach the fact to install transmissio-daemon on router. I think is much better to modify on the fly the port in transmission on remote machine, is only my opinion. The second is that I can't see on your side (maybe I miss it) a second script on remote machine, that is needed in order to take the port if transmission start or re-start after the pia connection is established. But like I said is only my opinion.
When I said that transmission must be on the same device I mean that if transmission is on router and the router hold the pia connection, so can forward and make rules in a different way that if transmission is on a different device, and this's also the solution you got, am I right?
Sorry if I "ignored" your solution asking for a new method, I respect your work!!!
The eibgrad approach is the more flexible and practical one.
The thing is mine does almost exactly what you wanted and you missed it !
Chryses wrote:
Like you do, I tried to use a up or route-up script but never worked like expected, I don't know why it stuck during a curl
The Openvpn process puts limits on things executing from scripts from it and interacting with it. You need to use this intermediate script to get around it
Code:
#!/bin/sh
/jffs/portforward2.sh &
exit 0
You jump from route-up.sh to the above then to the script that runs curl. That is if my memory remembers it all correct. I think there was also something running the script as sh and not bash.
Also of note the --up and --route-up openvpn variables are different. UP is usable in ddwrt and executes once the device TUN is up. ROUTE-UP is not usable in ddwrt unless you copy over it as ddwrt uses it for PBR and other things. ROUTE-UP runs after the connection is made and when your 2 minutes start to get a port
Chryses wrote:
Btw I don't like in your approach the fact to install transmissio-daemon on router.
No you don't need to run the daemon on the router. That is just where I run it as that is all I have.
Chryses wrote:
I think is much better to modify on the fly the port in transmission on remote machine, is only my opinion.
Yes I have already explained this to you.
Chryses wrote:
The second is that I can't see on your side (maybe I miss it) a second script on remote machine, that is needed in order to take the port if transmission start or re-start after the pia connection is established. But like I said is only my opinion.
You don't need to restart transmission to change the port.
The transmission-remote binary can be used to connect to your transmission-daemon and control it, like any other remote also for windows ,android etc. For me the daemon is on my router so the ip of my router is 192.168.3.1, but for you will be your NAS ip. The remote can change the port of transmission while it is running.
You will need to run transmission-remote from your router. You will also need to whitelist your router in the transmission settings.json to allow it to control transmission or if you also use a user and pass for transmission you will need to use that with the remote.
Chryses wrote:
When I said that transmission must be on the same device I mean that if transmission is on router and the router hold the pia connection, so can forward and make rules in a different way that if transmission is on a different device, and this's also the solution you got, am I right?
Yes but you are confusing a lot of my scripting. A lot of what you are seeing in the script is also a double or even triple killswitch, bit over kill. The part to change the port can run from the router to change it on your NAS and so could some other parts.
Let me write out better instructions so you can try it
#Make a copy of /tmp/openvpncl/ to /jffs/openvpncl/, you will need jffs in nvram.
use the cmd#
Code:
cp -a /tmp/openvpncl/* /jffs/openvpncl/
#Make a script at /jffs/portforward.sh containing#
Code:
#!/bin/sh
cp -a /jffs/openvpncl/* /tmp/openvpncl/
#Add this to an empty line in "additional config" in /services/vpn tab at openvpn. This will execute that script when openvpn starts and makes tun1 it's tunnel dev#
Code:
up /jffs/portforward.sh
# Edit the scipt route-up.sh in /jffs/openvpncl/. Add this to the end of it#
Code:
/jffs/portforward1.sh
#next script make /jffs/portforward1.sh, this is to seperate from openvpn process#
Code:
#!/bin/sh
/jffs/portforward2.sh &
exit 0
#last script /jffs/portforward2.sh,be careful of the port= line some of it is on the line below, here is the pastebin https://pastebin.com/21a97kZ5 #
You will need the transmission-remote binary so install transmission from entware. Installing it does not mean the daemon is going to run just that the files are there. My memory is foggy on some parts as i did this all 10 months ago. I am happy to work through it with you. For example I think you might need to install /bin/sh/ which is in the busybox package if i remember right. I remember there was an issue running scripts as bash from openvpn.
eibgrad wrote:
In my experience, it still isn't reliable.
10 months no issues ever. I don't know what you call reliable but I think I have it.
eibgrad wrote:
You also only have a very few seconds to execute your event handler. You can't just twiddle your thumbs for 10, 15, or more secs waiting for the perfect opportunity to access the tunnel. IIRC, if you go beyond about 10 secs, OpenVPN just kills the connection and reports a failure w/ the script. IOW, it won't wait indefinitely for you to complete your actions.
I think my solution for part of that was jumping to script thru another script.
eibgrad wrote:
To make matters worse, even if it did work, dd-wrt makes it a major PITA to use the route-up event since it too uses that event for its own purposes, and does so by configuring the event on the command line, making it impossible to override via Additional Config. Instead, you have to kill the existing OpenVPN process and restart it from the command line using your own route-up script, making sure to call the router's route-up script too.
You can just overwrite the route-up.sh or route-down.sh scripts using the --up variable to run another script to do so.
egc wrote:
I do not use transmission but the binding of $ifconfig_local is interesting
It restricts transmission to the VPN. $ifconfig_local is the internal ip address PIA or your VPN provider gives you.
