bottleneck
Choose style:

Author Topic: Please, fix OpenVPN CLIENT already!  (Read 546 times)

0 Members and 1 Guest are viewing this topic.

Offline Artik

  • Backer
  • *
  • Posts: 10
  • Thanks: 0
  • Registered : 07/09/2013
    YearsYearsYearsYears
Please, fix OpenVPN CLIENT already!
« on: April 08, 2017, 04:59:43 pm »
Back in September 2016 we had a long troubleshooting session with Securifi specialists trying to make Almond+ connect to a remote VPN server. Results: a pdf with instructions to manually set up connection using SSH console and a promise to address the problem in a future firmware, which so far didn't happen. I've spent today trying to set up at least some scripts to quickly turn VPN client on or off; as a side effect, I realized there are actually around 3 separate bugs in Almond's OpenVPN client implementation that need addressing (Securifi specialists probably figured that out back in September, but they weren't too open about their findings):

1)OpenVPN crashes immediately on launch because of inline certificate error. This happens if some of the certificate fields are left empty (if they are not required or provided by your VPN service). As a result, the client.ovpn config file will contain empty blocks like <cert> </cert>. Workaround: after pressing "save>connect>disconnect" manually delete empty intermediary certificate files (i.e. client.cacert). Deleting faulty blocks in client.ovpn won't help as it is regenerated when you press "connect"

2)Routing settings are not applied properly. When you press "connect", Almond changes routing /etc/config/network and /etc/config/ntpclient. These changes are more or less sufficient (see bug 3), but they are not applied fully. Reboot helps - but it's not an option for a web interface. Some way of reloading everything related to this routing must be found. If we keep these changes, reboot, relaunch openvpn client, it will finally work, except

3)Broken DNS. DNS settings are successfully received from VPN service, as evidenced by openvpn logs, but they are lost somewhere on the way towards LAN. Workaround: set up google DNS (8.8.8.8 8.8.4.4) manually either on each client, or in OpenWRT>Network>Interfaces>LAN.

What this means for users: you can make OpenVPN client work manually, via command line (or you can write a couple shell scripts). The attached pdf from Securifi has the right idea, but does a few unnecessary things. Follow these instructions, but for /etc/config/network use
Code: [Select]
config 'interface' 'loopback'
        option 'ifname' 'lo'
        option 'proto' 'static'
        option 'ipaddr' '127.0.0.1'
        option 'netmask' '255.0.0.0'

config 'interface' 'wan'
        option 'broadcast' '0'
        option 'ifname' 'tun1'
        option 'proto' 'none'

config 'interface' 'lan'
        option 'ifname' 'eth1'
        option 'type' 'bridge'
        option 'proto' 'static'
        option 'ipaddr' '10.10.10.254'
        option 'netmask' '255.255.255.0'
        option 'bcast' '10.10.10.255'
        option 'dns' '8.8.8.8 8.8.4.4'

config 'interface' 'wan1'
        option 'proto' 'dhcp'
        option 'ifname' 'eth0'
and for /etc/config/ntpclient use
Code: [Select]
config 'ntpserver'
        option 'hostname' '0.pool.ntp.org'
        option 'port' '123'

config 'ntpserver'
        option 'hostname' '1.pool.ntp.org'
        option 'port' '123'

config 'ntpserver'
        option 'hostname' '2.pool.ntp.org'
        option 'port' '123'

config 'ntpserver'
        option 'hostname' '3.pool.ntp.org'
        option 'port' '123'

config 'ntpdrift'
        option 'freq' '0'

config 'ntpclient'
        option 'interval' '600'
        option 'interface' 'wan1'
This is almost exactly what the OpenWRT-side script would've done, except for an additional DNS setting. Also, wait about 5 minutes after router reboots for connection to actually start working.

And Securifi: I can't stress this enough, you need to finally fix this. It's a basic feature which was supposed to be available since day 1.

Offline rvanee

  • Newbie
  • Posts: 1
  • Thanks: 0
  • Registered : 20/07/2015
    YearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #1 on: April 09, 2017, 11:35:58 am »
Artik....thanks very much for this informative summary and status. I was just about to start looking into the OpenVPN CLIENT myself and this saved me much time.

Offline mbirnbaum

  • Newbie
  • *
  • Posts: 5
  • Thanks: 0
  • Registered : 12/03/2017
Re: Please, fix OpenVPN CLIENT already!
« Reply #2 on: April 16, 2017, 09:40:12 pm »
Amen

Offline nsgnfcnt1

  • Backer
  • *
  • Posts: 10
  • Thanks: 0
  • Registered : 29/08/2014
    YearsYearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #3 on: April 17, 2017, 04:34:44 pm »
Bump

Offline spooky123

  • Backer
  • *
  • Posts: 129
  • Thanks: 0
  • Registered : 30/09/2014
    YearsYearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #4 on: April 20, 2017, 04:04:41 pm »
I agree, I was going to retry OpenVPN setup (haven't tried in the last firmware iterations, but glad I checked in here before bothering.

Offline w0b

  • Peanut
  • **
  • Posts: 10
  • Thanks: 0
  • Registered : 04/01/2015
    YearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #5 on: June 16, 2017, 03:26:02 pm »
Bump!

Offline ecamou

  • Backer
  • *
  • Posts: 4
  • Thanks: 0
  • Registered : 02/08/2013
    YearsYearsYearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #6 on: June 19, 2017, 10:29:27 am »
Thank you Artik

You have actually provided more useful information than anybody from Security Staff regarding VPN Client support...

Really Securifi,  you answered that VPN Client WOULD WORK on the Almond+ on that particular question I asked you on Kickstarter.

Offline trancethereal

  • Backer
  • *
  • Posts: 2
  • Thanks: 0
  • Registered : 02/08/2013
    YearsYearsYearsYears
Re: Please, fix OpenVPN CLIENT already!
« Reply #7 on: June 23, 2017, 11:37:41 am »
Bump for visibility...

I assume this is centered around the same issue as discussed in another thread "Private Internet Access VPN" - wonder if that topic should be merged or at least highlight this as a growing concern and feature request (or feature promised, but not delivered).

Personally, I get the sense that having a way to easily and reliably connect to a third party vpn service is going to be the next "obvious" feature for routers ... and further have the ability to segregate  traffic (ie voip that should not route through the vpn service) ...

I personally would vote for a more finished solution ... (not scripting) in order to implement. It should be a tab that is accessible like the "Rules" tab.

 

Page created in 0.069 seconds with 18 queries.

bottleneck