OpenVPN Connect fails connecting using a proven good ovpn file from Windows and OpenVPN for Android by A.Schwabe: Solved

[MostlyHarmless]

Hi,

I have been pulling my hair out for many hours trying to get OpenVPN Connect for Android on a Samsung S20 FE 5G.

The app seems to connect ok - as my phone gets correct ip address.

But the routing seems to be failing - I can ping my self, but no other local computers on my network on any subnets.

I created the ovpn file by testing on OpenVPN Connect for Windows (win11pro) - and it works perfect, but was unable to get OpenVPN for Android to access my internal servers. After googling I came by OpenVPN for Android by Arne Schwabe - and imported the same ovpn file - and it just worked immediately

So now I have found a solution for me - but just in a way that make be wonder how far I was to make it work on OpenVPN Connect for Android.

My server setup (open-wrt) I am using port 1195 as I have my tap based vpn on 1194:
config openvpn 'bv_tun'
option dev 'tun'
option port '1195'
option proto 'udp'
option server '10.10.10.0 255.255.255.0'
option ca '/etc/openvpn/ca.crt'
option cert '/etc/openvpn/fw.crt'
option key '/etc/openvpn/fw.key'
option dh '/etc/openvpn/dh2048.pem'
option comp_lzo 'yes'
option mssfix '1420'
option keepalive '10 60'
option verb '3'
option enabled '1'
option log '/tmp/openvpntun.log'
option push 'route 10.99.0.0 255.255.0.0'

My client setup:
client
dev tun
proto udp
remote my.ddns.ip 1195
nobind
persist-key
persist-tun
ca bv_ca.crt
cert hp820.crt
key hp820.key
compress lzo
verb 3
remote-cert-tls server

Anyone knows why this works perfect on Arne Schwabes OpenVPN for Android and not on OpenVPN Connect for Android?
My firewall settings on the OpenWRT is as said ok as both OpenVPN Connect for windows and Arne Schwabes android app works perfect.

I have read on this forum that I should remove compress - so will do. Just posted my findings here as I got it to work.

Best Regards,
Arild

[openvpn_inc]

Hello Arild,

Do you have client side logs from OpenVPN Connect? Kind of hard to guess at what's going wrong.

If it contains sensitive data, better to open a support ticket on https://openvpn.net/support

Kind regards,
Johan

[MostlyHarmless]

Installed OpenVPN Connect again and same result with this log:

15:17:48.100 -- EVENT: DISCONNECTED trans=TO_DISCONNECTED

15:17:48.100 -- Tunnel bytes per CPU second: 0

15:17:48.101 -- ----- OpenVPN Stop -----

15:17:49.462 -- ----- OpenVPN Start -----

15:17:49.462 -- EVENT: CORE_THREAD_ACTIVE

15:17:49.464 -- OpenVPN core 3.git::d3f8b18b:Release android arm64 64-bit PT_PROXY

15:17:49.465 -- Frame=512/2048/512 mssfix-ctrl=1250

15:17:49.467 -- UNUSED OPTIONS
4 [nobind]
5 [persist-key]
6 [persist-tun]
11 [verb] [3]

15:17:49.467 -- EVENT: RESOLVE

15:17:49.482 -- Contacting x.y.z.w:1195 via UDP

15:17:49.484 -- EVENT: WAIT

15:17:49.491 -- Connecting to [x.y.z.w]:1195 (x.y.z.w) via UDPv4

15:17:49.522 -- EVENT: CONNECTING

15:17:49.524 -- Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client

15:17:49.525 -- Creds: UsernameEmpty/PasswordEmpty

15:17:49.526 -- Peer Info:
IV_VER=3.git::d3f8b18b:Release
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_AUTO_SESS=1
IV_GUI_VER=net.openvpn.connect.android_3.3.0-8367
IV_SSO=webauth,openurl
IV_BS64DL=1


15:17:49.555 -- VERIFY OK: depth=1, /C=NO/ST=MyTown/L=MyTown/O=MyName/OU=BVOU/CN=MyEmail/name=MyDomain/emailAddress=MyEmail, signature: RSA-SHA256

15:17:49.555 -- VERIFY OK: depth=0, /C=NO/ST=MyTown/L=MyTown/O=MyName/OU=BVOU/CN=MyEmail/name=MyDomain/emailAddress=MyEmail, signature: RSA-SHA256


15:17:49.582 -- SSL Handshake: peer certificate: CN=MyDomain, 2048 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD


15:17:49.583 -- Session is ACTIVE

15:17:49.583 -- EVENT: GET_CONFIG

15:17:49.585 -- Sending PUSH_REQUEST to server...

15:17:49.600 -- OPTIONS:
0 [route] [10.99.0.0] [255.255.0.0]
1 [route] [10.10.10.1]
2 [topology] [net30]
3 [ping] [10]
4 [ping-restart] [60]
5 [ifconfig] [10.10.10.6] [10.10.10.5]
6 [peer-id] [0]
7 [cipher] [AES-256-GCM]


15:17:49.600 -- PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: NONE
key-derivation: OpenVPN PRF
compress: COMP_STUB
peer ID: 0

15:17:49.600 -- EVENT: ASSIGN_IP

15:17:49.618 -- Connected via tun

15:17:49.619 -- LZO-ASYM init swap=0 asym=1

15:17:49.619 -- Comp-stub init swap=1

15:17:49.619 -- EVENT: CONNECTED info='x.y.z.w:1195 (x.y.z.w) via /UDPv4 on tun/10.10.10.6/ gw=[10.10.10.5/]'

[MostlyHarmless]

Hi,

I removed the sensitive data from the logs. If you want me to test with deeper loglevel or other things, I will do.
I can open a support ticket if you want me to then.

Best Regards,
Arild

Hello Arild,

Do you have client side logs from OpenVPN Connect? Kind of hard to guess at what's going wrong.

If it contains sensitive data, better to open a support ticket on https://openvpn.net/support

Kind regards,
Johan

[openvpn_inc]

Hello,

The server config states:
option server '10.10.10.0 255.255.255.0'
option push 'route 10.100.0.0 255.255.0.0'

On the client side log I see:
0 [route] [10.99.0.0] [255.255.0.0]
1 [route] [10.10.10.1]

Why are the subnets 10.100.0.0/16 and 10.99.0.0/16 different? Maybe this is your problem?

Have you done ping tests with packet capturing on the server to verify that pings from the client are arriving at the server?

Kind regards,
Johan

[MostlyHarmless]

I am so sorry! I posted this topic from another computer than running openvpn - so copied one of the wrong settings-files on the road to the one that are running and works for Windows and Schwabes app I have updated my first post now.

All my sub-nets are on the 10.99.x.x range
So i push route 10.99.0.0 255.255.0.0 to reach all subnets on my network from my vpn client.

I choose 10.10.10.0 on my tun adapter to be on another subnet completely different. (originally I choose 10.99.10.0 for my tun adapter, but that way I had to use three push route subnets, while I was suspecting that was my problem.) Selecting 10.10.10.0 as tun-subnetwork I can reach all my subnets in one "push route"

In short: the logs from OpenVPN Connect was correct and my copy from the OpenWrt was wrong:
This is a copy-paste from my OpenWrt as it is running now:

config openvpn 'bv_tun'
option dev 'tun'
option port '1195'
option proto 'udp'
option server '10.10.10.0 255.255.255.0'
option ca '/etc/openvpn/ca.crt'
option cert '/etc/openvpn/fw.crt'
option key '/etc/openvpn/fw.key'
option dh '/etc/openvpn/dh2048.pem'
option comp_lzo 'yes'
option mssfix '1420'
option keepalive '10 60'
option verb '3'
option enabled '1'
option log '/tmp/openvpntun.log'
option push 'route 10.99.0.0 255.255.0.0'

Have updated my initial post also.

Best regards,
Arild

Hello,

The server config states:
option server '10.10.10.0 255.255.255.0'
option push 'route 10.100.0.0 255.255.0.0'

On the client side log I see:
0 [route] [10.99.0.0] [255.255.0.0]
1 [route] [10.10.10.1]

Why are the subnets 10.100.0.0/16 and 10.99.0.0/16 different? Maybe this is your problem?

Have you done ping tests with packet capturing on the server to verify that pings from the client are arriving at the server?

Kind regards,
Johan

[openvpn_inc]

Hello,

> I choose 10.10.10.0 on my tun adapter to be on another subnet completely different. (originally I choose 10.99.10.0 for my tun adapter, but that way I had to use three push route subnets, while I was suspecting that was my problem.) Selecting 10.10.10.0 as tun-subnetwork I can reach all my subnets in one "push route"

You should definitely avoid having the VPN subnet being in the subnet that you're trying to reach. Using 10.10.10.0/24 for the VPN network while trying to give access to 10.99.0.0/16 should be fine.

On server side there is:
> option comp_lzo 'yes'

And client side is:
> compress lzo

Any way you can get rid of this? You should not be using compression anymore. See voracle vulnerability information online to learn why.

From your logs I see that the server subnet is configured to be 10.10.10.0/24. In topology 'subnet' the server will take 10.10.10.1 and the clients will get the other IP addresses. In your client logs I see that instead 10.10.10.5 and 10.10.10.6 are being used for server and client respectively. Seems to me that this is not a subnet topology. Are there other hidden directives on the server side that I'm not seeing here?

Try adding;
topology subnet
On the server side configuration

Kind regards,
Johan

[MostlyHarmless]

Hi and thanks for your comments!

I removed compression-lzo from both server and client-config.....
.... And that made it work!

I have reinserted and removed the compression settings - and every time the results are consistent. With the compression settings I can not reach my private subnets - when removed and not changing any other settings I get contact with my private network!

Thanks!

Now regardning your comments on the 10.10.10.5 server-address..... I also noticed this - but it is nothing I have control over.... but after removing compression - it seems not to make any problems...

I can see if I can set a static address on the tun-interface - and maybe I should, but I did not see this to be done in any tutorials I followed.
I thought this was setup by the openvpn-server on connection, but I will experiment with a static ip address on the tun-interface. It is easier now when I have a functional fallback that works.

Thanks!
Best regards,
Arild

On server side there is:
> option comp_lzo 'yes'
And client side is:
> compress lzo

In your client logs I see that instead 10.10.10.5 and 10.10.10.6 are being used for server and client respectively. Seems to me that this is not a subnet topology. Are there other hidden directives on the server side that I'm not seeing here?

Try adding;
topology subnet
On the server side configuration

Kind regards,
Johan

[Pippin]

Hi,

Compression is deprecated, it will be removed in a future version.
The same is true for --topology net30.

Judging by what you posted here

Code: Select all

option topology 'subnet'

should not give you a problem with regards to OpenVPN.

.
Also

Code: Select all

option mssfix '1420'

if it works without it you can remove it.

[MostlyHarmless]

Hi and thanks again!

Setting static ip on the tun-interface in openwrt did not do anything regaring the 10.10.10.5 address on the openvpn-server.

Adding your suggested "option topology 'subnet'" serverside fixed the issue.
I now have route-gateway 10.10.10.1 and client at 10.10.10.2

Thanks - Works perfect now!

Best regards,
Arild

my server config aftrer removing compression and adding topology subnet (openvpn on openwrt) (be aware that I am not using the default 1194 port)
config openvpn 'bv_tun'
option dev 'tun'
option port '1195'
option proto 'udp'
option server '10.10.10.0 255.255.255.0'
option ca '/etc/openvpn/ca.crt'
option cert '/etc/openvpn/fw.crt'
option key '/etc/openvpn/fw.key'
option dh '/etc/openvpn/dh2048.pem'
option keepalive '10 60'
option verb '3'
option enabled '1'
option log '/tmp/openvpntun.log'
option push 'route 10.99.0.0 255.255.0.0'
option topology 'subnet'

client config:
client
dev tun
proto udp
remote my.ddns.ip 1195
nobind
persist-key
persist-tun
ca bv_ca.crt
cert hp820.crt
key hp820.key
verb 3
remote-cert-tls server

gives this log in OpenVPN Connect:

20:47:41.348 -- ----- OpenVPN Start -----

20:47:41.348 -- EVENT: CORE_THREAD_ACTIVE

20:47:41.350 -- OpenVPN core 3.git::d3f8b18b:Release android arm64 64-bit PT_PROXY

20:47:41.353 -- Frame=512/2048/512 mssfix-ctrl=1250

20:47:41.353 -- UNUSED OPTIONS
4 [nobind]
5 [persist-key]
6 [persist-tun]
10 [verb] [3]

20:47:41.354 -- EVENT: RESOLVE

20:47:41.577 -- Contacting x.y.z.w:1195 via UDP

20:47:41.577 -- EVENT: WAIT

20:47:41.583 -- Connecting to [my.ddns.ip]:1195 (x.y.z.w) via UDPv4

20:47:41.609 -- EVENT: CONNECTING

20:47:41.610 -- Tunnel Options:V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client

20:47:41.611 -- Creds: UsernameEmpty/PasswordEmpty

20:47:41.611 -- Peer Info:
IV_VER=3.git::d3f8b18b:Release
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
IV_AUTO_SESS=1
IV_GUI_VER=net.openvpn.connect.android_3.3.0-8367
IV_SSO=webauth,openurl
IV_BS64DL=1


20:47:41.658 -- VERIFY OK: depth=1, /C=NO/ST=MyTown/L=MyTown/O=MyName/OU=BVOU/CN=MyEmail/name=MyDomain/emailAddress=MyEmail,signature: RSA-SHA256

20:47:41.659 -- VERIFY OK: depth=0, /C=NO/ST=MyTown/L=MyTown/O=MyName/OU=BVOU/CN=MyEmail/name=MyDomain/emailAddress=MyEmail,signature: RSA-SHA256

20:47:41.701 -- SSL Handshake: peer certificate: CN=my.ddns.ip, 2048 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD


20:47:41.701 -- Session is ACTIVE

20:47:41.702 -- EVENT: GET_CONFIG

20:47:41.704 -- Sending PUSH_REQUEST to server...

20:47:41.737 -- OPTIONS:
0 [route] [10.99.0.0] [255.255.0.0]
1 [route-gateway] [10.10.10.1]
2 [topology] [subnet]
3 [ping] [10]
4 [ping-restart] [60]
5 [ifconfig] [10.10.10.2] [255.255.255.0]
6 [peer-id] [0]
7 [cipher] [AES-256-GCM]


20:47:41.738 -- PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: NONE
key-derivation: OpenVPN PRF
compress: NONE
peer ID: 0

20:47:41.738 -- EVENT: ASSIGN_IP

20:47:41.763 -- Connected via tun

20:47:41.764 -- EVENT: CONNECTED info='my.ddns.ip:1195 (x.y.z.w) via /UDPv4 on tun/10.10.10.2/ gw=[10.10.10.1/]'

[openvpn_inc]

Hello MostlyHarmless,

Glad to hear the issue was resolved and all is working correctly now.

Kind regards,
Johan