Beta VPN Director testing

[RMerlin]

@octopus , @kernol : I think you might both have the same issue, just that it shows differently. I opened an account with VPN Unlimited so I could reproduce the issue, and I found what was causing problems with VPN Unlimited - the remote variable I was using to configuring routes wasn't working because it contained a hostname pointing to a round-robin series of A records. Configuring the route using the trusted_ip variable instead fixed it. I suspect the two pools used by @octopus's provider was having similar issue, except it also generated that extra error message that VPN Unlimited wasn't.

I'll try to push new builds later tonight so you can both test it.

 

[octopus]

That would be from iproute2.

Try setting verbosity of the OpenVPN client to 6 instead of the default 3, connect your client, and post the system log result. It will show most of the iproute calls as they are done, which might help tracking down which specific command is sent just before the error.

Here is log with verboseity set to 6.

https://pastebin.com/qpsnV5JF

 

[RMerlin]

Here is log with verboseity set to 6.

https://pastebin.com/qpsnV5JF

Odd, your log is missing all the openvpn-routing debug entries that should be generated when routes are added through iproute2, even though verbosity seems to be set correctly based on the rest of the debugging info. Do you have anything set that filters your syslog content? It should contain entries looking like this:

Jun 26 14:14:02 openvpn-routing: Add pushed route: /usr/ sbin/ip route add 10.200.0.1/255.255.255.255 via 10.200.0.29 dev tun11 metric 1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Add route to remote endpoint: /usr/ sbin/ip route add ca.vpnunlimitedapp.com via 192.168.10.1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Setting client 1 routing table's default route through the tunnel

 

[octopus]

Odd, your log is missing all the openvpn-routing debug entries that should be generated when routes are added through iproute2, even though verbosity seems to be set correctly based on the rest of the debugging info. Do you have anything set that filters your syslog content? It should contain entries looking like this:

Jun 26 14:14:02 openvpn-routing: Add pushed route: /usr/ sbin/ip route add 10.200.0.1/255.255.255.255 via 10.200.0.29 dev tun11 metric 1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Add route to remote endpoint: /usr/ sbin/ip route add ca.vpnunlimitedapp.com via 192.168.10.1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Setting client 1 routing table's default route through the tunnel

No i don't have any filter scripts, I don't use any 3rd party script except one, ChkWAN from Martineau.
Tested to turn off openvpn-event script but same reusult there.

 

[RMerlin]

No i don't have any filter scripts, I don't use any 3rd party script except one, ChkWAN from Martineau.
Tested to turn off openvpn-event script but same reusult there.

Where did you get the syslog content? It's also missing the identifier field, and contain that ùs=xxxxx field that's not there in a regular Asuswrt syslog.

If you are sending the log to a remote syslog server, that might be what's filtering the content.

Anyway, test again when I uploaded updated builds to see if it also addresses your specific issues.

 

[octopus]

Where did you get the syslog content? It's also missing the identifier field, and contain that ùs=xxxxx field that's not there in a regular Asuswrt syslog.

If you are sending the log to a remote syslog server, that might be what's filtering the content.

Anyway, test again when I uploaded updated builds to see if it also addresses your specific issues.

Only send syslog to:
log /tmp/vpnclient-1.log
Not to regular log page.

 

[RMerlin]

Updated test builds uploaded (they should appear on Onedrive over the next couple of minutes).

96f8b95ddd libovpn: cleanup client instance on ovpn_stop_client() even if client isn't running
48cfcb7e64 libovpn: set remote endpoint route by its actual IP instead of the --remote parameter
9201127d1f rc: allow Guest Network 1 clients to use an OpenVPN tunnel in the firewall
8b46b2db6b libovpn: clarify log entries for VPN Director rule configuration

 

[octopus]

Updated test builds uploaded (they should appear on Onedrive over the next couple of minutes).

96f8b95ddd libovpn: cleanup client instance on ovpn_stop_client() even if client isn't running
48cfcb7e64 libovpn: set remote endpoint route by its actual IP instead of the --remote parameter
9201127d1f rc: allow Guest Network 1 clients to use an OpenVPN tunnel in the firewall
8b46b2db6b libovpn: clarify log entries for VPN Director rule configuration

Just tested new build and "error" in log is gone. All routes with my 3 clients working.

I don't have this in log. ( I using: VPN Director (policy rules) )

Jun 26 14:14:02 openvpn-routing: Add pushed route: /usr/ sbin/ip route add 10.200.0.1/255.255.255.255 via 10.200.0.29 dev tun11 metric 1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Add route to remote endpoint: /usr/ sbin/ip route add ca.vpnunlimitedapp.com via 192.168.10.1 table ovpnc1
Jun 26 14:14:02 openvpn-routing: Setting client 1 routing table's default route through the tunnel

I have this in log.

Jun 27 08:14:03 openvpn-routing: Setting client 1 routing table's default route through the tunnel
Jun 27 08:14:03 openvpn-routing: Setting client 3 routing table's default route through the tunnel
Jun 27 08:14:03 openvpn-routing: Routing Tun22-route from 10.8.40.3 to any through ovpnc3
Jun 27 08:14:03 openvpn-routing: Routing LANtoVPN from 192.168.12.0/24 to any through ovpnc1
Jun 27 08:14:03 openvpn: Forcing 10.8.40.3 to use DNS server 46.227.67.134
Jun 27 08:14:03 openvpn-routing: Setting client 2 routing table's default route through the tunnel
Jun 27 08:14:03 openvpn: Forcing 192.168.12.0/24 to use DNS server 46.227.67.134
Jun 27 08:14:03 openvpn-routing: Routing DummyIP from 172.16.32.8 to any through ovpnc2
Jun 27 08:14:04 openvpn: Forcing 172.16.32.8 to use DNS server 46.227.67.134

Jun 27 08:14:00 openvpn-routing: Routing DummyIP from 172.16.32.8 to any through ovpnc2
Jun 27 08:14:00 openvpn-routing: Configured killswitch on VPN client 2

Jun 27 08:14:01 openvpn-routing: Routing Tun22-route from 10.8.40.3 to any through ovpnc3
Jun 27 08:14:01 openvpn-routing: Configured killswitch on VPN client 3

Jun 27 08:13:57 openvpn-routing: Routing LANtoVPN from 192.168.12.0/24 to any through ovpnc1
Jun 27 08:13:57 openvpn-routing: Configured killswitch on VPN client 1

May 5 07:05:15 openvpn-routing: Routing LANtoVPN from 192.168.12.0/24 to any through ovpnc1
May 5 07:05:15 openvpn-routing: Configured killswitch on VPN client 1
May 5 07:05:15 openvpn-routing: Routing DummyIP from 172.16.32.8 to any through ovpnc2
May 5 07:05:15 openvpn-routing: Configured killswitch on VPN client 2
May 5 07:05:15 openvpn-routing: Routing Tun22-route from 10.8.40.3 to any through ovpnc3
May 5 07:05:15 openvpn-routing: Configured killswitch on VPN client 3

 

[TimmyL]

Hi Merlin,

Is it possible to add a protocol for NordLynx ?

 

[kernol]

Updated test builds uploaded (they should appear on Onedrive over the next couple of minutes).

96f8b95ddd libovpn: cleanup client instance on ovpn_stop_client() even if client isn't running
48cfcb7e64 libovpn: set remote endpoint route by its actual IP instead of the --remote parameter
9201127d1f rc: allow Guest Network 1 clients to use an OpenVPN tunnel in the firewall
8b46b2db6b libovpn: clarify log entries for VPN Director rule configuration

Many thanks @RMerlin - definitely working with VPNUnlimited now - tested "Accept DNS Config" = Disabled and = Exclusive ...
Plus tested Redirect internet = Yes (all) and = VPN Director Policy rules.

Here's the thing though [my lack of knowledge?] ...

• when using Accept DNS = Disabled - DNS leak test shows correct tunnel public ip and correct DNS public ip [as per Router setting - be it Cloudflare or Quad9] ... BUT
• when using Accept DNS = Exclusive - DNS leak test shows correct tunnel public ip but identifies the DNS by the same public ip as the tunnel - be it Cloudflare or Quad9 - same issue [NB doesn't seem to matter whether one has DNS filter set or not].

I expected when using Exclusive that the DNS public ip would be the one belonging to the chosen DNS service rather than the public tunnel ip of the VPN service ???

 

[kernol]

@RMerlin - any chance you can add to the VPN Status screen in the webui - see pic below - the public ip of the DNS being used with the particular connection? If it's a stoopid idea - ignore. Would have been useful while I did the testing .

 

[RMerlin]

when using Accept DNS = Exclusive - DNS leak test shows correct tunnel public ip but identifies the DNS by the same public ip as the tunnel - be it Cloudflare or Quad9 - same issue [NB doesn't seem to matter whether one has DNS filter set or not].

As long it doesn't show your ISP's IP, that's fine. Keep in mind that those test sites can only report which IP sent them the query. It might not necessarily be the same IP as was configured in your router, particularly if the provider uses anycast IP addresses to reroute queries.

ny chance you can add to the VPN Status screen in the webui - see pic below - the public ip of the DNS being used with the particular connection? If it's a stoopid idea - ignore. Would have been useful while I did the testing

A DNS server is not tied to a VPN connection, so there is no way to tell which DNS server is used to send queries through a specific tunnel.

 

[RMerlin]

Hi Merlin,

Is it possible to add a protocol for NordLynx ?

Not possible. In fact, NordVPN doesn't even provide config files for it, the only way to use it is through their proprietary application.

 

[kernol]

A DNS server is not tied to a VPN connection, so there is no way to tell which DNS server is used to send queries through a specific tunnel.

So setting "Accept DNS Configuration" = "Exclusive" doesn't tie the VPN service providers DNS to the tunnel ??? Or it does so ... but there is no way of knowing what its DNS ip address is? How does DNS leak test find it ? Excuse my ignorance - but I thought at the time the tunnel came up it may have been possible to identify the DNS assigned by the Client settings.

 

[RMerlin]

So setting "Accept DNS Configuration" = "Exclusive" doesn't tie the VPN service providers DNS to the tunnel ??? Or it does so

OpenVPN in itself has no understanding of a DNS. All it does is receive whichever DNS server is pushed at the remote end, and provide it as a series of environment variables, for the firmware to do whatever it wants to do with it at connect time. It could very well be ignored, or overridden by the user, so there's no way for the status page to know for sure.

What Exclusive mode does is have the firmware take whatever DNS is provided at connection time through those environmental variables, and configure iptables rules for it, trying to match the IP addresses of the clients that are redirected through the tunnel, and having then NAT'ed to the DNS provided at connect time.

How does DNS leak test find it ?

One way to do it is when you visit the test page, it contains a unique DNS hostnames that your browser tries to resolve. The test site controls the authoritative DNS server for that particular domain, so it receives the DNS query from you for that unique hostname, which tells it the IP address of the server that queried it. It can then push it to your web page.

 

[octopus]

Now new vpn working fine.
I have a suggestion, is it possible to have different coulor on start client /stop client on VPN direktor page it is eaysier over look then.
@RMerlin

 

[RMerlin]

Now new vpn working fine.
I have a suggestion, is it possible to have different coulor on start client /stop client on VPN direktor page it is eaysier over look then.
@RMerlin

It`s already using the highlight colour instead of the regular text coulour.

 

[octopus]

It`s already using the highlight colour instead of the regular text coulour.

What I meant is different colour start/stop client. Ex stop= light colour and start highlight colour as it is.
It's easier overlook with different color.

 

[RMerlin]

What I meant is different colour start/stop client. Ex stop= light colour and start highlight colour as it is.
It's easier overlook with different color.

That would clash with the rest of the UI design, where only two colours are used for general text elements. There's already a highlight used for the Connected/Disconnected state, I don't see the point of also making the stop/start link change colour.

 

[octopus]

That would clash with the rest of the UI design, where only two colours are used for general text elements. There's already a highlight used for the Connected/Disconnected state, I don't see the point of also making the stop/start link change colour.

Okey. I understand it was just a suggestion. Thanks.