WORKS as well!!!
Thanks… SOLVED!
Ciao
Vincenzo
1 Like
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.
OK will do.
thx
Well that was new to me. Always opportunities to keep learning your whole life. Thanks for the knowledge.
I think this would be good to have somewhere in the Open VPN wiki pages. 
agreed too…
Infact , I was looking at somewhere in wiki before… without success.
Anyway… SOLVED!
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.
1 Like
Below is a link to a small addition to what @cfuso wrote
Best regards
1 Like
Hi guys… VPN seems working… but:
- In the log I see the message “TLS Error: incoming packet authentication failed f rom [AF_INET]”
and “Authenticate/Decrypt packet error: bad packet ID ( may be a replay)” - maybe this is why I can’t enter in ipfire gui port 444, when I’m under VPN.
My Incoming Firewall access rule is set as:
Source - STD network: OpenVPN
Destination - Firewall: green
Protocol - TCP Port: 444
… and the same occur when I try to enter in NAS…
what can I do?
thanks
vincenzo
MTU problem, I think. You need to adjust it.
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?
thx
you do not have much choice, unless you decide to use the fritzbox as a glorified cable and set it up in bridge mode (avoiding a double nat would be the positive trade-off).
EDIT: I thought you were talking about the NAT rule in the fritzbox. For accessing the WUI I do not think you need to add a rule to the firewall.
the error is still there… i decrease again.
can you ping the NAS and IPFire machine? Maybe you need to add some push rule.
error still there even if i put MTU 1300 in both Global settings and .ovpn.
I’m proceeding going down with MTU
check if you can ping IPFire and NAS first, you might need to push your OpenVPN subnet and possibly other subnets if you use them, like the blue or the orange. Green should not need to be included in the push option. Do not forget to restart the server.
the strange thing is…
I can ping:
red (192.168.1.200)
green (192.168.2.1) but not the NAS (192.168.2.130). Same subnet…
In addition… VPN Connection is not stable… and after a ping from termius get disconnected for a while.
After openvpn connection, no additional rule is needed to open the WUI from the green side.
ok i delete the rule and try again
Try to push the openvpn subnet
Just to be sure, do a reboot.
Do you have additional firewall rules?
What is your OpenVPN subnet ?