HELP! Something's trying to connect to my openvpn server >.<
-
Hello, idk what's happening but I went on my computer today and saw an undef connection with an IP under my openvpn tab on the dashboard. I looked in the log entry and saw this
Jun 20 15:42:29 openvpn 33503 118.193.31.222:42428 WARNING: Bad encapsulated packet length from peer (19026), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:29 openvpn 33503 118.193.31.222:42428 Connection reset, restarting [0]
Jun 20 15:42:29 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:39778
Jun 20 15:42:29 openvpn 33503 118.193.31.222:39778 WARNING: Bad encapsulated packet length from peer (26628), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:29 openvpn 33503 118.193.31.222:39778 Connection reset, restarting [0]
Jun 20 15:42:29 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:38711
Jun 20 15:42:29 openvpn 33503 118.193.31.222:38711 WARNING: Bad encapsulated packet length from peer (17517), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:29 openvpn 33503 118.193.31.222:38711 Connection reset, restarting [0]
Jun 20 15:42:30 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:40117
Jun 20 15:42:30 openvpn 33503 118.193.31.222:40117 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:30 openvpn 33503 118.193.31.222:40117 Connection reset, restarting [0]
Jun 20 15:42:30 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:42154
Jun 20 15:42:30 openvpn 33503 118.193.31.222:42154 WARNING: Bad encapsulated packet length from peer (17993), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:30 openvpn 33503 118.193.31.222:42154 Connection reset, restarting [0]
Jun 20 15:42:30 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:35515
Jun 20 15:42:30 openvpn 33503 118.193.31.222:35515 WARNING: Bad encapsulated packet length from peer (17152), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:30 openvpn 33503 118.193.31.222:35515 Connection reset, restarting [0]
Jun 20 15:42:31 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:60536
Jun 20 15:42:31 openvpn 33503 118.193.31.222:60536 WARNING: Bad encapsulated packet length from peer (12300), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:31 openvpn 33503 118.193.31.222:60536 Connection reset, restarting [0]
Jun 20 15:42:31 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:41871
Jun 20 15:42:31 openvpn 33503 118.193.31.222:41871 WARNING: Bad encapsulated packet length from peer (15423), which must be > 0 and <= 1607 – 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…]
Jun 20 15:42:31 openvpn 33503 118.193.31.222:41871 Connection reset, restarting [0]
Jun 20 15:42:31 openvpn 33503 TCP connection established with [AF_INET]118.193.31.222:32875
Jun 20 15:42:34 openvpn 33503 118.193.31.222:32875 Connection reset, restarting [-1]
Jun 20 15:44:48 openvpn 33503 /usr/local/sbin/ovpn-linkdown ovpns2 1500 1604 10.0.8.1 255.255.255.0 init
Jun 20 15:44:48 openvpn 33503 SIGTERM[hard,] received, process exitingAnd the IP's are from hong kong apparently, am I safe or is my pfsense box compromised and what should I do? I've turned off the server for now.
-
Change your OpenVPN server port so it's not on the default 1194 port.
Use strong authentication and passwords of 56 characters (56 characters is the max I've been able to make work with OpenVPN Clients).
Generate your passwords with KeePass or LastPass or equivalent in the "password generator" section of these programs. Use digits, lowercase letters, uppercase letters, special chars, and brackets.
That's just a start!
-
Changing the port is security through obscurity. A waste of time.
Yes, use strong passwords but in conjunction with digital certificates.
Most importantly, make sure your pfSense and OpenVPN are up to date.
-
Changing the default port a waste?
Let me tell you something -
If I'm looking to steal my neighbor's mail then I'm going to look in his mailbox first.
If the mail isn't there then I'm going leave his place and head down the street to look in my other neighbor's mailbox….
What I'm probably not going to do, and the majority of every other mail thief isn't going to do, is to take the extra effort and look through all 65,535 bushes in my neighbor's yard to see if the postal carrier threw the mail in the bushes.
Ya catch my drift bro?
-
If it was just a matter of guessing/brute forcing (with the knowledge that the password is going to be a weak one) one password to break in then sure, changing the default listening port would do some although very minor good. Your listening port could be still found after some trivial probing. However, OpenVPN is not like that unless you deliberately dump it down to that level. There are multiple very hard challenges the attacker has to beat to break OpenVPN's security and it's a reasonable assumption that almost nobody has the resources to do that on demand unless we start looking at government level players. Even then I would be sceptical because there's no undeniable proof yet presented that the ciphers and other cryptographic methods could be broken with government level resources. Changing the OpenVPN listening port will just cut down on log noise from failed hacking attempts by script kiddies at best, no additional security gained.
-
That error doesn't necessarily mean you are under attack. It means something is sending a request to that port that OpenVPN doesn't understand. It could be something other than an OpenVPN client (like a web browser or other scanner/probe), or it could even be a misconfigured OpenVPN client that thinks it's talking to something else like a proxy instead of direct. If it's still repeating like that, run a packet capture for that source address and TCP and see what the request looks like.
If you have a TLS Key enabled, then you have even less to worry about. Even more so if you're on 2.4 and use TLS Crypt instead of just auth.
Ideally you'll have every possible factor of authentication enabled with sensible settings for other options, such as:
1. TLS Key enabled for authentication (Or TLS Crypt on 2.4+)
2. Per-user certificates (SSL/TLS)
3. Username and password authentication (Even better if it ties back into RADIUS that has some 2FA system in place) with strong passwords.While not primarily a security concern, using UDP is better than TCP. Aside from being faster in general for VPN usage, a UDP service would not offer any information to an attacker that a service is even present on the port. TCP will let the client complete a TCP handshake and/or send a reset, letting them know there is a service on the port.
Moving the port on its own is security by obscurity but as a part of a multi-layered approach involving other security measures, it's still worth doing in most cases. So don't just change the port, but also enact other changes as mentioned above. I generally don't bother moving it though.
-
The only point of changing the port would be to reduce log spam.. It is sure not security.. And you also can tend to have odd shit happen when you do that. Firewall is setup to allow openvpn traffic outbound. So 1194 outbound is open..
You come along and say hey my openvpn client doesn't work - could you open up port 41194 since that is the port my vpn server is listening on.. Billy comes along, hey mine isn't working either could you open up port 59411 that is the port mine is listening on..
Might as well just open up all the freaking ports now! ;)
The mailbox analogy is flawed.. Since in this case the mailbox is LOCKED and SECURE.. Doesn't matter if they know there is mail in or not.. They don't have the KEY - they don't get the mail.. If they have a big enough sledge hammer and want the mail - doesn't matter if you try and hide the mail under a rock or not.. Also if you hide the mailbox - how and the F does the mailman find it to put your mail in?
So now the mailman has to know where everyone hid their mailbox..
Applications have specific ports assigned to them for a reason… Changing them is not a valid security stance, nor does it add any valid level security in a layered approach. The security is only going to be good as it is. Hiding it might keep the log spam down from people that couldn't get in anyway, but sure not going to stop someone that actually could get through your security.
-
Changing the default port a waste?
Let me tell you something -
If I'm looking to steal my neighbor's mail then I'm going to look in his mailbox first.
If the mail isn't there then I'm going leave his place and head down the street to look in my other neighbor's mailbox….
What I'm probably not going to do, and the majority of every other mail thief isn't going to do, is to take the extra effort and look through all 65,535 bushes in my neighbor's yard to see if the postal carrier threw the mail in the bushes.
Ya catch my drift bro?
Well you would if you had a few mail stealing robot minions that would just do it for you in a few seconds. Catch my drift, bro?
-
Oh alright thanks, thought I was under attack or something. On my dashboard where I can see if someone's connected to openvpn, it was spamming it connecting and disconnecting, is that normal? Also I only have 1 user and the password is 30+ characters long and has capitals, numbers, and special characters.
-
If you open listening ports to the internet you can always expect to catch some "noise" from random probes that people keep trying, some of them more determined than others. If it becomes a problem you can add rate limit options to the firewall rule that allows the traffic in to limit the number of connections that can be attempted over a period of time or the number of simultanious connection attempts.
-
If you use password and a solid key I wouldn't worry about it. No spot kiddies are going to bypass both.
-
@kpa:
If you open listening ports to the internet you can always expect to catch some "noise" from random probes that people keep trying, some of them more determined than others. If it becomes a problem you can add rate limit options to the firewall rule that allows the traffic in to limit the number of connections that can be attempted over a period of time or the number of simultanious connection attempts.
Alright, how do I do this? Also thanks all for the help! :D
-
In the advanced settings of your firewall rules. Max source connection rate & rates.
-
In the advanced settings of your firewall rules. Max source connection rate & rates.
pfBasic, does that work for you? I tried that to stop/slow brute force hits to a web server. No luck at all.
-
I've never used that feature, I was just pointing him in the direction of the settings for it.
I use a strong password in addition to strong keys for all of my VPN connections, so I've never paid any attention to unauthorized authentication attempts.
My assumption is that the setting works (in most scenarios).
-
Is a Key length of 2048 and Digest Algorithm SHA256 enough? I want to stream video over the VPN?
-
yes, I use RSA-4096 keys because that authentication only takes place once and the whole process only takes a couple seconds anyways.
I use SHA-224 as that has an ongoing performance impact and AFAIK SHA-2xx has no known vulnerabilities so I just go with the smallest thing that gets me into SHA-2. That being said I think that the difference between 224 & 256 are totally negligible.
Finally I use AES-128 for my server because again, AFAIK it has no known vulnerabilities so anything above that is a waste and some of my clients (smartphones) are noticeably impacted by the AES-256 performance tax.
That being said I do use AES-256 for my client on pfSense just because it's an old i5 and doesn't break a sweat even when maxing my 150/15 line so why not.In reality, if all you want to do is stream video (assume you are talking about pirated stuff?) then you can pick all of the lowest settings and disregard whatever vulnerabilities they may have. Your ISP is not going to attempt to decipher your encrypted traffic. Neither will any studio whose content you are pirating.
This really applies to most home users. If your VPN isn't used to transfer sensitive data for your job, or some sort of illicit activity that could get the attention of a government entity (read: not pirated media), then any level of encryption is almost certain to be more than enough. As long as all of your data is in CT, and you aren't on some government agencies list then it is extremely unlikely that anyone will ever attempt to decrypt your data even if it would be a trivial task due to using outdated and vulnerable ciphers.
Image the headlines if it was found out that Studio X or ISP Y was discovered deciphering someones internet traffic for any reason?
In reality though, most people who take the time to implement pfSense and/or VPN's for their network aren't going to use a cipher with known vulnerabilities after going to all that effort even if they know it probably doesn't matter for their use case. So we all end up use significant overkill in our encryption levels even if it means a performance impact.
AFAIK, IPSEC would be much faster/less resource intensive than OpenVPN in many cases. But IDK for sure since I've never used it because I don't have a performance limitation with my existing connection & hardware combo. But if I ever went to gigabit internet, I'd very likely switch to IPSEC.
-
Just to toss in my two cents about changing the port,.. I would for sure. Understandable it's security through obscurity but if someone is just scanning a block of addresses they are going to check for the most common ports people will leave default/open. If someone is scanning a block or poking for weakness for an application or protocol default ports can get caught up in that. It brings unwanted attention to your systems. So if someone wasn't targeting you specifically they would now know you're running a vpn server on the default configuration, so you start with weak passwords, sending packets to identify tcp or udp flags and go to work.
There is nothing wrong with changing the default port, it's a TCP/UDP connection that any port can handle. You either do it or don't do it, but do it because you're just trying to keep your privacy not because you think you're doing something other then changing the path you drive to work everyday. Also, if you have snort or bro or suracata running you should be using the known_compromised_host list.
-
Yeah often when someone suggest changing from default port someone else usually retorts with a speech about security through obscurity being worthless…
Security through obscurity vs "true" security is an imperfect analogy to cover vs concealment. Concealment can't physically protect you but it serves a purpose. The most commonly cited purpose is to clean up your log files, and that is certainly a valid purpose.