OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2

Gertjan

OpenVPN Connection to iOS

pfSense the client, and it connects to an iOS device ?

For me, it's the other way arround :
pfSense server Open log :

OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 24 2021
library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
WARNING: experimental option --capath /var/etc/openvpn/server1/ca
TUN/TAP device ovpns1 exists previously, keep at program end
TUN/TAP device /dev/tun1 opened
/sbin/ifconfig ovpns1 192.168.3.1 192.168.3.2 mtu 1500 netmask 255.255.255.0 up
/sbin/ifconfig ovpns1 inet6 2001:470:beaf:3::1/64 mtu 1500 up
/sbin/ifconfig ovpns1 inet6 -ifdisabled
/usr/local/sbin/ovpn-linkup ovpns1 1500 1621 192.168.3.1 255.255.255.0 init
UDPv4 link local (bound): [AF_INET]192.168.10.3:1194
UDPv4 link remote: [AF_UNSPEC]
NOTE: IPv4 pool size is 252, IPv6 pool size is 65536. IPv4 pool size limits the number of clients that can be served from the pool
Initialization Sequence Completed

When I use the OpenVPN client on my iPhone, I see (pfSense openvpn server log) :

92.184.108.228:60084 peer info: IV_VER=3.git::58b92569
92.184.108.228:60084 peer info: IV_PLAT=ios
92.184.108.228:60084 peer info: IV_AUTO_SESS=1
92.184.108.228:60084 peer info: IV_GUI_VER=net.openvpn.connect.ios_3.2.3-3760
92.184.108.228:60084 peer info: IV_SSO=openurl
92.184.108.228:60084 [MyPhone-iPhone] Peer Connection Initiated with [AF_INET]92.184.108.228:60084
MyPhone-iPhone/92.184.108.228:60084 MULTI_sva: pool returned IPv4=192.168.3.2, IPv6=2001:470:beaf:3::1000

92.184.108.228 is the IPv4 of my iPhone.

Btw : I do not have thse :

sndbuf 524288
rcvbuf 524288
push "route 192.168.1.0 255.255.255.0"
 push "route 192.168.2.0 255.255.255.0"
 push "route 192.168.2.0 255.255.255.0"
 push "route 192.168.3.0 255.255.255.0"

"Compression" is set to disabled.

My "Custom options" is empty.

You have :
tls-auth /var/etc/openvpn/server1/tls-auth 0
I have (the newer ?)
tls-crypt /var/etc/openvpn/server1/tls-crypt

Probably because I use :

(I'm not bothering with a user name password and unique certs ... - just the certs is fine to me)

highc

Thanks, @gertjan.

Our setup is similar in the sense that we're trying to get iOS devices connected to the OpenVPN server running on pfSense. I need to the push route statements, as my VPN connects to a different subnet in which alone the connected iOS device cannot do anything. I.e. it needs to connect to my other subnets.

I have

as well. I guess the difference in tls-statements is probably rather related to these aspects:

As I'm only using IPv4, I didn't bother with IPv6, but am also moving all traffic through the VPN, if connected:

Compression is disabled here as well.

As you can see from the logs, the connection as such appears to work, at least from pfSense's point of view. But pings (even to the 10.0.10.1 of pfSense itself) are not possible, nor is any meaningful use, as I cannot ping anything outside of 10.0.10.0/24, either.

Gertjan

@highc

Hummmm.
Just to be sure : you have a pas-all rule on the "OpenVPN" interface ?
Or, You have no rules on that 'OpenVPN' interface, but you've created yourself a OPENVPN (or whatever name you chose) interface with these rrules :

highc

@gertjan Yes, I have all-pass-through rules on the OpenVPN tab, and I have an individual all-pass-through rule on the interface that I created for OpenVPN as well.

Trying to drill down on the IP routing, I tried to drill into that a bit more. Pings from the iPhone don't work, so I'm trying to ping the iPhone from the pfSense:

t: ping 10.0.10.2
PING 10.0.10.2 (10.0.10.2): 56 data bytes
36 bytes from 62.155.245.93: Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 85d7   0 0000  40  01 345c 91.23.81.93  10.0.10.2

Tell me, if my approach is too simplistic. But I would have expected traffic for 10.0.10.0/24 to be routed to the VPN, but the fact that pfSense shows a response from 62.155.245.93 (my provider's gateway - NOT my phone's public IP) suggests to me that VPN routing within pfSense is broken...?

Gertjan

@highc

When I connect my iPhone using the OpenVPN app, it obtains a 192.168.3.2 (192.168.3.1/24 being the OpenVPN IPv4 network) :

From a PC on my LAN (192.168.1.1/24 ) I can ping my iPhone on 192.168.3.2.

highc

@gertjan

Thx, so this confirms that routing is broken here since the update.

I just googled the command for showing the routing table, and it seems that there is something missing for the OpenVPN net 10.0.10.0/24:

 netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            p3e9bf55d.dip0.t-i UGS      pppoe0
10.0.11.0/24       link#16            U        ovpns2
10.0.11.1          link#16            UHS         lo0
10.8.0.0/24        gateway            UGS       lagg0
10.9.0.0/24        gateway            UGS       lagg0
p3e9bf55d.dip0.t-i link#14            UH       pppoe0
p5b17515d.dip0.t-i link#14            UHS         lo0
localhost          link#6             UH          lo0
192.168.1.0/24     link#9             U         lagg0
firewall           link#9             UHS         lo0
192.168.2.0/24     gateway            UGS       lagg0
192.168.3.0/24     link#10            U      lagg0.30
192.168.3.1        link#10            UHS         lo0
192.168.4.0/24     link#3             U          igb0
192.168.4.2        link#3             UHS         lo0
192.168.5.0/24     link#11            U      lagg0.50
192.168.5.1        link#11            UHS         lo0
192.168.6.0/24     link#12            U      lagg0.60
192.168.6.1        link#12            UHS         lo0
192.168.7.0/24     link#13            U      lagg0.70
192.168.7.1        link#13            UHS         lo0

Would you happen to know how to fix this?

Gertjan

@highc said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

Would you happen to know how to fix this?

Undo whatever you did, related to routing ?
( honstly, I don't know how to 'read' a routing table to see what needs to be done where ).

My IPv4 routing table is pretty straight forward :

As I'm using :
a upstream ISP router using 192.168.10.1 - pfSense WAN is 192.168.1.3
pfPblockerNG uses 10.10.10.1
I consider my routes 'simple'.

You can clearly see 192.168.3.0 being the "OpenVPN" interface.

What you could do :
Take a know, recent ( !! - as it needs to be OpenVPN 2.5.2, that is the openVPN version, not the pfSense version that happens to be the same right now ) Youtube Video (example : Lawrence ?) and use that to make a working connection.
When it works, add you own changes 'up until it fails'. Then you know what the issue is.

highc

@gertjan said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

Undo whatever you did, related to routing ?

Just to be clear: The only thing I did, was upgrade vom 2.4.5p1. It worked there. Since them, I'm trying to get back to the state I had with 2.4.5p1.

Gertjan

@highc

The (a) OpenVPN setup probably needs some changes as many Open-VPN parameters changed when shifted from 2.4.x to 2.5.y.

I advise you to read what you mentioned :

@highc said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

(as available from here.

There is a big :

section.

Don't forget to export a newer opvn file for the clients.

highc

@gertjan
Ok, I did not just point to that section, but I actually read it ("of course, I'm tempted to say"). It might be that ...

Linux-specific features

    - VRF support
    - Netlink integration (OpenVPN no longer needs to execute ifconfig/route or ip commands)

... the netlink part is related to my problem. But there is no config option on this in pfSense. Neither would I know how to debug that part in pfSense. I'm happy to execute commands, but it would be great, if someone with a bit of background knowledge of how this works in pfSense could help me.

And as I said above, I did recreate the client config, exported it, and imported it again into the client. Doesn't work. I could redo the whole thing now for the third again and hope for a different outcome this time. But that sounds like a very desperate approach.

There are, by the way, open bug reports for OpenVPN related to pushing routes (e.g., here and here). But whether or not that is related to my problem where I can't even ping the OpenVPN client itself from pfSense, I don't know.

Gertjan

@highc

You entered this :

push "route 192.168.1.0 255.255.255.0"
 push "route 192.168.2.0 255.255.255.0"
 push "route 192.168.2.0 255.255.255.0"
 push "route 192.168.3.0 255.255.255.0"

?

( and why a leading space the last 3 lines ?)

johnpoz

@highc said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

something missing for the OpenVPN net 10.0.10.0/24:

You would not push the tunnel network you setup.. These should be in the routing table of pfsense, if openvpn is running.

example I use 10.0.8/24 and 10.0.200.248/29 in my tunnel networks.

routing table on pfsense shows these..

There really is little reason to use push route, networks you want your clients to get to should be listed in the local networks of your vpn

When not using the force gateway parameter

Notice if I disable the vpn instance, that route is no longer listed in pfsense for that tunnel network.

Gertjan

@johnpoz said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

You would not push the tunnel network you setup.

Did I miss that ?
He isn't pushing "10.0.10.0 255.255.255.0" (right ?)

As I have a

server 192.168.3.0 255.255.255.0

because my tunnel is 192.168.3.0/24

@highc has

server 10.0.10.0 255.255.255.0

as 10.0.10.0 is is tunnel.

highc

Ok, thanks. I've now configured the VPN to route all IPv4 traffic via the VPN. That works. Will leave it at that.

johnpoz

@gertjan said in OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2:

He isn't pushing "10.0.10.0 255.255.255.0" (right ?)

No he isn't pushing it - but you wouldn't need too.. The problem I saw with his configuration was that pfsense showed no route for his tunnel.

So something glitched or his instance wasn't actually running as I showed. If the instance is running there should be routes on pfsense for that tunnel network. See where I tuned off my instance and the route went away.

My point about pushing as well - is there is really no reason to have to add those. As long as you list them as local networks they are auto pushed.. You don't need to add them to the options box, etc.