OPENVPN on smartphone

[negan07]

It has been noticed a bug affecting vpn connection with smartphone: explain in details what happen.

[mcrs969]

Hi Negan,I'll do my best as I am not an expert.

So: phone links to D7000 with OpenVPN but no traffic is generated. Tried either with Android either with iOs with different versions, no change.

A guy, who names himself lazzar0 in a forum posted a interesting workaround that fixes this issue in all official FWs (I have not tested .50 yet)

"yes I confirm guys you have to edit lane 26 of file /etc/server_phone.conf.

You'll find a line like:

push "route 192.168.1.1 255.255.255.0" (in place of 192.168.1.1 you could find 192.168.0.1 , this depends by the way of addressing you set of your internal LAN, my one is 192.168.1.0/24 for example).

you should edit it in:

push "route 192.168.1.0 255.255.255.0"

This lane substantially instructs the client VPN on how routing packets with destination in your LAN. So we're saying to client: "Dear Client, to reach network 192.168.1.0/24 - or 192.168.0.0/24 according to the case - use TUN, so VPN interface". Otherwise the client would attempt to reach the network 192.168.1.0/24 through default gateway - so by the interface on internet of the mobile device.

The bug of configuration stays in the fact that the instruction "route" could accept two types of routing, or to a complete network or to a specific host.

if it were a route to host (so we link to a specific host to route packets only destinated to that host) we would have:

push "route 192.168.1.1 255.255.255.255" so we would not have problems.

But since we are routing a complete netwrok the correct sintax will be: push "route 192.168.1.0 255.255.255.0".

originally the sintax is wrong because: push "route 192.168.1.1 255.255.255.0" (original lane) seems a routing to host, 192.168.1.1, nevertheless the netmask is wrong because it should be 255.255.255.255 and the VPN client gets angry a bit."

So, I am not sure the data from the guy is safe or is "structured" to be part of a production firmware, but it works, meaning that somehow he found something linked to the problem.

Negan07, hope this can help you and please let me know as I have 2 D7000 so I would love to help, I believe it is not acceptable to deal with such issue for so long.

I did not translate fully the message but to be fair with him I wish to say that this guy posted on hwupgrade.it and herewith the text in Italian:

ciao a tutti, si confermo dovete necessariamente modificare la riga 26 del file /etc/server_phone.conf.

Troverete una riga del tipo :

push "route 192.168.1.1 255.255.255.0" (al posto di 192.168.1.1 potreste trovare 192.168.0.1 , questo dipende dal piano di indirizzamento della vostra LAN interna, la mia sta su 192.168.1.0/24 ad esempio).

dovete andare a modificarla in :

push "route 192.168.1.0 255.255.255.0"

Questa riga sostanzialmente istruisce il client VPN su come instradare i pacchetti destinati alla vostra LAN. In pratica stiamo dicendo al client : "Caro client per raggiungere la rete 192.168.1.0/24 - oppure 192.168.0.0/24 a seconda dei casi - utilizza l'interfaccia tun ossia l'interfaccia VPN". Diversamente il client tenterebbe di raggiungere la rete 192.168.1.0/24 tramite default gateway - presumibilmente quindi interfaccia verso internet del dispositivo mobile.

Il bug di configurazione sta nel fatto che l'istruzione route può accettare due tipi di instradamento, ossia verso una rete completa o verso un host specifico.

Se fosse stato un route to host (ossia puntiamo un host specifico per ruotare i pacchetti solo destinati a quell'host) avremmo :

push "route 192.168.1.1 255.255.255.255" e allora non ci sarebbero problemi.

Però dato che noi stiamo instradando una rete completa la sintassi corretta sarà : push "route 192.168.1.0 255.255.255.0".

Originariamente la sintassi è sbagliata perchè push "route 192.168.1.1 255.255.255.0" (riga originale) sembra un puntamento to host, 192.168.1.1, tuttavia la netmask è sbagliata perchè dovrebbe essere 255.255.255.255 e il client VPN si incazza non poco.

Un mio parere personalissimo : questo tipo di sviste sono ahimè dimostrazione che questi fw sono davvero testati poco e rilasciati con troppa fretta (anche se da un rilascio all'altro passano mesi paradossalmente). Non sono bug implementativi su GUI , o problemi di instabilità del kernel o dei driver. Sono svite di configurazione anche piuttosto grossolane.

Quello che dico io è : rilasciano un fw con (finalmente) il supporto alle VPN tun per i dispositivi mobili. Credo sia evidente che questa sia una major feature quindi un'implementazione e un rilascio importanti - peraltro feature richiestissima da mesi sia qui che in altri forum. Ma possibile che nessuno abbia testato che funzionasse correttamente tutto il giro ? Sembra come se i loro test si fossero ridotti e limitati a : proviamo a collegarci con smartphone, bene si connette. FINE DEL TEST. Ma come ?!?!?!? Possibile che non viene in mente a nessuno di fare un ping verso un host della LAN interna una volta stabilita la VPN ?

Per quanto riguarda la collaborazione con Netgear ci stiamo lavorando

[negan07]

it seems to be a simple config problem converting /usr/sbin/rc_app/rc_openvpn symlink to a script starting with /usr/sbin/rc_app/rc_apps and then editing the file just created changing the above line with awk or tail/sed

this can be also the occasion to update all the openvpn package that is old and superficially configured improving security and adding some more useful features

[negan07]

please post a running /etc/server_phone.conf complete conf file

edit personal config data if any before

[mcrs969]

Hi Negan,

I place here my one just as it is after FW upgrade and setting up configuration from NETGEAR GUI,

`dh /tmp/openvpn/dh2048.pem ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/server.crt key /tmp/openvpn/server.key dev tun
server 192.168.2.0 255.255.255.0 proto udp
port 52973
keepalive 10 120 verb 5 mute 5
log-append /tmp/openvpn_log writepid /tmp/openvpnd.pid mtu-disc yes
topology subnet
cipher AES-128-CBC auth sha1 tls-server
push "redirect-gateway def1 bypass-dhcp" client-to-client duplicate-cn comp-lzo fast-io
push "route 192.168.5.1 255.255.255.0"

• /etc/server_phone.conf 1/24 4% `

I intentionally move my network on 192.168.5.1, unfortunately it seems that saving modifications to /etc/server_phone.conf is not working, specially after reboot of router the "wrong" setup is loaded again.

[negan07]

to apply modifications you have to edit then /usr/sbin/openvpn --config /etc/server_phone.conf

this topic results interesting

https://community.netgear.com/t5/DSL-Modems-Routers/D7000-OpenVPN-Server-configuration-issue/td-p/1177464/page/2

if there is an old beta fw already fixed grabbing its rc_apps file renaming rc_openvpn solves the problem at all

[mcrs969]

Hi negan07,

I guess I may have access to that FW but I am too "basic user" to understand what to do with it, shall I 1 mount fw 2 where do I find which files? 3 how do I grab? 4 where do I place them into the .50? 5 how do I place? 0... do you need them?

Will this fix be part of your package? I am not installing your ancistrus as I need the mobile VPN.. :(

[negan07]

simply: upload this beta firmware fixing this openvpn somewhere (or link me where to download it because i dont have it)

then creating a package is very easy, it is a simply file substitution that can be done manually

[negan07]

openvpn 2.4.4 is on the src

cannot test it deeply with mobile but it seems the correct settings seems to have been applied properly

opkg update
opkg list

and can be seen

for safety make a backup of old /usr/sbin/openvpn exec make sure to have enough space on flash install the package with: opkg install openvpn

to revert back rc openvpn stop move the backup openvpn on /usr/sbin rm /usr/sbin/rc_app/rc_*vpn

ln -sf /etc/rc_apps /usr/sbin/rc_app/rc_vpn
ln -sf /etc/rc_apps /usr/sbin/rc_app/rc_openvpn

and then rc openvpn restart

[negan07]

no news from this: it seems got through

[negan07]

from the 1.0.1.54 fw the above settings fix has been included