OpenVPN Connection to iOS not working since update from 2.4.5p1 to 2.5.2
-
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.
-
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 :
-
@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.2Tell 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...?
-
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.
-
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 lo0Would you happen to know how to fix this?
pfSense+ 24.03 on Netgate SG-2100 (replaced SG-2440)
pfSense 2.6 on Super Micro 5018D-FN4T (retired) -
@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. -
@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.
-
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.
-
@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.
-
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 ?)
-
@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.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@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.0because my tunnel is 192.168.3.0/24
@highc has
server 10.0.10.0 255.255.255.0as 10.0.10.0 is is tunnel.
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
Ok, thanks. I've now configured the VPN to route all IPv4 traffic via the VPN. That works. Will leave it at that.
-
@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.
