PIA VPN always disconnects with policy routing

[BlezZ]

Hi Community,

This has been an issue for a long time for me. Currently on 384.9 and using PIA VPN

Whenever I enable policy routing on the VPN client for certain devices on my network the VPN disconnects randomly and does not reconnect automatically.
If I disable policy routing then the VPN tunnel stays up.

Any people having similar issues?

My hardware is: RT-AC88U (AC3100)

 

[Intrepid2007]

Hi Community,

This has been an issue for a long time for me. Currently on 384.9 and using PIA VPN

Whenever I enable policy routing on the VPN client for certain devices on my network the VPN disconnects randomly and does not reconnect automatically.
If I disable policy routing then the VPN tunnel stays up.

Any people having similar issues?

I use the same version (384.9) as you do, but here it works without problems. I use 2 ExpressVPN tunnels (policy based routing enabled).

It appears that your VPN connection has been setup correctly because it works with policy based routing disabled. When policy based routing is enabled, do you have rules set for your VPN?

 

[BlezZ]

I use the same version (384.9) as you do, but here it works without problems. I use 2 ExpressVPN tunnels (policy based routing enabled).

It appears that your VPN connection has been setup correctly because it works with policy based routing disabled. When policy based routing is enabled, do you have rules set for your VPN?

Thanks for your reply.

I have policies created for 2 clients on the network and the rule to block traffic if the tunnel goes down.
I was wondering if this is only happening with PIA or if this would happen with another provider like ExpressVPN too.

May I ask why you have 2 tunnels open and not route the clients through the same tunnel?

 

[Intrepid2007]

Thanks for your reply.

I have policies created for 2 clients on the network and the rule to block traffic if the tunnel goes down.
I was wondering if this is only happening with PIA or if this would happen with another provider like ExpressVPN too.

May I ask why you have 2 tunnels open and not route the clients through the same tunnel?

The first VPN tunnel (my own country):
used for 'regular' internet traffic

The second VPN tunnel (US-based)
used to watch TV services online (bypassing geo-restrictions)

In your case you only use 1 VPN tunnel...
About those 2 clients: Do the IP-addresses of those clients match the IP-addresses you have entered exactly?

 

[rcc344]

Had the same issue when "block client when tunnel is down". My VPN provider suggested to add a policy-
router directed to WAN. ie 192.168.1.1 use WAN. This solved the issue.

 

[BlezZ]

The first VPN tunnel (my own country):
used for 'regular' internet traffic

The second VPN tunnel (US-based)
used to watch TV services online (bypassing geo-restrictions)

In your case you only use 1 VPN tunnel...
About those 2 clients: Do the IP-addresses of those clients match the IP-addresses you have entered exactly?

Yes, they match 2 devices the NAS and KODI.
I really might have to try Express VPN for a month and check if this is provider related.

PIA support recommends not to use policy routing but this is not acceptable for me as the whole purpose of my router is to be able to do those sorts of rules.
PIA support replies very quickly and they do look into things from my experience but they are not very familiar with specific router setups.

 

[BlezZ]

Had the same issue when "block client when tunnel is down". My VPN provider suggested to add a policy-
router directed to WAN. ie 192.168.1.1 use WAN. This solved the issue.

Sorry, you mean to direct the router own IP to WAN?

 

[CaptainSTX]

Yes, they match 2 devices the NAS and KODI.
I really might have to try Express VPN for a month and check if this is provider related.

PIA support recommends not to use policy routing but this is not acceptable for me as the whole purpose of my router is to be able to do those sorts of rules.
PIA support replies very quickly and they do look into things from my experience but they are not very familiar with specific router setups.

Policy routing has never caused any issues for me using PIA on a N66, AC1900p or currently on an AC86. I have it currently running on two routers and both have been up for over thirty days with no tunnel drops. The recommended additional settings did change slightly with the change in version of OpenVPN used in Merlin's version 384.9.

1. Download a new and current set of ovpn files from PIA.
2. Select the server's ovpn file you want to use and upload it into Merlin using the button.
3. Add you user name and password for PIA
4. Modify and settings you want such as start with WAN, Policy routing, etc.
5. Here are the custom settings I have setup. I'm not sure that PIA's servers act on all of them other than the ones included with the ovpn file but you can try. They may help but they don't seem to harm anything. Currently I am experimenting to see if ping-restart has any impact. Haven't found a good way to down the tunnel while keeping the VPN client active.

persist-key
persist-tun
pull-filter ignore "auth-token"
resolv-retry infinite
tls-client
remote-cert-tls server
disable-occ
fast-io
sndbuf 524288
rcvbuf 524288
ping-restart 120

 

[BlezZ]

Policy routing has never caused any issues for me using PIA on a N66, AC1900p or currently on an AC86. I have it currently running on two routers and both have been up for over thirty days with no tunnel drops. The recommended additional settings did change slightly with the change in version of OpenVPN used in Merlin's version 384.9.

1. Download a new and current set of ovpn files from PIA.
2. Select the server's ovpn file you want to use and upload it into Merlin using the button.
3. Add you user name and password for PIA
4. Modify and settings you want such as start with WAN, Policy routing, etc.
5. Here are the custom settings I have setup. I'm not sure that PIA's servers act on all of them other than the ones included with the ovpn file but you can try. They may help but they don't seem to harm anything. Currently I am experimenting to see if ping-restart has any impact. Haven't found a good way to down the tunnel while keeping the VPN client active.

persist-key
persist-tun
pull-filter ignore "auth-token"
resolv-retry infinite
tls-client
remote-cert-tls server
disable-occ
fast-io
sndbuf 524288
rcvbuf 524288
ping-restart 120

Thanks for providing that info. I will test with your custom strings again.
Worth mentioning is that I tried now through different Merlin builds. Now testing on different PIA ports and ciphers.
Ages ago I had the tunnel up for a long time and then updated the firmware and tunnel started dropping. But again only with policy routing enabled.
Also the error that I see sometimes in the logs is related to TLS negotiation failed.

If for any reasons my provider disconnects the WAN connection after x hours. I assume the tunnel should come up again as reconnect is enabled by default in the settings?

 

[RMerlin]

A lot of my own development was tested using a PIA account as well, no problem there.

 

[CaptainSTX]

Thanks for providing that info. I will test with your custom strings again.
Worth mentioning is that I tried now through different Merlin builds. Now testing on different PIA ports and ciphers.
Ages ago I had the tunnel up for a long time and then updated the firmware and tunnel started dropping. But again only with policy routing enabled.
Also the error that I see sometimes in the logs is related to TLS negotiation failed.

If for any reasons my provider disconnects the WAN connection after x hours. I assume the tunnel should come up again as reconnect is enabled by default in the settings?

Depends on how long the ISP interuption/disconnection lasts.

If you think you have an ISP problem then run a long term ping plotter test (many hours/ many days) to see if your internet connection is unstable. If that is the case then it isn't PIA's problem and any VPN provider tunnel will drop.

Also it wouldn't hurt if you set up a device on your network that is routed using the VPN to ping an IP once a minute to create a constant flow of traffic over the tunnel.

Also consider connecting your modem and router to a UPS so power fluctuations and glitches wonb't lead to instability in your Internet connection.

 

[Netbug]

I've no issues with PIA either.

This is what I have in my custom config without issues.

remote-random
tls-client
remote-cert-tls server
auth-nocache
mute-replay-warnings
disable-occ
allow-recursive-routing
pull-filter ignore “auth-token”
pull-filter ignore “ifconfig-ipv6”
pull-filter ignore “route-ipv6”
ping 15
ping-restart 0
ping-timer-rem
pull
fast-io

Sent from my SM-G975F using Tapatalk

 

[BlezZ]

A lot of my own development was tested using a PIA account as well, no problem there.

Thanks, Merlin. That is a good indication that it might be my provider then.

ALso thanks to everyone for all the replies. I will do more testing with the pings.

This is my latest log. I have 2 tunnels open (UDP on 1198) (TCP on 502) and they seem to be going down but then reconnecting.

Mar 28 12:20:42 ovpn-client2[4822]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Mar 28 12:20:42 ovpn-client2[4822]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Mar 28 12:22:47 ovpn-client2[4822]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 28 12:22:47 ovpn-client2[4822]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Mar 28 12:22:47 ovpn-client2[4822]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Mar 28 12:22:53 openvpn-routing: Configuring policy rules for client 2
Mar 28 12:22:53 openvpn-routing: Removing rule 10301 from routing policy
Mar 28 12:22:53 openvpn-routing: Tunnel down - VPN client access blocked
Mar 28 12:22:53 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 2
Mar 28 12:22:53 openvpn-routing: Completed routing policy configuration for client 2
Mar 28 12:22:53 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 12:22:53 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 12:22:53 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 12:22:56 openvpn-routing: Configuring policy rules for client 2
Mar 28 12:22:57 openvpn-routing: Creating VPN routing table (mode 2)
Mar 28 12:22:57 openvpn-routing: Removing route for 10.13.10.1 to tun12 from main routing table
Mar 28 12:22:57 openvpn-routing: Removing route for 0.0.0.0/1 to tun12 from main routing table
Mar 28 12:22:57 openvpn-routing: Removing route for 128.0.0.0/1 to tun12 from main routing table
Mar 28 12:22:57 openvpn-routing: Removing rule 10301 from routing policy
Mar 28 12:22:57 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 2
Mar 28 12:22:57 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Mar 28 12:22:57 openvpn-routing: Completed routing policy configuration for client 2
Mar 28 13:14:07 ovpn-client1[5159]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 28 13:14:07 ovpn-client1[5159]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 28 13:14:22 ovpn-client1[5159]: Connection reset, restarting [0]
Mar 28 13:14:27 ovpn-client1[5159]: WARNING: --ping should normally be used with --ping-restart or --ping-exit
Mar 28 13:14:27 ovpn-client1[5159]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Mar 28 13:14:27 ovpn-client1[5159]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 28 13:14:30 ovpn-client1[5159]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 28 13:14:30 ovpn-client1[5159]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mar 28 13:14:30 ovpn-client1[5159]: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Mar 28 13:14:31 openvpn-routing: Configuring policy rules for client 1
Mar 28 13:14:31 openvpn-routing: Removing rule 10101 from routing policy
Mar 28 13:14:31 openvpn-routing: Tunnel down - VPN client access blocked
Mar 28 13:14:31 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 1
Mar 28 13:14:31 openvpn-routing: Completed routing policy configuration for client 1
Mar 28 13:14:31 ovpn-client1[5159]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:14:31 ovpn-client1[5159]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:14:31 ovpn-client1[5159]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:14:37 openvpn-routing: Configuring policy rules for client 1
Mar 28 13:14:37 openvpn-routing: Creating VPN routing table (mode 2)
Mar 28 13:14:37 openvpn-routing: Removing route for 10.31.1.1 to tun11 from main routing table
Mar 28 13:14:37 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
Mar 28 13:14:37 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
Mar 28 13:14:37 openvpn-routing: Removing rule 10101 from routing policy
Mar 28 13:14:37 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 1
Mar 28 13:14:37 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Mar 28 13:14:37 openvpn-routing: Completed routing policy configuration for client 1
Mar 28 13:22:47 ovpn-client2[4822]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Mar 28 13:22:47 ovpn-client2[4822]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Mar 28 13:24:52 ovpn-client2[4822]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 28 13:24:53 ovpn-client2[4822]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'
Mar 28 13:24:53 ovpn-client2[4822]: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
Mar 28 13:24:55 openvpn-routing: Configuring policy rules for client 2
Mar 28 13:24:55 openvpn-routing: Removing rule 10301 from routing policy
Mar 28 13:24:55 openvpn-routing: Tunnel down - VPN client access blocked
Mar 28 13:24:55 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 2
Mar 28 13:24:55 openvpn-routing: Completed routing policy configuration for client 2
Mar 28 13:24:55 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:24:55 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:24:55 ovpn-client2[4822]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 28 13:24:58 openvpn-routing: Configuring policy rules for client 2
Mar 28 13:24:58 openvpn-routing: Creating VPN routing table (mode 2)
Mar 28 13:24:58 openvpn-routing: Removing route for 10.24.10.1 to tun12 from main routing table
Mar 28 13:24:58 openvpn-routing: Removing route for 0.0.0.0/1 to tun12 from main routing table
Mar 28 13:24:58 openvpn-routing: Removing route for 128.0.0.0/1 to tun12 from main routing table
Mar 28 13:24:58 openvpn-routing: Removing rule 10301 from routing policy
Mar 28 13:24:59 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 2
Mar 28 13:24:59 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Mar 28 13:24:59 openvpn-routing: Completed routing policy configuration for client 2

 

[RMerlin]

Based on these log errors, I suspect you are using old configuration parameters. Download their latest .ovpn files, and re-import it on top of your current configuration.

 

[BlezZ]

Based on these log errors, I suspect you are using old configuration parameters. Download their latest .ovpn files, and re-import it on top of your current configuration.

Just wanted to say "THANK YOU!" for the great Merlin Builds and your time invested into the development!

I have uploaded the new ovpn file and also created a new 3rd VPN client with just the new file. Lets see how that goes over the weekend.

Is below guide actually still valid, as I don't have an Firewall entry that I can set to automatic.
https://www.privateinternetaccess.com/helpdesk/guides/routers/merlin/merlin-firmware-openvpn-setup

 

[RMerlin]

Is below guide actually still valid

No idea how up-to-date these settings are.

 

[CaptainSTX]

Just wanted to say "THANK YOU!" for the great Merlin Builds and your time invested into the development!

I have uploaded the new ovpn file and also created a new 3rd VPN client with just the new file. Lets see how that goes over the weekend.

Is below guide actually still valid, as I don't have an Firewall entry that I can set to automatic.
https://www.privateinternetaccess.com/helpdesk/guides/routers/merlin/merlin-firmware-openvpn-setup

As the date on the guide is prior to when Merlin released 384.9 the answer is maybe or mostly valid. It will probably work but you need to download a current ovpn file from PIA and then if you see issues in your log fix the problems. Where the biggest issues usually come from is when you add home brewed tweaks to the custom config trying to improve throughput.

 

[BlezZ]

As the date on the guide is prior to when Merlin released 384.9 the answer is maybe or mostly valid. It will probably work but you need to download a current ovpn file from PIA and then if you see issues in your log fix the problems. Where the biggest issues usually come from is when you add home brewed tweaks to the custom config trying to improve throughput.

So far so good with latest OVPN file and pretty much default config. I have disabled cipher neg as it fails anyway with PIA.

custom config is:
resolv-retry infinite
tls-client
remote-cert-tls server
disable-occ
auth-nocache
pull-filter ignore "auth token"
pull-filter ignore "ifconfig-ipv6"
pull-filter ignore "route-ipv6"


I am happy with the throughput at 30mbit over VPN. I have a fibre link into the garage so speed is ok.

Log files shows that every time I access the VPN, it goes down but then comes up again, which is strange. Today around 11am and just now around 19pm.
As long as it comes up automatically I am fine. But it did not before and the client only showed "authentication failed"


Mar 29 11:10:26 ovpn-client3[5012]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 29 11:10:37 ovpn-client3[5012]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 29 11:10:39 openvpn-routing: Configuring policy rules for client 3
Mar 29 11:10:40 openvpn-routing: Removing rule 10501 from routing policy
Mar 29 11:10:40 openvpn-routing: Removing rule 10502 from routing policy
Mar 29 11:10:40 openvpn-routing: Tunnel down - VPN client access blocked
Mar 29 11:10:40 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 3
Mar 29 11:10:40 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 3
Mar 29 11:10:40 openvpn-routing: Completed routing policy configuration for client 3
Mar 29 11:10:40 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 11:10:40 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 11:10:40 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 11:10:46 openvpn-routing: Configuring policy rules for client 3
Mar 29 11:10:46 openvpn-routing: Creating VPN routing table (mode 2)
Mar 29 11:10:46 openvpn-routing: Removing route for 10.22.10.1 to tun13 from main routing table
Mar 29 11:10:46 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
Mar 29 11:10:46 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
Mar 29 11:10:46 openvpn-routing: Removing rule 10501 from routing policy
Mar 29 11:10:46 openvpn-routing: Removing rule 10502 from routing policy
Mar 29 11:10:47 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 3
Mar 29 11:10:47 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 3
Mar 29 11:10:47 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Mar 29 11:10:47 openvpn-routing: Completed routing policy configuration for client 3
Mar 29 19:12:37 ovpn-client3[5012]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mar 29 19:12:44 openvpn-routing: Configuring policy rules for client 3
Mar 29 19:12:45 openvpn-routing: Removing rule 10501 from routing policy
Mar 29 19:12:45 openvpn-routing: Removing rule 10502 from routing policy
Mar 29 19:12:45 openvpn-routing: Tunnel down - VPN client access blocked
Mar 29 19:12:45 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 3
Mar 29 19:12:45 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 3
Mar 29 19:12:45 openvpn-routing: Completed routing policy configuration for client 3
Mar 29 19:12:45 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 19:12:45 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 19:12:45 ovpn-client3[5012]: ERROR: Linux route delete command failed: external program exited with error status: 2
Mar 29 19:12:51 openvpn-routing: Configuring policy rules for client 3
Mar 29 19:12:51 openvpn-routing: Creating VPN routing table (mode 2)
Mar 29 19:12:51 openvpn-routing: Removing route for 10.73.10.1 to tun13 from main routing table
Mar 29 19:12:51 openvpn-routing: Removing route for 0.0.0.0/1 to tun13 from main routing table
Mar 29 19:12:51 openvpn-routing: Removing route for 128.0.0.0/1 to tun13 from main routing table
Mar 29 19:12:51 openvpn-routing: Removing rule 10501 from routing policy
Mar 29 19:12:51 openvpn-routing: Removing rule 10502 from routing policy
Mar 29 19:12:51 openvpn-routing: Adding route for 192.168.1.10 to 0.0.0.0 through VPN client 3
Mar 29 19:12:51 openvpn-routing: Adding route for 192.168.1.100 to 0.0.0.0 through VPN client 3
Mar 29 19:12:51 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Mar 29 19:12:51 openvpn-routing: Completed routing policy configuration for client 3

 

[BlezZ]

So far, everything is working fine. The tunnel goes sometimes down but then back up again.

Thanks to everyone for their help.

 

[Namrustler]

I never had problems with PIA until I upgraded to 384.10. I also see the problem under 384.10.2, so I rolled back to 384.9 and it seems okay.

I have the RT-AC86U with the first OpenVPN client configured for PIA. I'm using "Policy Rules" with the kill switch enabled. I route three IP addresses through the VPN. These IP addresses belong to three Windows 7 VMs.

On each VM I'm running OpenVPN and will connect to either PIA or ibVPN since I subscribe to both services. I realize I'm tunneling with a tunnel.

If the Windows 7 client maintains it tunnel, I'm okay. But sometime when I disconnect the Windows 7 client, it can no longer access the Internet. At this point, I'll notice that the other two Windows computers cannot access the Internet because it's like the router's VPN client is blocking them.

However, the status of the router's VPN client is "connected" and there are no messages in the system log that indicate a problem.
If I click the Apply button at the bottom of the page for configuring the router's VPN client, the three computers now tunnel properly through the router's VPN client.

Merlin suggested earlier in this thread to redownload the ovpn files from PIA, but that didn't resolve the problem. I also tried different variations of commands for the custom configuration but that has not worked.

The problem seems to take several hours to occur but I haven't tried to determine if it happens after a specific amount of time or is random.

The annoying thing is that looking at the router's VPN status doesn't lead you to think the problem lies there. Everything looks fine.

I've noticed in 384.10 and 384.10.2 there are error messages I never saw in earlier firmwares:

Apr 4 22:29:51 ovpn-client1[1466]: /bin/ip route del 10.47.10.1/32
Apr 4 22:29:51 ovpn-client1[1466]: ERROR: Linux route delete command failed: external program exited with error status: 2
Apr 4 22:29:51 ovpn-client1[1466]: /bin/ip route del 199.229.249.199/32
Apr 4 22:29:51 ovpn-client1[1466]: /bin/ip route del 0.0.0.0/1
Apr 4 22:29:51 ovpn-client1[1466]: ERROR: Linux route delete command failed: external program exited with error status: 2
Apr 4 22:29:51 ovpn-client1[1466]: /bin/ip route del 128.0.0.0/1
Apr 4 22:29:51 ovpn-client1[1466]: ERROR: Linux route delete command failed: external program exited with error status: 2
Apr 4 22:29:51 ovpn-client1[1466]: Closing TUN/TAP interface

However, I don't understand the significance of these error messages.

Does anyone have any thought on this?