OpenVPN bad encapsulated packet length question
-
@amrogers3 Now really, you are considering the ai driven forum spams?
Don't mess with mtu. its not the cause for dropouts.
-
Thank you.
@netblues said in OpenVPN bad encapsulated packet length question:
ai driven forum spams
I am not sure what you mean by ai driven forum spams
Also, is this messing with mtu? mssfix 1400 mtuSo this in server and client or just server?
fragment 1400 mssfix 1400 mtu max-mss headersI connected to my VPN through a different network and it has not had any issues. Connection has been stable. The dropout must be due to something happening connecting through the other network. I am glad it is not my VPN server that is the issue. I will have to run that down later.
As for the Bad encapsulated packet error, I am still getting that.
Aug 2 14:29:19 openvpn 16903 202.93.141.18:61001 WARNING: Bad encapsulated packet length from peer (5635), which must be > 0 and <= 1768 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]I did some research on 202.93.141.18. It appears to be a malicious IP address.
I also see same packet length error from 149.50.96.5:54758, 45.135.232.205.From what I gathered, I do not think I can mitigate this error. The Bad encapsulated packet length error appears to be scanning activity. I am using 443 so probably very common from what I am reading.
If these will help block the error, I can give these a try.
fragment 1400 mssfix 1400 mtu max-mss headers -
@amrogers3 said in OpenVPN bad encapsulated packet length question:
max-mss headers
This reply seems to be the first post you made clear you also control the server.
I dont recall saying to put 'max-mss headers' as a line in the config.
'mssfix 1400 mtu' does not change the mtu, the mtu part just affects how it calculates what size mss to use.
Since you have access to the server it is easy for you to verify the MTU configured on both ends of the tunnel. This is basic nix commands to check MTU size, ifconfig on BSD and ip on linux.
-
@amrogers3 said in OpenVPN bad encapsulated packet length question:
I am running VPN over TCP. I can try UDP.
You shouldn't use TCP, unless you need it to get through a firewall, etc.. With TCP you wind up with double flow control, which can hit performance.
-
@amrogers3 said in OpenVPN bad encapsulated packet length question:
I am not sure what you mean by ai driven forum spams
A user giving random advice, just signed up and then suggesting sex related sites, is an advanced form of spam.
Now.. tell me that you don't also have a tls key.
And never ever use tcp for a vpn, unless you don't have any option.
-
UDP using port 443 ok?
Had no idea there was ai driven spam now. Thought that was one weird post.Going to change it here to UDP over 443 and download a new client Viscosity bundle. Glad I posted about the TCP error. I learned a bit.
-
@amrogers3
Well, you can do that, technically all ports are the same , however quic will be using udp on 443.
And if it is a firewall that you need to bypass, udp won't cut it either.
Most todays firewals can do dpi and will detect openvpn on any port.Unless you have other reasons, consider using the default 1194 port, or maybe 1193 or 1195, just to avoid random scans.
Obscurity is not security, and sometimes creates more issues than it solves, e.g. in a penetration test audit. -
It should work using TCP on port 443. It's relatively common to use that combination to avoid restrictive networks.
But I too would advice starting out at something close to the default values setup by the wizard and make sure it works as expected there first.
-
@netblues
Thank you, I was using 443 because I sometimes log into my VPN through different networks and never know how restrictive firewalls will be and if they lockdown anything other than 80/443.I wasn't trying to do security through obscurity, it was what port would be the most unrestricted. I figured 443 is pretty universal and would be allowed everywhere. My other option I was thinking about was 80. I was unaware of the speed degradation issues with TCP but it makes sense because all of the handshakes and overhead with TCP. Also, if DPI is utilized I guess it really doesn't matter what port I use, they can block openvpn if they see it, although it seems openvpn over encrypted connection be be harder to inspect??? maybe it would be the handshake that alerts?
Have you had any issues using 1194 through various networks?
-
@amrogers3 Depends on the network and the admin
Fortigate firewalls detect openvpn and block it by default for one.Blocking outbound ports is found in medium to high security since it requires much more administrative effort.
And then, usually such shops opt for a proxy approach which gives much better control anyway.You can always run two instances on the same box, one on 1194 udp and another on 443 tcp
And see how it goes. -
@netblues said in OpenVPN bad encapsulated packet length question:
You can always run two instances on the same box, one on 1194 udp and another on 443 tcp
And see how it goes.That is a good idea. I will give that a try. Forum won't let me thumbs up your post so I will give you a thumbs up here.
Appreciate all the help!
-
You can even get extra sneaky: https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/port-share.html
-
That is interesting. So if I am not running a web server, I can just redirect to a IP to an internal IP that doesn't exist?
I have a 192.168.1.x network but not 192.168.2.x.
port-share 192.168.2.111 443; -
Yup you could though I'm not sure what advantage that might give.
But I certainly wouldn't try that until you have a basic UDP server setup and working as expected. Any custom server config is likely to make diagnosing issue more difficult. Start simple, add fun stuff later!
