OpenVPN bad encapsulated packet length question
-
@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!
-
I think I may be dealing with the issue @netblues mentioned that on one particular network, it is blocking VPN.
I am not sure what that would look like in the logs but I can create a new post on the topic if that would be more appropriate. What would a Firewall block on VPN look like in the logs? Would it hang the connection? Would it look like this?
It can find the VPN server but cannot connect.
It then hangs on attempting to establish a TCP connection.
My VPN is functional over other networks, this is the only network that is giving me issues.
-
Yes you would likely just see no replies at all because the server never sees the incoming connection.
-
Ok, I will do some research on VPN port share tonight and do some testing.
-
I would not expect that to help in this situation, just FYI.
-
Good to know. Is there a way around DPI?
-
It depends. Probably not if it's any good. Not easily at least.
-
yep, looks like I am done. I checked 443 and 1194 from another network and both are connecting. The network I need openVPN to work appears to be blocking both ports. Port 443 wasn't working before so I gave 1194 a shot just to check if default was allowed, however, the firewall appears to also block 1194.
Bummer
-
You can try something like UDP port 53 or 123 which are commonly passed. But you would need to do some shuffling for that since pfSense is already listening on those ports for DNS and NTP. You could forward traffic incoming on those to port 1194 on localhost for example.
