Anyone have DD-WRT, PIA openvpn, and port forwarding working

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page Previous  1, 2, 3, 4, 5, 6
Author Message
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sat Jul 13, 2019 16:34    Post subject: Reply with quote
eibgrad wrote:
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?
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 5920
Location: Netherlands

PostPosted: Sat Jul 13, 2019 18:24    Post subject: Reply with quote
@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.

Anyway I have a stable connection without soft reset

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Wireguard server setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1183135
Wireguard client setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624
Wireguard Advanced setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324787
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sat Jul 13, 2019 18:25    Post subject: Reply with quote
Here the conf
Code:
management 127.0.0.1 16
management-log-cache 100
verb 3
mute 3
syslog
writepid /var/run/openvpncl.pid
client
resolv-retry infinite
nobind
persist-key
persist-tun
script-security 2
dev tun1
proto udp4
cipher aes-128-cbc
auth sha1
auth-user-pass /tmp/openvpncl/credentials
remote de-frankfurt.privateinternetaccess.com 1198
comp-lzo yes
tun-mtu 1500
mtu-disc yes
fast-io
passtos
pull-filter ignore "dhcp-option DNS"
pull-filter ignore "redirect-gateway"
mute-replay-warnings
persist-key
persist-tun
tls-client
remote-cert-tls server
persist-local-ip
persist-remote-ip


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?

What do you think?
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sat Jul 13, 2019 21:11    Post subject: Reply with quote
egc wrote:
@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.

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!
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sun Jul 14, 2019 9:28    Post subject: Reply with quote
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).

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.
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sun Jul 14, 2019 10:22    Post subject: Reply with quote
@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?

Here the log from /var/log/messages:
Code:
###############################################################
Jul 14 12:05:16 DD-WRT user.err clientvpn_watchdog.sh: Ohhh No! We were unable to ping 8.8.8.8
Jul 14 12:05:16 DD-WRT user.err clientvpn_watchdog.sh: Sooo....Executing OpenVPN Forced Restart...
Jul 14 12:05:16 DD-WRT user.err clientvpn_watchdog.sh: ###############################################################
Jul 14 12:05:16 DD-WRT user.notice clientvpn_watchdog.sh: Taking down OpenVPN Client Routes
Jul 14 12:05:18 DD-WRT user.notice clientvpn_watchdog.sh: Shutting Down OpenVPN...
Jul 14 12:05:23 DD-WRT user.notice clientvpn_watchdog.sh: OpenVPN is restarting...
Jul 14 12:05:23 DD-WRT user.notice clientvpn_watchdog.sh:
Jul 14 12:05:23 DD-WRT user.notice clientvpn_watchdog.sh: Waiting 20 seconds for tunnel to open and secure...
Jul 14 12:05:43 DD-WRT user.notice clientvpn_watchdog.sh: Starting Up OpenVPN Client Routes
Jul 14 12:05:44 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3500 S    openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:06:02 DD-WRT user.notice root: pbr no change detected yet, old: 10.59.10.5 , new: 10.59.10.5
Jul 14 12:06:02 DD-WRT user.notice root: pbr change detected old: 10.59.10.5 , new: 10.3.11.5
Jul 14 12:06:02 DD-WRT user.notice root:  simple-pbr.sh Pull-filter detected table 11 via VPN
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
Jul 14 12:07:54 DD-WRT user.notice clientvpn_watchdog.sh: 0/6 ping failed. All systems are functioning within normal parameters.
Jul 14 12:08:03 DD-WRT user.notice root: pbr no change detected yet, old: 10.3.11.5 , new: 10.3.11.5
Jul 14 12:08:15 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3500 S    openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:08:16 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:08:16 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:16 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:16 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:08:24 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:08:24 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:24 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:24 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'state'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'state'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'state'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: NOTE: --mute triggered...
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: 1 variation(s) on previous 3 message(s) suppressed by --mute
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'status 2'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'status 2'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: CMD 'log 500'
Jul 14 12:08:30 DD-WRT daemon.notice openvpn[14821]: MANAGEMENT: Client disconnected
Jul 14 12:08:32 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:08:32 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:32 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:32 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:08:36 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3532 S    openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:08:45 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:08:45 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:45 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:08:45 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:08:54 DD-WRT user.notice clientvpn_watchdog.sh: 0/6 ping failed. All systems are functioning within normal parameters.
Jul 14 12:08:58 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3532 S    openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:09:02 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:09:02 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:02 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:02 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:09:03 DD-WRT user.notice root: pbr no change detected yet, old: 10.3.11.5 , new: 10.3.11.5
Jul 14 12:09:10 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:09:10 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:10 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:10 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:09:19 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3532 S    openvpn --config /tmp/openvpncl/openvpn.conf --route
Jul 14 12:09:21 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:09:21 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:21 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:21 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet
Jul 14 12:09:33 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPDISCOVER(br0) 00:e0:4c:68:00:9f
Jul 14 12:09:33 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPOFFER(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:33 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPREQUEST(br0) 10.0.0.114 00:e0:4c:68:00:9f
Jul 14 12:09:33 DD-WRT daemon.info dnsmasq-dhcp[1674]: DHCPACK(br0) 10.0.0.114 00:e0:4c:68:00:9f MiBox-Palestra-Ethernet

Here the external openvpncl.log with verb 4:
Code:
Sun Jul 14 12:05:23 2019 us=703545 WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
Sun Jul 14 12:05:23 2019 us=703699 WARNING: file '/tmp/openvpncl/credentials' is group or others accessible
Sun Jul 14 12:05:23 2019 us=703836 Current Parameter Settings:
Sun Jul 14 12:05:23 2019 us=703892   config = '/tmp/openvpncl/openvpn.conf'
Sun Jul 14 12:05:23 2019 us=703943   mode = 0
Sun Jul 14 12:05:23 2019 us=703994 NOTE: --mute triggered...
Sun Jul 14 12:05:23 2019 us=704069 229 variation(s) on previous 3 message(s) suppressed by --mute
Sun Jul 14 12:05:23 2019 us=704122 OpenVPN 2.4.6 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 28 2018
Sun Jul 14 12:05:23 2019 us=704176 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.09
Sun Jul 14 12:05:23 2019 us=705961 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
Sun Jul 14 12:05:23 2019 us=706221 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sun Jul 14 12:05:23 2019 us=709874 LZO compression initializing
Sun Jul 14 12:05:23 2019 us=710541 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Sun Jul 14 12:05:23 2019 us=750329 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Sun Jul 14 12:05:23 2019 us=750563 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sun Jul 14 12:05:23 2019 us=750633 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sun Jul 14 12:05:23 2019 us=750731 TCP/UDP: Preserving recently used remote address: [AF_INET]185.220.70.131:1198
Sun Jul 14 12:05:23 2019 us=750818 Socket Buffers: R=[180224->180224] S=[180224->180224]
Sun Jul 14 12:05:23 2019 us=750881 UDPv4 link local: (not bound)
Sun Jul 14 12:05:23 2019 us=750949 UDPv4 link remote: [AF_INET]185.220.70.131:1198
Sun Jul 14 12:05:23 2019 us=777565 TLS: Initial packet from [AF_INET]185.220.70.131:1198, sid=7ccc8322 475d1535
Sun Jul 14 12:05:23 2019 us=778006 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Jul 14 12:05:23 2019 us=809997 VERIFY OK: depth=1, C=US, ST=CA, L=LosAngeles, O=Private Internet Access, OU=Private Internet Access, CN=Private Internet Access, name=Private Internet Access, emailAddress=secure@privateinternetaccess.com
Sun Jul 14 12:05:23 2019 us=811597 VERIFY KU OK
Sun Jul 14 12:05:23 2019 us=811671 Validating certificate extended key usage
Sun Jul 14 12:05:23 2019 us=811726 NOTE: --mute triggered...
Sun Jul 14 12:05:23 2019 us=913949 3 variation(s) on previous 3 message(s) suppressed by --mute
Sun Jul 14 12:05:23 2019 us=914001 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Sun Jul 14 12:05:23 2019 us=914093 WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Sun Jul 14 12:05:23 2019 us=914506 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sun Jul 14 12:05:23 2019 us=914580 [59e9f91df0f5ef85e9a75e23770dc838] Peer Connection Initiated with [AF_INET]185.220.70.131:1198
Sun Jul 14 12:05:25 2019 us=59246 SENT CONTROL [59e9f91df0f5ef85e9a75e23770dc838]: 'PUSH_REQUEST' (status=1)
Sun Jul 14 12:05:25 2019 us=85204 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 209.222.18.222,dhcp-option DNS 209.222.18.218,ping 10,comp-lzo no,route 10.3.11.1,topology net30,ifconfig 10.3.11.6 10.3.11.5,auth-token'
Sun Jul 14 12:05:25 2019 us=85297 Pushed option removed by filter: 'redirect-gateway def1'
Sun Jul 14 12:05:25 2019 us=85359 NOTE: --mute triggered...
Sun Jul 14 12:05:25 2019 us=85815 6 variation(s) on previous 3 message(s) suppressed by --mute
Sun Jul 14 12:05:25 2019 us=85877 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:406 ET:0 EL:3 ]
Sun Jul 14 12:05:25 2019 us=86419 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Jul 14 12:05:25 2019 us=86514 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul 14 12:05:25 2019 us=86584 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Sun Jul 14 12:05:25 2019 us=86658 NOTE: --mute triggered...
Sun Jul 14 12:05:25 2019 us=89312 1 variation(s) on previous 3 message(s) suppressed by --mute
Sun Jul 14 12:05:25 2019 us=89396 TUN/TAP device tun1 opened
Sun Jul 14 12:05:25 2019 us=89481 TUN/TAP TX queue length set to 100
Sun Jul 14 12:05:25 2019 us=89567 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Jul 14 12:05:25 2019 us=89689 /sbin/ifconfig tun1 10.3.11.6 pointopoint 10.3.11.5 mtu 1500
Sun Jul 14 12:05:25 2019 us=96908 /sbin/route add -net 10.3.11.1 netmask 255.255.255.255 gw 10.3.11.5
Sun Jul 14 12:05:25 2019 us=119984 Initialization Sequence Completed
Sun Jul 14 12:06:16 2019 us=116494 Recursive routing detected, drop tun packet to [AF_INET]185.220.70.131:1198
Sun Jul 14 12:06:19 2019 us=174430 Recursive routing detected, drop tun packet to [AF_INET]185.220.70.131:1198
Sun Jul 14 12:06:25 2019 us=218175 Recursive routing detected, drop tun packet to [AF_INET]185.220.70.131:1198
Sun Jul 14 12:08:30 2019 us=817228 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
Sun Jul 14 12:08:30 2019 us=817583 MANAGEMENT: CMD 'state'
Sun Jul 14 12:08:30 2019 us=817978 MANAGEMENT: Client disconnected
Sun Jul 14 12:08:30 2019 us=822080 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
Sun Jul 14 12:08:30 2019 us=822419 MANAGEMENT: CMD 'state'
Sun Jul 14 12:08:30 2019 us=822804 MANAGEMENT: Client disconnected
Sun Jul 14 12:08:30 2019 us=831667 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
Sun Jul 14 12:08:30 2019 us=832014 MANAGEMENT: CMD 'state'
Sun Jul 14 12:08:30 2019 us=832387 MANAGEMENT: Client disconnected
Sun Jul 14 12:08:30 2019 us=886323 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
Sun Jul 14 12:08:30 2019 us=886642 MANAGEMENT: CMD 'status 2'
Sun Jul 14 12:08:30 2019 us=887488 MANAGEMENT: Client disconnected
Sun Jul 14 12:08:30 2019 us=932184 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
Sun Jul 14 12:08:30 2019 us=932522 MANAGEMENT: CMD 'log 500'
Sun Jul 14 12:08:30 2019 us=933784 MANAGEMENT: Client disconnected

Here the html from your script:
Code:
Sun Jul 14 04:13:17 CEST 2019: PIA external port forward: 185.220.70.138:43876


Hope the verb 4 can help
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 5920
Location: Netherlands

PostPosted: Sun Jul 14, 2019 11:10    Post subject: Reply with quote
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
)

Have not tested it and @eibgrad will probably come up with en "even" smarter solution Wink

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Wireguard server setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1183135
Wireguard client setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624
Wireguard Advanced setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324787
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Sun Jul 14, 2019 12:14    Post subject: Reply with quote
eibgrad wrote:

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.

eibgrad wrote:
As far as the following in the log …

Code:
Jul 14 12:05:44 DD-WRT user.notice ddwrt-pia-port-forward.[1433]: 16101 root      3500 S    openvpn --config /tmp/openvpncl/openvpn.conf --route


… 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.
portsup
DD-WRT User


Joined: 20 Oct 2018
Posts: 85

PostPosted: Mon Jul 22, 2019 23:34    Post subject: Reply with quote
Chryses wrote:

I'm trying to do this working


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.

For example


Code:
#!/bin/sh

/opt/bin/transmission-daemon --paused -g /tmp/mnt/sdb1/torrents/config
sleep 15
port=$(curl --interface tun1 "http://209.222.18.222:2000/?client_id=#insertyour sha256sum from calc here#" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }')
echo $port>/tmp/port.txt
/opt/bin/transmission-remote 192.168.3.1 -p "$port"


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


Code:
port=$(curl --interface tun1 "http://209.222.18.222:2000/?client_id=#insertyour sha256sum from calc here#" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }')


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 Smile
(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

SCRIPT:
Code:
#!/bin/bash

SERVICE="transmission-daemon.service"
PIA_EXT_PORT="http://10.0.0.1/user/pia/ext_port_forward.html"
TRANSMISSION_SETTINGS="/home/muletto/.config/transmission-daemon/settings.json"

TMP_PATH="/tmp"
TMP_LOCK_FILE="$TMP_PATH/${0##*/}.lock"

LOG_PATH="/var/log/nas-script"
LOG_ENABLE=0

if [[ "$LOG_ENABLE" == "1" ]]; then
   if [[ ! -w "$LOG_PATH/${0##*/}.log" ]]; then
      touch "$LOG_PATH/${0##*/}.log"
   fi
fi

[[ "$LOG_ENABLE" == "1" ]] && echo "########## $(date) ##########" >> "$LOG_PATH/${0##*/}.log"

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



... my post!!!!

nice coding but

Code:
sleep 15
port=$(curl --interface tun1 "http://209.222.18.222:2000/?client_id=#insertyour sha256sum from calc here#" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }')
echo $port>/tmp/port.txt
/opt/bin/transmission-remote 192.168.3.1 -p "$port"


you can even drop the txt bit so

Code:
sleep 15
port=$(curl --interface tun1 "http://209.222.18.222:2000/?client_id=#insertyour sha256sum from calc here#" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }')
/opt/bin/transmission-remote 192.168.3.1 -p "$port"


egc wrote:

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.
portsup
DD-WRT User


Joined: 20 Oct 2018
Posts: 85

PostPosted: Tue Jul 23, 2019 2:57    Post subject: Reply with quote
TLDR/


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.
portsup
DD-WRT User


Joined: 20 Oct 2018
Posts: 85

PostPosted: Tue Jul 23, 2019 12:03    Post subject: Reply with quote
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.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 5920
Location: Netherlands

PostPosted: Tue Jul 23, 2019 12:14    Post subject: Reply with quote
@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 Smile

I do not use transmission but the binding of $ifconfig_local is interesting Smile

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Wireguard server setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1183135
Wireguard client setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324624
Wireguard Advanced setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324787
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Chryses
DD-WRT User


Joined: 27 Jun 2018
Posts: 99

PostPosted: Tue Jul 23, 2019 19:27    Post subject: Reply with quote
Wait wait wait ...

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!!!
portsup
DD-WRT User


Joined: 20 Oct 2018
Posts: 85

PostPosted: Wed Jul 24, 2019 1:38    Post subject: Reply with quote
Chryses wrote:
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 Smile


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.

Code:
/opt/bin/transmission-remote 192.168.3.1 -p "$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 #


Code:
#!/bin/sh

sleep 15
port=$(curl --interface tun1 "http://209.222.18.222:2000/?client_id=#insertyour sha256sum from calc here#" 2>/dev/null | awk -F ':' '{ print $2 }'| awk -F '}' '{ print $1 }')
/opt/bin/transmission-remote "YOUR NAS IP ADDRESS" -p "$port"


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 Smile


It restricts transmission to the VPN. $ifconfig_local is the internal ip address PIA or your VPN provider gives you.
portsup
DD-WRT User


Joined: 20 Oct 2018
Posts: 85

PostPosted: Sun Aug 04, 2019 15:08    Post subject: Reply with quote
https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1172154

updated setup, better, sort of a guide, lots of good info.
Goto page Previous  1, 2, 3, 4, 5, 6 Display posts from previous:    Page 6 of 6
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum