this is my current setup: internet - Fritx Box router - RPI3 with IPFire (red on 192.168.1.200)
I created the OpenVPN server, putting in Global Settings - “Local VPN Hostname/IP” field: 192.168.1.200
I created the new connection as Host-to-Net, and delivered the .P12 / key / ovpn file, into the mobile.
imported p12 and ovpn into “OpenVPN connect” app.
In the end:
VPN is working only when I’m at home using the mobile connected with WIFI of the router FritzBox.
When I’m outside home, OpenVPN Connect is not able to connect to the IPfire OVPN.
What is missing?
Router rule to forward all trafic from External to RED and Port 1194?
Dedicated firewall rule (and which rule)?
Anyone have experience on this topic,and can give me some hints on how to solve?
Thanks… appreciate your support
Your fritzbox is your border router with the wan. I imagine that you either have a fix IP or you have dynamic dns, therefore I assume that when you are outside and you open your client, those packets find their way to your fritzbox. With this assumption, the question becomes: now what? Does your fritzbox knows what to do with all those incoming packets asking to be delivered to a service on port 1194?
from local provider, I have got a public fixed IP Address… but in this case:
have i to put this public IP address in the global settings “Local VPN Hostname/IP” ?
I think not…
therefore I tried to include a port forwarding rule in Fritz, in order to route trafic to 192.168.1.200 port 1194… but it seems not working.
Question to me: how openVPN connect app, knows that has to use the public IP address?
If you open the .ovpn file with a text editor you will find the remote directive, for example:
remote public_ip 1194
;remote local_ip 1194
This is where the clients gets the info to where to send the traffic.
Here the local IP is commented out, therefore if you try to connect your phone to your OpenVPN server outside your lan, it will work, but when you are inside, it won’t. Vice versa, if you comment out only the directive with your public IP the opposite will happen. If you do not comment any of them, then the client will try first one, then the other (this is called round robin). With this last setting it will work inside and outside your lan, if there are no other problems.
Just a suggestion for next time you need to troubleshoot. Look at the logs from both sides (server and client). You would have figured out immediately the problem if you had a look to the OpenVPN Connect logs.
I am procrastinating on updating those pages. I would like to put in my tutorial on roadwarrior connections using mobile devices, as the current tutorials are obsolete. I will do that and add this information as well.
Explanation: If you send a message that is bigger than a packet, it will be broken up in several packets, whose size is based on the Maximum Transmission Unit (variable depending on the network characteristics). Then the message is encrypted and sent to the other side of the tunnel. If even one hop in this trajectory has an MTU smaller than the initial one, the packet will be further broken up, but now this is an encrypted packet that is atomized. When al these fragments arrive finally to the tunnel end, they need to be reassembled and decrypted, which leads to all sorts of bugs and slow down.
The fragmentation has to happen before encryption or you will have a very slow, very buggy connection. Hence, you need to choose the MTU equal or smaller than the smallest hop between the two ends of the tunnel.
ok…in effect… following your documentation, ping with 1500 says too long!
I decreased the ping by 10 each step … and the first occurency with ping success is 1470… this means 1430 as MSS. I will adapt the global settings as 1470 and adding mssfix 1430 to the .ovpn .
and regarding the FW Rule… is it OK from your point of view?