OpenVPN compression
-
Probably from packet capture?
-
Looks more like ntopng restarting, taking all the interfaces out of promiscuous mode and then putting them back in.
Still unrelated to OpenVPN though.
Steve
-
I have still the same issue. I installed fresh pfsense and disabled compression. Windows machines and mobile phones connects and can access local network. Linux machines connects but can't access local network. I exported vpn files of Viscosity Bundle in Openvpn Client Export and imported files in Openvpn / Network Connection in Linux Mint, If I use compression in openvpn server and export new files and import them in Linux OS, then Linux machines can access local network.
But I export Archive in Openvpn server in pfSense and open terminal in Linux and run this command:
sudo openvpn --config user.ovpn and enter username and password then it connects and can access local network. -
You can edit the VPN connection in Linux Mint to change the compression settings.
Does it match what you set in pfSense? Can you change it to match? Does that then allow access?Steve
-
If I choose one of options in Compression, save and export new fles and import them in Linux Mint, then I connect and access local network.
Default was "Omit Preference (Use Openvpn Default). Because of Voracle attack, I choose "Disable Compression, retain compression packet framing (compress)".There is also option in Compression settings: "No LZO Compression (Legacy style, comp-lzo-no)".
To disable Compression, did I choose the right option? - "Disable Compression, retain compression packet framing (compress)".
-
"Disable Compression, retain compression packet framing (compress)" is selected in Compression. And I checked "Push Compression", after that, when I connect vpn, I can access local network. But I wonder why I have to check Push Compression?
But I ask again. To disable Compression, did I choose the right option? - "Disable Compression, retain compression packet framing (compress)".
Elvin
-
What does it show in the client in Mint when you do that?
I always choose omit preference there unless the other end has some specific setting that requires it.
Steve
-
@stephenw10 It shows nothing. I suggest you do it in your test environment to make sure why it happens, maybe there is a bug and it needs to be fixed. I read again that pfsense developers says don't use compression and disable it, because you may be a victim of Voracle attack.
-
I have such a tunnel configured right now. It works fine with the inline config imported to Mint, I can ping across it.
That's against an SG-1100 running 2.4.4p2
In Mint that looks like this:
Steve
-
Select Disable Compression in Compression settings and uncheck Push Compression in Openvpn server, then export bundle and import in Linux Mint. You will see what I mean.
-
Compression is disabled by default, why would I do that?
You still haven't said what Mint shows it's using for compression in the situation where there is seemingly a mismatch.
Steve
-
Just checking :
really ? tap !?
-
Ha, yeah I was testing everything on the 1100. That just happened to be the last thing I tested there.
Steve
-
in your screenshot Omit Preference has been chosen in Compression in Openvpn Server. In my side, I have chosen "Disable Compression, retain compression packet framing (compress)" in Compression in Openvpn Server. I want to disable compression on server side and when I export vpn files of client, it will be automatically disabled on client side as well. But if I don't check Push Compression, then Linux users can't access local network when they are connected. I want to know why it happens?
There is no need to check Push Compression when Omit Preference is checked in Compression?
My screenshot is as follows.
-
I would only expect to have to push the compression setting if you have changed it to something other than the default.
Steve
-
It doesn't matter which compression setting I choose and keep Push compression unchecked, it is working well both in Windows and Linux machines. But if I choose Disable compression in Openvpn server and keep Push compression unchecked, then it is not working in Linux machines. To make it working, I have to check Push compression.
I have this logs in Openvpn Logs when Disable Compression and Push compression is checked. If I uncheck Push Compression, everything is okay in logs.
Mar 26 16:06:31 openvpn 29296 XX.XX.XX.XXX:60636 peer info: IV_TCPNL=1
Mar 26 16:06:31 openvpn 29296 XX.XX.XX.XXX:60636 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1549'
Mar 26 16:06:31 openvpn 29296 XX.XX.XX.XXX:60636 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Mar 26 16:06:31 openvpn 29296 XX.XX.XX.XXX:60636 [elvin] Peer Connection Initiated with [AF_INET]XX.XX.XX.XXX:60636
Mar 26 16:06:31 openvpn user 'elvin' authenticated -
I've lost track of what the actual problem is here.
If you set a compression setting other than the default you have to either manually set that on the client to match or push the setting from the server. That seems like the expected behaviour.
Steve
-
I set Compression to Omit Preference in Openvpn Server in pfSense, everything is okay. When I connect from android device with the software Openvpn Connect, the above logs appear in Openvpn logs in pfSense, but when I connect with Openvpn for Android, everyhing is okay in logs. Beside this, Openvpn Connect doesn't require "Password Protect Certificate" while others do.
-
@emammadov said in OpenVPN compression:
I have this logs in Openvpn Logs when Disable Compression and Push compression is checked. If I uncheck Push Compression, everything is okay in logs.
So you only see that logged when you set a non-default compression setting and push the value? And it doesn't actually break anything?
The client side is free to refuse whatever the server pushes though they would not usually as that allows them to connect. It may simply not be setting it. However even if doesn't if it still passes traffic what issue are you trying to address here?
Steve
-
General remark : You checked openvpnn version on both sides ?
Recent versions changed behaviour, "compress" is a part of that (because of the possible flaw).
