Re: [Openvpn-users] what keys/certificates I as a openvpn client need to generate?
On 17.06.24 23:29, Mika Laitio wrote: But what information I will need from the server side to generate the keys. Unless there are restrictions in algorithm used or key length? (FWIW, the server admin asking for your "credentials" isn't quite enough to convince me that he is in fact thinking of X.509 certs based auth, rather than a shared secret (what OpenVPN calls "static key") or the --auth-user-pass option ...) Even though you can stuff most of the details a cert can carry into your CSR, a CA signing your CSR doesn't need to copy *anything* other than your public key into the cert it creates. (In particular, he SHOULD NOT let you choose the CN for the cert, as he is supposed to ascertain that it's unique.) Assume that if he were *not* planning to override *every* detail he can, he would have suggested which params and values you should ponder for longer than it takes you to reach for your random generator. On Mon, Jun 17, 2024 at 1:47 PM Antonio Quartulli mailto:a...@unstable.cc>> wrote: On 17/06/2024 22:33, Mika Laitio wrote: So I would need to be connected to an openvpn server not hosted by me and the owner of the server asked me to send my credentials for the server key. At the moment I do not know the name of the server, ca-files of it or anything. I believe that once I send my public key, he can then generate the configuration file for me that I can use to connect to the server. (.opni) There are two ways to achieve this: 1) the admin generates the certificate/private key pair for you and send it over along with the config 2) you generate the public/private key pair and then you create a CSR (Certificate Signature Request) which you send over to the admin. IMHO your admin is asking to follow 2). Thus he wants you to create your key pair and a CSR, so that he can then create the certificate for you. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
On 17.05.24 15:49, shadowbladeee via Openvpn-users wrote: Time is correct on the machines, certs expire in 2049. Any *CRLs* that might have expired? I note that the tcpdump shows only quite *small* packets. MTU issues that could lead to (persistent) loss of large ones from the other end? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] PC connects to the server but not Android
On 08.04.24 12:03, Peter Davis via Openvpn-users wrote: Hello, I can connect to OpenVPN server through PC, but it is not possible from Android. 2024-04-08 13:25:58 read UDPv4 [EMSGSIZE Path-MTU=1476]: Message too long (fd=6,code=90) Well, *if* we can take that log line at face value, you might want to try reducing the MTU configured in your client. Other than that, do you see any packets of a connection *attempt* arrive on the server, or corresponding log entries? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] [ext] Re: DNS Round-robin-records vs. "Preserving recently used remote address"
On 03.04.24 13:30, Ralf Hildebrandt via Openvpn-users wrote: I don't see such an option in the docs (for 2.6, to be precise), but let me ask a question for clarification: Does your setup answer requests to a now-disabled IP with some explicit denial (ICMP UNREACHABLE, RST, whatever), No, since the machine might still be active and serving existing openvpn sessions (basically we'd like to keep serving existing clients and disallow new clients) ... well, that wouldn't keep me from trying something along the lines of iptables -I INPUT -p tcp --dport $MYPORT -m state --state NEW -j REJECT iptables -I INPUT -p udp --dport $MYPORT -m state --state NEW -j REJECT but YMDOPMV¹ ... Note, however, that this interprets your term "new client" so as to include clients that *were* connected seconds ago, but choose to *re*connect for whatever reason. ¹ "Your Mileage, Distro, and Other Parameters May Vary" Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] DNS Round-robin-records vs. "Preserving recently used remote address"
On 03.04.24 11:31, Ralf Hildebrandt via Openvpn-users wrote: We're using DNS Round-robin-records with a TTL of 300s for our openvpn endpoint servers. Yet, clients seem to reconnect to the same IP, although the DNS entry has expired; the log usually shows something like: 2024-02-21 11:37:04 TCP/UDP: Preserving recently used remote address: [AF_INET]193.175.73.xxx:1194 Yes, it makes perfect sense to re-use a known IP, especially in the VPN context (DNS settings might just be off while dropping out of the VPN etc.), but this does really clash with our intentionally low TTL - at least when we're removeing one endpoint from the DNS for maintenance. I shall assume that your question is "how do I tell the client *not* to try sticking to the last IP used?". ;-) I don't see such an option in the docs (for 2.6, to be precise), but let me ask a question for clarification: Does your setup answer requests to a now-disabled IP with some explicit denial (ICMP UNREACHABLE, RST, whatever), in which case I'd be surprised if the client takes more than a second or two to give up on the old server, or are we talking about one or more minute-or-so timeout delays? If the latter, would it be possible to extend your going-down-for-maintenance routines so as to tell some firewall to generate such denial packets? On 03.04.24 12:40, Marek Zarychta via Openvpn-users wrote: in your case setting "explicit-exit-notify 2" on the servers should solve the problem. ... as long as the VPNs are running in UDP mode, and the server goes through an *orderly* shutdown ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client history
On 28.02.24 14:31, Bo Berglund wrote: I am running *all* openvpn scripts from within /etc/openvpn/scripts and I use the *full path* to the scripts in the conf files calls. I also keep all of the custom logs (as defined in the conf file) below /etc/openvpn/log, which is also perfectly accessile by tye openvpn service. I can for the life of me not understan why someone is hell bent on complicating the issues here by wandering around in circles in all kinds of strange locations Well, that falls under "gotta know *your* systems", I suppose. If the system in question were Red-Hat-ish with SELinux (it isn't, according to the OP), it would probably refuse your logfile placement: # egrep 'openvpn_(var_log|unc)' /etc/selinux/targeted/contexts/files/file_contexts /var/log/openvpn.* system_u:object_r:openvpn_var_log_t:s0 /etc/openvpn/scripts(/.*)? system_u:object_r:openvpn_unconfined_script_exec_t:s0 Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Increase data transmission
On 26.02.24 13:14, Peter Davis wrote: Is there really no way to hide? Let me put it like this: You're trying to evade nation-level censors. Those are *humans*, which has consequences: They might be (collectively) smarter than you, they're quite likely more experienced than you, they obviously see some incentive in hunting down people like you, and even if you manage to evade them today, it's entirely unclear whether the same methods will succeed tomorrow (and whether getting caught is something that you can afford happening every once in a while, or rather a "game over" scenario). That's fundamentally different from working around some technical snag, and if I were in that situation, I'd be wary of taking advice from *this* (technical) mailinglist at face value, as there seem to be rather few people on it who have actual experience with all-out *hiding* their VPNs. (Also, the capabilities of nation-level censors vary with the nation in question, and you have never mentioned - maybe for good reason - *which* nation we're talking about ...) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Increase data transmission
On 24.02.24 11:35, Peter Davis via Openvpn-users wrote: If you use OpenVPN to access the Internet of another country, then receiving data is usually more than sending it, and this traffic is considered suspicious and blocked. Is there a way to send fake data? Since the VPN layer supposedly hides all details of the traffic transported, *any* traffic you send out that doesn't cause much traffic back would do that. However, outgoing traffic that does not cause *any* traffic back (like when sending into a blackhole or against a DROP rule) would IMHO look just as suspicious, and very *small* reply packets (like RSTs, FINs or ICMP when you knock on a REJECT rule) would too. And when you get above *that*, whoever runs the receiving server is likely to consider your traffic abusive. "discard" servers (TCP+UDP port 9) have pretty much died out these days, some sort of file upload service would probably fit the bill best. You still shouldn't upload the same file over and over, or in regular intervals, though, if you want to fool the national censors. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Client history
On 21.02.24 18:53, Peter Davis via Openvpn-users wrote: LOG_FILE="/var/log/openvpn/Connections.log" I restarted the OpenVPN service and connected to the OpenVPN server with a client. I checked the file, but it was empty and nothing was registered. What is wrong? Are directory and file writable for the user OpenVPN runs as? Does your system use SELinux? If yes, does SELinux allow the OpenVPN server process to write into that directory/file? (Temporarily placing the file in /tmp instead should help you tell whether it is indeed a problem with OpenVPN accessing the file, or a problem in that OpenVPN doesn't try to write to the log in the first place.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and ChaCha20-Poly1305 encryption
On 08.02.24 20:07, Peter Davis wrote: Why OpenVPN articles uses AES-256-GCM? Is it better? It is very probably "better" in the sense of remaining compatible with various OpenVPN and OpenSSL versions; Ctrl-F the online OpenVPN reference manuals for more info. "Better" as in more resistant to cryptanalysis ... no idea. People around me tend to value the recommendations of the BSI more than my CYA-fu and cipherpunkness, anyway. Try https://www.schneier.com/ for a second opinion. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and ChaCha20-Poly1305 encryption
On 08.02.24 19:36, Peter Davis via Openvpn-users wrote: Why OpenVPN does not support ChaCha20-Poly1305 encryption? You sure? $ openvpn --show-ciphers | grep -i cha CHACHA20-POLY1305 (256 bit key, stream cipher, TLS client/server mode only) (FWIW, OpenVPN 2.6.8 and, *more* relevant to the point, OpenSSL 3.0.9.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to hide the number of connections to the server?
On 08.02.24 19:14, Peter Davis via Openvpn-users wrote: On Thursday, February 8th, 2024 at 9:36 PM, Gert Doering wrote: On Thu, Feb 08, 2024 at 05:58:42PM +, Peter Davis wrote: Can an intermediate server be an OpenVPN server for clients and an OpenVPN client for the final server at the same time? Sure. How to connect the traffic from the OpenVPN server on the intermediate server to the OpenVPN client on the intermediate server? Is it possible? Well-chosen IP pools for the OpenVPN instances, routes for those IPs (pointing to the tun interfaces of the respective instance, so give them *exact* names including the number in the OpenVPN configs) on the server, enable forwarding there as well, and finally, either MASQUERADE on the server or push a proper set of routes to the VPN clients. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to hide the number of connections to the server?
On 08.02.24 19:04, Peter Davis wrote: On Thursday, February 8th, 2024 at 3:45 PM, Jochen Bern wrote: On 08.02.24 11:36, Peter Davis via Openvpn-users wrote: Can an intermediate server do this? Instead of connecting directly to the final server, people connect to an intermediate server and this intermediate server sends requests to the final server! ... you mean, like what a VPN (to a central peer at the same site as the final server, and ideally many more servers) does ... ? Something like that. Suppose, in an environment, the number of connections to the OpenVPN server outside the country is limited, but the internal OpenVPN server does not have this limit. Many clients connect to the internal OpenVPN server, but this OpenVPN server only has one connection to the OpenVPN which is outside the country. Therefore, clients can easily connect to the external OpenVPN server. Well, if the domestic OpenVPN server is "internal" in the sense that your adversary can *not* detect and count the connections from the clients to it, even if someone clues him in on the setup, sure. Note that, while OpenVPN does indeed use "connections" in the sense of fixed IPs+ports quadruplets (in either UDP or TCP), the equivalent in IPsec VPNs would be the security associations (SAs). They're far from *impossible* to detect by external observation of the traffic, but depending on your definition of "connection" and the capabilities of the adversary, they might provide better obscuration. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to hide the number of connections to the server?
On 08.02.24 11:36, Peter Davis via Openvpn-users wrote: Is there a way to hide the number of connections to a server? From whom, having what resources at his disposal? What resources are at *your* disposal? You can encrypt and reroute *traffic*, but not make it vanish entirely. If your adversary can measure the bandwidth going to the server, and has a good idea of what the *average* traffic going through one connection is, he can trivially *estimate* the *number* of connections happening. If you need to avoid that, you need (lots of) *other* traffic going to you(?) to try and hide *amongst*. Can an intermediate server do this? Instead of connecting directly to the final server, people connect to an intermediate server and this intermediate server sends requests to the final server! ... you mean, like what a VPN (to a central peer at the same site as the final server, and ideally many more servers) does ... ? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] A few questions about revoking keys
On 04.02.24 16:32, Bo Berglund wrote: It took a week after revoking him until I could no longer access the site myself (I live about 6000 km away from the site and rely on OpenVPN for access). We once apparently had someone think that it'd be "neat and tidy" to have a root CA cert's validity end 01-Jan 00:00 ... 'nuff said. However: That's a central server that supposedly can be adminned only by your IT, and is being monitored in some way, likely allowing to keep tabs on whether the installed CRL is current/recent (or someone snuck in some pre-revocation version), too. What's the rationale to limit a CRL installed *there* to a lifetime of one week, if that's a burden to ops? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can a configuration item be cleared in the server.conf file
On 05.02.24 09:55, Bo Berglund wrote: I really wonder why it uses this terrible illogical display with the day name first? Because the need for global, *cross-OS* standards for a timestamp format first arose with BBSes, USENET, E-Mails and the like, and the developers of those wanted to have the "Date:" headers primarily *human*-readable (as long as the human can read English): $ date --rfc-email Mon, 05 Feb 2024 11:23:57 +0100 $ LANG=C date Mon Feb 5 11:24:03 CET 2024 $ LANG=C date +%c Mon Feb 5 11:24:06 2024 So the human-readable variants are *older* and more widely implemented than machine-readable or purpose-optimized ones. Be grateful that the code for *logging* is unlikely to support *localization* (to one of what, 400+?, regional human conventions) ... ;-3 $ echo $LANG de_DE.UTF-8 $ date Mo 5. Feb 11:24:22 CET 2024 $ date +%c Mo 05 Feb 2024 11:24:25 CET $ LANG=fr_FR.UTF-8 date lun. 05 févr. 2024 11:24:43 CET $ LANG=fr_FR.UTF-8 date +%c lun. 05 févr. 2024 11:24:50 $ LANG=en_US.UTF-8 date +%c --date="4 hours" Mon 05 Feb 2024 03:41:11 PM CET $ LANG=en_GB.UTF-8 date +%c --date="4 hours" Mon 05 Feb 2024 15:41:16 CET $ locale -a | wc -l 873 Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN on port 443
On 27.01.24 19:27, Peter Davis wrote: On Thursday, January 25th, 2024 at 1:25 AM, Jochen Bern wrote: Also, don't forget to configure the VPN server with --port-share, in case one of the nation-level censors you're trying to fool gets the idea of looking at your "interesting website" himself ... Can you tell me more about the --port-share? Not really much beyond what the OpenVPN Reference Manual says, sorry. https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/#server-options Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can a configuration item be cleared in the server.conf file
On 27.01.24 10:37, Bo Berglund wrote: It seems like there is a global conf file somewhere which is used by all instances of the openvpn service, but I am confused by the various statements on how to edit this file. Please: Exactly where is this file? ( /path/to/conffile ) If I may put words into the mouths of the systemd maintainers: "None of your business. If you need the unit file(s) changed, you've been given the 'systemctl edit ...' command. If you touch the files directly, you're trying to do *our* job, and will be held liable to have acquired, and keep updated to, the required level of know-how." (Note that, back when I had to try to get rid of the parameterless "--daemon" in the unit file, I found that the unit file would get overwritten with every update - unlike "normal" config files, where a new packaged version would be put into a *.rpmnew file when the update finds the current version manually changed.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Two questions about key generation for clients
On 25.01.24 11:11, Bo Berglund wrote: 1) The "sudo systemctl edit" command brings up a blank page for me, what is the editor commands in this window? I am used to how nano works but not how I can operate in this case. Tried Ctl-X and Ctl-C to get back from it... I would guess(!) that "systemctl edit ..." respects the $EDITOR env var, and the manpage seems to confirm that. Do I do it like so: sudo systemctl edit openvpn-server@server.service or like this: sudo systemctl edit openvpn-server@server (*These* two should actually do the same, but your "serverlocal" variant has me stumped ...) 4) And can I use sudo or must I switch to su first to get to the # prompt? My recommendation to get a root *shell* (prompt), if you do indeed need it, is "sudo -i". (I get the shivers whenever I see someone do "sudo su" instead.) I think I've *once* seen a case where it was necessary to use "sudo -s" instead. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN on port 443
On 24.01.24 13:31, Hans via Openvpn-users wrote: From: "Gert Doering" mailto:g...@greenie.muc.de>> Date: Wednesday, 24 January 2024 at 13:03:30 On Wed, Jan 24, 2024 at 11:49:43AM +, Peter Davis via Openvpn-users wrote: How can I make OpenVPN look like an HTTPS connection? You can't. OpenVPN is not https, so even if you use tcp/443, on a close enough look it will be clear "this is not HTTPS". How about using stunnel instead? stunnel may be able to wrap your (TCP) traffic into TLS, whose unencrypted parts may look more or less like the TLS interwoven into HTTPS, but it still won't make your hours-long single-server VPN connection with keepalives and key renegs in regular intervals and carrying an SSH login with its single-keystroke upstream packets look like you browsed a couple websites. Also, don't forget to configure the VPN server with --port-share, in case one of the nation-level censors you're trying to fool gets the idea of looking at your "interesting website" himself ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN on port 443
On 24.01.24 08:48, Marc SCHAEFER wrote: and obviously you won't be able to contact any of those Microsoft IPs anymore, Considering all the times Peter mentioned that "evade [nation-level] censors" is among his objectives, blackholing the clients' connections to Microsoft (auto)update servers while they're deep-diving might well be the *idea*. :-3 Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] iptables rules required for OpenVPN and Tor
On 22.01.24 12:01, Peter Davis wrote: On Monday, January 22nd, 2024 at 10:41 AM, Jochen Bern wrote: On 20.01.24 07:24, Peter Davis wrote: When someone connects to this server with OpenVPN and uses the Internet, then all his\her Internet connections are tunneled through Tor. I want to know which group of iptables rules are sufficient! Neither. If you want ALL his connections to the Internet to get redirected to Tor, then you'll need to either a) remember IP and port he's actually trying to connect to, or b) get the client to "talk proxy" (different protocol) if it didn't yet. Blindly applying "-j DNAT --to 10.8.0.1:..." everywhere erases that information from the actual connection attempt, and does nothing to inform the client of changed requirements. Hi, Thanks again. But it works, and when the user connects to the OpenVPN server, all his\her internet connections are tunneled through Tor. I just want to know which iptables rules are extra! What iptables rules do you use for such a scenario? Well, if it *works* right now, then the first thing you should do is to have a look at which rules do or don't get *triggered* by your tests. (I.e., use the "-v" option to iptables, but if you haven't done so since the last change of the setup, you might want to use "-Z" to reset the counters to zero and rerun the tests to get proper counts.) My *guess* would be that your # iptables -A FORWARD -s $YOUR_OPENVPN_SUBNET -o $IF_MAIN -j ACCEPT # iptables -t nat -A POSTROUTING -s $YOUR_OPENVPN_SUBNET -o $IF_MAIN -j MASQUERADE should be replaced by something like # iptables -A INPUT -s $YOUR_OVPN_SUBNET -p tcp --dport 9040 -j ACCEPT # iptables -A INPUT -s $YOUR_OVPN_SUBNET -p udp -m multiport --dports 9040,53530 -j ACCEPT and I'd probably add # iptables -I FORWARD -i $IF_TUNNEL -o $IF_MAIN -j REJECT to be sure to suppress non-UDP non-TCP traffic going out unTored, but it's sure that you need *parts* of *both* blocks (as the second fails to make the VPN itself accessible to clients). Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Can a configuration item be cleared in the server.conf file
On 21.01.24 21:08, Bo Berglund wrote: Inside the [systemd unit file for] openvpn server [...] this item is defined: --suppress-timestamps This means that *all* server instances will get this set even though it is not in the instance's own conf file! Now I wonder if there is anything at all one can do on a server instance level to disable that setting such that the timestamps are returned to the logfiles? My .02: .01) The problem isn't restricted to this particular config setting. A while back, when I set up a VPN server with about two handful of OpenVPN server instances running in parallel, I added "daemon MyInstanceName" to the config files so as to have the instances identify themselves in the log - only to find that the parameterless "--daemon" in the back-then unit file overruled that. .02) OpenVPN prioritizes command line parameters over statements in config files on the theory that someone probably typed them in for *this* particular execution of the openvpn binary - which obviously isn't the case when the command line's given in a systemd unit file. I wonder whether the situation would improve if OpenVPN were to give a *lower* priority config mechanism to the systemd folks. (Single global "template" config file, overridden by the usual per-instance config file?) Note, however, that this *alone* would *not* yet solve this particular problem, as you'd still need config syntax to "undo" the lower-prio setting. And this has worked just fine, except for the fact that there are no timestamps inside the logfiles created when it runs. Another cent on that matter: .03) You already did notice the *next* problem with forcing $APPLICATION to timestamp its log entries *itself*, instead of letting "the logging system" (journald, (r)syslog(-ng), ...) do that: Yet *another* place to try and get the configuration consistent with the rest of the logs. (Format, timezone, creation vs. arrival time, ...) Not to mention that having $APPLICATION write files directly tends to rather stand in the way of having the logs collected, across servers, in a central (tamper proof) location. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] iptables rules required for OpenVPN and Tor
On 20.01.24 07:24, Peter Davis wrote: On Friday, January 19th, 2024 at 5:04 PM, Jochen Bern wrote: On 19.01.24 13:59, Peter Davis via Openvpn-users wrote: I want to tunnel OpenVPN on Tor and I found the following iptables rules: # export OVPN=tun0 # IPTABLES -A INPUT -i $OVPN -s 10.8.0.0/24 -m state --state NEW -j ACCEPT # IPTABLES -t nat -A PREROUTING -i $OVPN -p udp --dport 53 -s 10.8.0.0/24 -j DNAT --to-destination 10.8.0.1:53530 # IPTABLES -t nat -A PREROUTING -i $OVPN -p tcp -s 10.8.0.0/24 -j DNAT --to-destination 10.8.0.1:9040 # IPTABLES -t nat -A PREROUTING -i $OVPN -p udp -s 10.8.0.0/24 -j DNAT --to-destination 10.8.0.1:9040 Please explain what your definition of "tunnel OpenVPN on Tor" is. These rules look rather like [...] hosing any traffic normal VPN clients try to send through the server. When someone connects to this server with OpenVPN and uses the Internet, then all his\her Internet connections are tunneled through Tor. I want to know which group of iptables rules are sufficient! Neither. If you want *ALL* his connections to the Internet to get redirected to Tor, then you'll need to either a) remember IP and port he's actually trying to connect to, or b) get the client to "talk proxy" (different protocol) if it didn't yet. Blindly applying "-j DNAT --to 10.8.0.1:..." everywhere erases that information from the actual connection attempt, and does nothing to inform the client of changed requirements. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] iptables rules required for OpenVPN and Tor
On 19.01.24 13:59, Peter Davis via Openvpn-users wrote:
I want to tunnel OpenVPN on Tor and I found the following iptables rules:
# export OVPN=tun0
# IPTABLES -A INPUT -i $OVPN -s 10.8.0.0/24 -m state --state NEW -j ACCEPT
# IPTABLES -t nat -A PREROUTING -i $OVPN -p udp --dport 53 -s 10.8.0.0/24 -j
DNAT --to-destination 10.8.0.1:53530
# IPTABLES -t nat -A PREROUTING -i $OVPN -p tcp -s 10.8.0.0/24 -j DNAT
--to-destination 10.8.0.1:9040
# IPTABLES -t nat -A PREROUTING -i $OVPN -p udp -s 10.8.0.0/24 -j DNAT
--to-destination 10.8.0.1:9040
Please explain what your definition of "tunnel OpenVPN on Tor" is. These
rules look rather like running the server's own Tor connection, the
incoming traffic in particular, through the VPN(s) ("inside" and
"outside" reversed WRT what your question implies when taken literally),
and royally hosing any traffic normal VPN clients try to send through
the server.
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Limit the number of users based on the key
On 11.01.24 20:35, Peter Davis via Openvpn-users wrote: On Wednesday, January 10th, 2024 at 11:25 AM, Gert Doering wrote: On Wed, Jan 10, 2024 at 07:53:35AM +, Peter Davis wrote: True, but I don't want to create a key for each employee in the department. Abandon that thought. We've been here before: you need unique keys per user, everything else will just make your life painful and miserable. If each user has their own key, then there should be a Client.conf file for each user, which itself contains a unique IP address, a unique port and a unique TUN. For example, for 100 users, there are 100 configuration files, 100 IP addresses, 100 open ports and 100 TUNs. Please specify whether you're talking about the server or the client side setup; you're mostly wrong either way, but for different reasons. Unless you're setting up the most unused VPN solution ever, though, you *do* need separate cert+privkey pairs for every *device* connecting to the VPN. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Limit the number of users based on the key
On 09.01.24 12:33, Peter Davis via Openvpn-users wrote: An employee in the supervision department shares a key with someone outside the company, and you want to block access to the server through that key. You must revoke the certificate of the supervision department. If each department has its own key, then [...] ... then a normal OpenVPN server will not ever allow more than one employee of each department to be connected to the VPN at the same time. If *that* matches your requirements, please feel free to continue disregarding the dozens of times this list has told you that You Do Not Want To Do That™. (Disclaimer: Talking about "key"s as in "client privkey+cert" here. Per-department *secrets* for HMAC auth are a different beast.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 08.01.24 15:09, Bo Berglund wrote: OK, in my case there are only a handful of clients so I could presuambly do the following by creating new server crypto files from scratch: If you'd like to get into enough detail to come up with a step-by-step recipe, you should IMHO specify *which* certs exactly are about to expire and need to be replaced in the process - just the CA, or the server's as well? (Or maybe it's *just* the server cert ... ?) Creating a new CA cert *without* changing the keypair and then rolling that out to the clients would be particularly useful if it allows you to keep the server cert unchanged, assuming that the server cert's nominal lifetime exceeds that of the CA; for as long as the old CA cert is still valid, *either* CA cert in whatever client's config would have the server cert accepted. Problem though, I don't know whether *EasyRSA* has a command/procedure to create a CA cert that way. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 08.01.24 13:02, Peter Davis wrote: 1- What tool do you use to generate server and client keys? Whichever happens to be in current use in the environment in question. None of what we've been talking about so far is an issue with EasyRSA in particular (beyond the Internet handing you how-tos that hurt my eyes with the "nopass"es sprinkled everywhere), it's about basic concepts of certs and PKIs and what objects are usually more long-lived than others. 2- Assume that the keys have expired. Do I have to generate a new key again or can I renew the previous keys that I have copied in the server and client directory? *Keys* don't expire (at least not with the cryptalgorithms in current use, and other than by slowly losing their edge in the race against codebreakers). Certs and CRLs do. You don't necessarily need a new *keypair* to create a new *cert* for it(s public key), but in the case of *decades old* keypairs, replacing those as well *might* be a good idea. Not all data can be recovered from whatever remains after you deleted/lost/... certain other; that's the *purpose* of crypto. If you start deleting stuff without an understanding of what circumstances might arise and require you to use it again, you *WILL* eventually see the entire project roll over and fall to pieces, usually well after its go-live. (Another pro tip: Don't set a CA cert's validity period to end on a "neat" date, *especially* not 01-Jan 00:00. Unless you're at work at that time, anyway, and fond of doing BIG surprise tasks on your lonesome.) I still don't quite understand why I shouldn't delete the Easy-RSA directory after generating the keys! Because you don't delete your government every time you have been issued a new ID, either. It's a TRUSTED institution, and "been around and fully operational for a *long* time" (compared to how long the information it certifies remains valid) is an expected aspect of being trustworthy. What you're trying to create is the equivalent of "I would like to have your passport confirmed by the issuer, but it seems that your national authorities ceased to exist". Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 08.01.24 07:19, Peter Davis wrote: On Sunday, January 7th, 2024 at 10:52 PM, Jochen Bern wrote: On 07.01.24 06:50, Peter Davis via Openvpn-users wrote: Now if I ignore the warning message above, what is the risk? Then you'll lose the content of those files that only the CA needs, and thus the ability to continue operating that (first) CA, in particular: -- You'll be unable to create a CRL, whether it is to actually revoke a cert or just to replace an expiring one. -- When the (first) server cert expires, you'll be unable to have a new one created by the same CA, thus requiring a config change on every client - wherever and in whosever hands it is - before it'll be able to connect to the VPN again. Hi, Thanks again. So: 1- What's the solution? ... is your work environment so diverse that every colleague has an ID card / a passport issued by a *different* nation? Trusted Third Parties - and that's *exactly* what a CA is - tend to be trusted to issue *several* proofs of identity. 2- What do I need to do to build new servers using Easy-RSA? You need to do some steps *LESS* than your "set up EVERYTHING from scratch" how-to lists. (And as far as I can tell without running a test myself, the command that gives you the warning is *not* the only one you need to omit.) 3- What files do I need to copy from Easy-RSA so that I can safely delete the Easy-RSA directory? Assuming that there is *some* obscure reason why you'd want to do that in the first place, may I suggest that you use subdirectories, rather than a "photocopy, then shred original" approach ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 07.01.24 21:20, Bo Berglund wrote:
If you have a couple of OpenVPN servers operating off of certs and keys
generated back in 2014 (like I have), then these are probably set to expire this
year 2024 because I think that the easyrsa I used back then sets a 10 year life
of these.
What is the proper procedure to refresh these so the servers will continue to
operate into the future?
I assume there are things that needs to be done on the server side, right?
But do you additionally have to create updated OVPN files for the clients as
well? Or is there some other procedure that can be used?
In a nutshell, if a specific CA certificate is used(!) in the config of
whatever OpenVPN peer and is about to expire, you'll need to have it
replaced, yes, *in every such config*.
There are various methods to do that, though, and which may be viable
for your case or not does depend on the details. Probably the very
*first* question you'll need to answer is whether your *remote* peers -
usually "the clients" - need to still have a working VPN connection to
you to get the updates rolled out, or have some out-of-band management
access for you, or need to be updated (or an update *scheduled* to
whatever downtime is convenient for them) by someone ("customer admin")
who is on site, or ... .
David already described the "issue new CA cert for the same keypair" and
"launch an entirely new CA (-> keypair -> cert)" approaches; I'd like to
add that when we're talking about a CA created *10+ years ago*, one
should think hard about whether the keypair (and algorithms) are still
up to today's definition of "good enough".
(Yes, we have a CA cert still in use that's signed with MD5, and the
only reason it hasn't ceased to work quite a while ago is that its cert
has been self-signed back then, rather than issued by an offline root
CA, like we do nowadays.)
Another possibility is to make CA cert rollover a normal part of a VPN
peer's ("product") lifecycle, just like replacing the peer's own cert
(hopefully) is. In one line of our products, peers usually have *two*
certs (and corresponding, even shorter-lived CRLs) for every CA they
need to know; one cert (age < lifetime/2) actually issuing child certs
(with their lifetime := CA cert's lifetime / 2), and one (age ≥
lifetime/2) only "maintaining" the child certs it issued "back in its
day" - by a) still existing and being valid, and b) continuing to issue
CRLs.
(Pro tip: Make your cert lifetimes a multiple of seven days (or else
your CA cert replacement tasks will "wander" through the weekdays and,
assuming you have the weekends off, eventually pile up on Fridays) and
allow every pair of n-th and (n+2)-nd cert to have a *bit* of overlap,
i.e., at least a week, giving you some leeway to fix unexpected problems.)
Yes, that makes your product more complex. (A bit - you likely need some
mechanism to roll out other kinds of updates, anyway. And if you do not
*today*, you might want to note the EU's upcoming Cyber Resilience
Act¹.) On the flip side, there IMHO is an advantage in that this
approach pretty much *forces* you to implement CA cert updates "early"
in the product's lifecycle, when there's still the required know-how and
a development budget around ... way *before* things like "whoops, now we
have leaf certs whose lifetime exceeds that of the CA's²" or "our CA
privkey got leaked, we need to create and distribute a new keypair+cert
TODAY, whaddya mean we have no process for that!?" happen.
¹ https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
² i.e., the leaf cert will turn inoperational when the *CA* cert
expires, *not* on the (later) day the leaf cert's notAfter states
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] I have a question about Easy-RSA
On 07.01.24 06:50, Peter Davis via Openvpn-users wrote: As you can see, I have moved the files to /etc/openvpn/server directory. Correction: You have copied SOME files to that directory, namely, those that the server needs. Now if I ignore the warning message above, what is the risk? Then you'll lose the content of those files that only the *CA* needs, and thus the ability to continue operating that (first) CA, in particular: -- You'll be unable to create a CRL, whether it is to actually revoke a cert or just to replace an expiring one. -- When the (first) server cert expires, you'll be unable to have a new one created by the same CA, thus requiring a config change on *every* client - wherever and in whosever hands it is - before it'll be able to connect to the VPN again. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and outside clients
On 02.01.24 15:31, Peter Davis via Openvpn-users wrote: My server has a NIC with a local IP address. Clients can connect to it on the internal network. I want clients from outside to be able to connect to it, but I can't set a public IP on the server's network card. On the firewall (Fortinet) that is directly connected to the Internet, a public IP address is forwarded to the IP address of the OpenVPN server. For example, on the firewall, IP address 1.2.3.4 is forwarded to IP address 192.168.1.1. I want to know, if I replace the IP address 1.2.3.4 instead of 192.168.1.1 in the client configuration file, then the clients should be able to connect to the server from outside the network? Assuming that a bunch of other setups¹ is OK as well, yes, that should work. At worst with a bit of fiddling re: server cert verification. ¹ Server's host firewall, firewall config on the Forti, both up to and including the (TCP or UDP?) port the OpenVPN server's using, server has a defaultroute back to the Forti and can in fact reach it, no DPI trying to mess with the connection/crypto, your Internet uplink allows proper pMTU detection and is well-reachable from wherever the clients will be located, ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Reference manual for OpenVPN 2.6 PDF
On 13.12.23 11:37, j.witvl...@mindef.nl wrote: Even if a printer is able to accept it, and does the printing, current ones are NOT READABLE. Due to surgical error, I’m left with only 20% sight, But even my colleagues with full 20/20 eyesight agreed, the printed pages are unreadable. Nice for online, but don’t try to print them. Then I'd guess that you're not looking at the two pages/URLs specifically mentioned in this thread. I *did* try saving those as PDFs, and saw nothing but max-contrast text (mostly black on white, in one of them also inset black boxes with white lettering) in them. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Reference manual for OpenVPN 2.6 PDF
On 13.12.23 07:44, Jason Long via Openvpn-users wrote: I believe the correct answer here is: OpenVPN does not provide a PDF form of the manual. Which is a practical decision. Hello, Practical decision? Well, the situation's not as bad as it *used* to be, but still: https://en.wikipedia.org/wiki/Paper_size#/media/File:A_size_illustration2_with_letter_and_legal.svg There are printers that outright *refuse* to print out a PDF stating a sheet size different from the paper actually sitting in the tray, etc.. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to solve the TLS key negotiation failed error?
On 23.10.23 14:10, Peter Davis via Openvpn-users wrote: Hello, I installed the OpenVPN on Debian 12 and configured it as below: [...] tls-auth /etc/openvpn/server/ta.key 0 [...] Client configuration is: [...] tls-crypt "C:\\Program Files\\OpenVPN\\config\\ta.key" 1 [...] How to solve it? So the client tries to encrypt the control channel packets, on top of the HMAC auth, but the server doesn't do any extra (en- or) decryption, I'd guess ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OPenVPN 2.5 - How to allow client access to the web but not to the local LAN?
On 20.10.23 05:31, Bo Berglund wrote:
Does this mean that when the client tries to access the server side gateway
device (router) he will not be blocked but all other addresses will?
The gateway is on the LAN and it gets traffic from the tunnel, but does it mean
that its address is also open
The traffic flows through that server-side default router because its
immediate neighbors know about it, usually including its *IP* (layer 3
address), and rewrite packets to be addressed to its *MAC* (layer 2
address) for the next hop. Remote endpoints do *not* need to be able to
know its IP or talk to it for that.
However, there's a legit need for the endpoints being able to *receive*
packets from the router IP (Path MTU Detection and other ICMPain), and
anyone trying to analyze a network problem might easily want to *send*
to it, too ("hey, that hop in the traceroute output looks weird, lemme
ping it quick-like!"). Hence, "Internet links" usually use (globally
routable) *public* IPs for transfer nets, and allow the routers to reply
to probes to *some* extent.
for direct access like for the config page of the router?
Yeah, well, you want to block access to the router's *admin interfaces*,
of course. Preferably with belt (client IP whitelist on the router),
suspenders (having iptables filter out attemps through the VPN), *and*
superglue (strong authentication mechanisms).
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Using easyrsa3 - how to set longer expiration than 10 years?
On 06.10.23 22:17, Bo Berglund wrote: In easyrsa2 one could enter a longer expiration [...] like 7300 (20 years). [...] will my suggested expirations above not work? Define "work". If you create a CA cert with a lifetime of 20 years and leaf certs with a lifetime of 100 days less today, and keep using the software of today, then your clients and servers will still be able to communicate in mid-2043. Note that a leaf cert you create with that CA in 2030 with a lifetime of 7200 days, however, SHOULD cease to be accepted when the CA cert expires in October 2043, *not* at the time of its *own* expiry (in 2049/2050). Last not least, for how long your setup will "work" in the sense of "be sufficiently safe against intrusion/cracking attempts" is an entirely different question. The BSI, for example, refuses to speculate about the suitability of entire *algorithms* further than seven years down the road https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf?__blob=publicationFile&v=5#%5B%7B%22num%22%3A31%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C99.2%2C302.739%2C0%5D and if even *if* RSA were still acceptable in 2043, chances are that the OpenSSL versions available then might outright reject your 3 or 4 kb CA keypair as being of insufficient length, or balk at hashes predating SHA-4. Add to that that there's always the possibility of a privkey being leaked (rogue employee?), thus requiring it being revoked and replaced - at the least preferable time of course, as usual. My conclusion is that the most important thing to do to make whatever system using a PKI survive a decade or more is not to pick some "good and immortal" crypto parameters from day one, but to make sure that you got keypair/cert/CRL rollovers implemented end-to-end and well-tested while you still have a nominal devel budget for the project. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Migrating to new CA
On 04.10.23 22:44, mike tancsa wrote: this fails with just the old-ca.crt % openssl verify -show_chain -CAfile old-ca.crt -untrusted int.crt sentex-remote-only.crt CN = sentex-remote-only error 20 at 0 depth lookup: unable to get local issuer certificate error sentex-remote-only.crt: verification failed But works with the new ca or ca bundle of old and new % openssl verify -show_chain -CAfile newca.crt -untrusted int.crt sentex-remote-only.crt sentex-remote-only.crt: OK Chain: depth=0: CN = sentex-remote-only (untrusted) depth=1: CN = Sentex-remote-only CA It should show the cross-signed certificate at depth 1 linking the new server certificate to the old CA at depth 2. Would the old-ca.crt happen to limit the verification depth it may be used for (i.e., forbid itself to sign intermediaries), like this CA cert (Let's Encrypt's R3) does? # openssl x509 -in chain.pem -noout -text | grep -B 1 CA: X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Migrating to new CA
On 02.10.23 22:21, mike tancsa wrote: If I have to go for option A (Stacked CAs on all clients, stacked CAs on the server then update the server), is there a downside with leaving an expired CA cert on all the clients ? Or can they just be left there until the devices get re-imaged over time ? I remember running tests in 2012 where OpenVPN would refuse to start if there was an expired *CRL* in the config - IIRC with a CA *file*, not a CApath -, even if the CA cert had already expired earlier and would, of course, remain unused. Current OpenVPN versions don't do that anymore. How up-to-date are your client installations? (I still take care to get expired CAs removed from configs before their final CRL expires as well, just in case.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] URL forwarding and blacklisting
On 21.09.23 21:50, Jason Long via Openvpn-users wrote: Hello,I have two questions:1- When someone connects to an OpenVPN server, is it possible to be redirected to duckduckgo.com when trying to go to google.com? 2- How can I block access to certain websites? Does OpenVPN offer such features? You can manipulate traffic that *does* go through the VPN and, thus, your server(s) in whatever way *other* soft- and hardware allows you to. OpenVPN itself does not have any such functionality. Relevant sidenotes: a) There are OpenVPN(-protocol) clients that allow the user to override the routes the OpenVPN(-software) server sends it, not to mention adding routes with more specific prefixes pointing to selected servers (e.g., Google's), and also any DNS manipulation can be countered by way of /etc/hosts, so users can trivially circumvent your blocks (as long as they're willing to have the traffic *not* go through your VPN). b) As of right now, Google.com's servers have IPv6 addresses, which will be preferred in a dual stack setup, so you'll have to add IPv6 to your VPN to even stand a chance of intercepting those users' connections to Google. c) As of right now, DuckDuckGo.com does *not* have IPv6 addresses, so be prepared to run a 6-to-4 gateway as well ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Using username/password authentication
On 30.08.23 07:45, Jason Long via Openvpn-users wrote: Hello, I configured OpenVPN to use the username and password for authentication, but I need to have the "ca.crt", "cert server.crt", "server.key" and "dh.pem" certificates. So, what's the advantage of using this authentication method when I still need to use these keys? Umh, not having to roll out certificates¹ to the *clients* (assuming that your list is indeed complete)? I would guess that you *could* do away with those files as well ... if you're willing to run the VPN *unencrypted* as well. User+pass does not provide for encryption keys. ¹ And I mean *certificates*, half of what you list aren't. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Revoke a certificate and reuse it
On 27.08.23 20:43, Jason Long wrote: On Sun, Aug 27, 2023 at 1:33 PM, Jochen Bern that seems correct, but as I said, I don't use EasyRSA myself. Hello,Thanks again.Can you show me the OpenSSL commands that you use to generate the server and client certificates? I'm not using bare OpenSSL for that purpose, either. As I said previously, for settings involving a lot of client certs, you want that automated and integrated into your client maintenance solution - so our company wrote its own PKI implementation, complete with API and WebUI. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Revoke a certificate and reuse it
On 27.08.23 07:49, Jason Long wrote: 1- When a key is generated, how many days is the default time for it to expire? Whatever your configuration files say. And frankly, just generating one and *looking* at it might tell you *even faster* than reading the configs. (IIRC EasyRSA comes with its own bunch of openssl.cnf to cover several major versions of OpenSSL the machine may have preinstalled, but a lot of the parameter are filled from env vars that the easyrsa "executable" or a "vars" file would preset.) 2- Are the following commands correct to expire the client key after 110 days?? # export EASYRSA_CERT_EXPIRE=110 # ./easyrsa gen-req My_Client nopass # ./easyrsa sign-req client My_Client According to the docs https://github.com/OpenVPN/easy-rsa/blob/master/doc/EasyRSA-Advanced.md#environmental-variables-reference and assuming that you're using a POSIX Bourne-style shell https://unix.stackexchange.com/questions/368944/what-is-the-difference-between-env-setenv-export-and-when-to-use that seems correct, but as I said, I don't use EasyRSA myself. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Revoke a certificate and reuse it
On 26.08.23 07:32, Jason Long wrote: 1- How do you give keys to a large number of clients? Suppose there are 1000 employees in a company, do all employees have to go to the IT department of that company to get the client keys? Certificates are technical proof that the CA trusts the holder to have a set of properties - whether that's an e-mail address, a full (legal) name, being an employee, of a specific department / with a specific job title / legal capacity within the company, a paying customer, a resident of the city, yadda yadda. (In your case, it would either *happen* to imply "yes, he may use that VPN, too", or *be* simply "permission to use that VPN", whatever purpose the VPN serves.) In order for the entity to receive a certificate, that entity has to do whatever it takes to make the CA have that trust in them. If you're handing out employee certificates in a large company where the only way to verify "yes, he's one of us" is to compare the photo on his badge with his face, then yes, he'll obviously have to show up in your office to do that. (And you should agree on a confidential transfer password so that the cert can later be sent by an insecure channel - unless you create it and *somehow* hand it to him on the spot.) Ideally, there should be a written policy what the CA considers satisfactory procedures. Yes, that likely means that it's *your* job to at least define, if not write, it. 2- Is it possible to send a new key to clients automatically when client key is revoked? Not with one OpenVPN connection alone (as revoking the key means that you do not trust that client anymore, and thus should hand over a new one to the (re-)verified holder by *different*, still-trusted means). Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Revoke a certificate and reuse it
On 25.08.23 21:41, Jason Long via Openvpn-users wrote: Hello,With the help of the following command, you can revoke a certificate: # ./revoke-full "Client_Name" Now if you change your mind, is it possible to use that certificate again? Is there a command to validate a revoked certificate? Semantically, no, there is no such thing as "unrevoking" a certificate. Technically, you can get a cert back out of a CRL or other listing, and hope that the world will forget it was ever listed there, or never noticed that in the first place, but it'd probably be less work to just have the CA issue a *new* cert instead. *Revoked* certs do *not* count against the guideline of "there shouldn't be two certs by the same CA for the same DN with overlapping validity periods". Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] ccd-exclusive does not work
On 23.08.23 13:20, Jason Long via Openvpn-users wrote: As I understand, if the file name is not equal to the CN name in the client.crt file, then the client can't connect to the OpenVPN server. You said that in your test, the file name *does* match, then you changed IPs stated *in* the file, then asked the list how it's possible that the client can *still* connect. Why, rather than explain why you would expect such an effect in the first place, do you *now* bring up the filename aspect again? Excuse me, is the ccd-exclusive statement best way to filter the clients? For example, I only want to allow clients to connect to the server whose CN name is Trusted. I.e., you want a default-deny behavior. "ccd-exclusive" is one way to achieve that, and one that works for clients that connect from "wherever on the Internet" and can *lose* your trust later on. Off the top of my head, the only available "drop-in replacement" would be to properly *revoke* client certs, and keep the servers informed of the revocations (by CRL, OCSP or whatever). Otherwise: *If* you can pinpoint clients' IPs, you can let iptables do the filtering. *If* you won't withdraw trust once it has been given, even if the device gets into someone else's hands, just run a tight ship on client cert generation/handout. *If* you have actual administrative control over clients whenever necessary, prepare to send them a delete-keypair-and-secret command when they lose your trust. Etcetera. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] ccd-exclusive does not work
On 22.08.23 10:20, Jason Long via Openvpn-users wrote: Why can the client connect to my OpenVPN server when the IP range is not correct? Two reasons: 1. Because the VPN connection is established *before* any additional routes will be set. 2. You're utterly confused about what is or isn't "correct" there. As Gert already told you, "(i)route" instructs the peers to route a given subnet *into* the VPN. If there is such a thing as a pronouncedly "not correct" subnet to do that with, addresses that you need to use to establish the VPN tunnel in the first place would be it - which is exactly what you're trying to do, without ever explaining *why* you would want to do that. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 19.08.23 15:04, Jason Long wrote:
I asked:
"If CN's name is Server, then I must change the ccd directory to
Server? Am I right?"
Answer:
"If that's what the Subject CN of the cert you want to use as a
client cert says, then yes, that's it. Of course, looking at a
file "ca.crt" and seeing a CN "Server" for what is supposed to be
the *client's* cert is botched twelve ways to Gehenna and back and
will perpetually confuse anyone trying to debug your final setup..."
(Note that in that reply, I failed to notice that you meant to change
the name of the *directory*, rather than the name of files within it.)
Please clarify this for me. To use the --ccd-exclusive statement, I
must create a directory under the /etc/openvpn directory:
1- Is the the name of that directory important or not?
The server config must explicitly point to it (and ownership/access
rights/SELinux/... must allow the server process access to it).
Its name must be "CCD" or the CN's name, or it could be anything?
Other than the above, name and location can be chosen freely.
2- After the directory, I must create a file under it. How about
the name of that file? Is the the name of that file important
or not?
For the server to apply the configs in that file to a connecting client,
the name of the file must match the (subject) CN of the cert the client
uses to identify itself to the server.
3- For "Common Name (eg: your user, host, or server name) [Easy-RSA
CA]:" question, I can enter my name or anything
I still suggest that a CA cert's CN should mention "CA", the authority
(company?) running it, the purposes this CA issues certs for, and some
identifier for the specific cert to better identify it across CA Cert
rotation, but yes, "Jason was here" will work, too.
and the name that I entered could be used for the following
commands, but not mandatory. Am I right?
It ***SHOULD NOT*** be reused in those. The above creates a CA cert. The
following commands create a server cert and a client cert, respectively.
Given how incomprehensible the concept of these three roles seems to be
to you, failing to give the certs proper, unique, mnemonic names
promises to lead to disaster.
4- The names that I must enter for the following commands, must be
same. Right?
Yes, the "gen-req" and "sign-req" EasyRSA commands used to create one
cert need to take the same, unique identifier for the cert-to-be.
("sign-req" actually locates the file containing the CSR generated by
"gen-req" by the filename corresponding to that identifier, so failure
to enter the correct ID into the latter will *usually* result in an
error message, *except* when the ID has been used before and the old CSR
is still around.)
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 19.08.23 10:02, Bo Berglund wrote: On Sat, 19 Aug 2023 07:03:01 + (UTC), Jason Long via Openvpn-users wrote: I have another questions: 1- I checked the "Subject" of the ca.crt file and my CN name is "Server". Now, I must change the "ccd" directory to "Server", but how about the file name under the "Server" directory? WHAT? The ccd directory is defined in the server.conf file and could be named whatever you like. It has NOTHING whatever to do with the CommonName in any certificate or such! To add to that, we're talking about the *CA* cert here (in spite of its CN reading "Server") and the CA isn't going to connect to the VPN server, so having a CCD¹ *whatever* to match its CN isn't going to do anything ever. ¹ That *does* still stand for "(Per-)*Client* Configurations Directory", right? :-3 2- Suppose you want to configure a server. Can you show me the names you enter for the commands below? # ./easyrsa build-ca nopass ... Common Name (eg: your user, host, or server name) [Easy-RSA CA]: "Your_Name" Binect Exasperation CA - A (When rotating CA certs, we "increment" the trailing letter.) # ./easyrsa gen-req "Your_Name" nopass # ./easyrsa sign-req server "Your_Name" exavpn.binect.de # ./easyrsa gen-req "Your_Name" nopass # ./easyrsa sign-req client "Your_Name" These create a *client* cert, which is unnecessary to "configure a *server*", strictly speaking. Since you seem to plan to have a boatload of CCD files, which need to be named after the client certs' CN, I would probably revise my previous suggestion of "Jason Long's private cell phone" and go with something like "JasonLong_privCell" instead. Not that it should be much news to you how *I* would name CA, server, and client certs, respectively, if you had read my previous posts ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 18.08.23 21:22, Jason Long wrote: 1- In the round-robin mechanism, we can use the same keys for our servers, but each client uses its own key. You *can* do that, yes. Since you apparently don't provide clients with a CRL or any other means to have server certs revoked, I guess it doesn't worsen your reaction time / options after a leaked server cert any *further*, anyway ... 2- So, the name that I entered in the "Common Name (eg: your user, host, or server name) [Easy-RSA CA]:" question, must be used in the "./easyrsa gen-req NAME nopass" and "./easyrsa sign-req server NAME" commands. Right? NO. Reread what I wrote about the (hint: different) roles the certs generated by these two sets of commands have. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 18.08.23 16:31, Jason Long wrote: 1- So, if we have multiple servers, then it is better that the servers have the same key, but each client has its own key. Am I right? No. I said that *if* you want your clients to be able to replace one server with another dynamically, it may be a valid reason to have the *CN* in their server certs have *similarities* to each other (for "verify-x509-name ... name-prefix"), or be outright the same (other types of "verify-x509-name" checks). (Identical DNs/CNs technically still do not imply that the servers use the same keypair. And using the same keypair technically still does not imply that the servers use the same cert. Though we're going into the area of somewhat questionable setups there.) 2- I can filter clients by MAC address No, you can't. If the VPN server can see the clients' MACs (*before* a VPN has been established *and* does *bridging*), there's no need to run a VPN between them in the first place. 3- Can you introduce a tool to easily generate keys? You're already using EasyRSA, that's about as easy¹ as it gets. Not that the act of generating a keypair looks that much different between EasyRSA, plain OpenSSL, or more sophisticated PKI tools ... ¹ "Easy" as in "easy to understand and use manually". Automation and integration may yield something that's easier *to use and maintain long-term*, but since you're apparently unclear on what other systems you're going to integrate it *with* (see next question), we can't comment on that. 4- You said " You need a PKI solution that doesn't just chuck new certs onto a local disk, but can feed it into whatever mechanism you use to keep the clients updated.", which mechanism? The mechanism that *you* are going to define (and, probably, build) that allows you to admin the clients you designed, and keeps the entire system from coming crashing down as soon as the first certificates' validity period ends. For example: a) Our staff is usually able to install a new client cert for their laptop's VPN connection to the company LAN themselves, so all we need *there* is an e-mailed reminder to IT that user XY will need a new cert in a couple weeks; but b) the firmware of the appliances we send to customers asks our servers "do I need to update something?" every morning, and if a VPN cert is running out, the servers i) verify that the customer's contract is still ongoing, ii) generate a new cert, and iii) inject it into a more general small-updates-offering mechanism that handles *all* config changes we hand to those appliances. 5- When I use "./easyrsa build-ca nopass", then it asks me "Common Name (eg: your user, host, or server name) [Easy-RSA CA]:", and as you said, better not to use "server" as name. For example, I entered "Jason_Server" ... which should better read "Jason's CA" (yes, blanks are OK there), as it still hasn't anything to do with any servers ... then I must use "Jason_Server" in the "./easyrsa gen-req Jason_Server nopass" and "./easyrsa sign-req server Jason_Server" commands. Right? Now *those* commands actually *are* part of generating the *server* certificate, so having them say "server" makes sense, unlike in creating the CA cert above. (I would still prefer server certs to have an FQDN for a CN, though. Old habits die hard ...) 6- Is this true for client too? Yes. (With the difference that VPN clients usually aren't expected to *have* a long-term-stable FQDN, so I would suggest naming the certs by user and/or device, like "Jason Long's private cell phone".) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 17.08.23 14:12, Jason Long wrote:
It is even better if each server has its own separate keys.
You didn't mention setting up multiple servers yet IIRC, but yes, same
best practice there ... in principle.
However, if you plan to instruct the clients to contact "*any* of
servers you find available" (e.g., by Round Robin DNS), you need them
all to pass the *exact same* server cert verification (like per
"verify-x509-name ..."). That *might* justify having multiple servers
use the same cert(s).
If the clients all use the same keys, then we can block any client
based on the IP address. It is true?
The design decisions you've made so far suggest that your VPN clients
will connect to the server from elsewhere than the site hosting your
server - maybe not just any random StarDonalds at Shady Mall, but are
you sure that you really can reliably identify them by their (public)
IP? Will you personally deliver them to customer sites and nail them to
a load-bearing wall?
1- Is there a tool to facilitate key generation for a large number
of clients?
Yes, several. And I wouldn't have too much of a problem scripting such a
run with nothing but bare OpenSSL, but.
The point is that you need to bring those client cert+keys *onto the
clients*, not just once, but everytime the previous client cert
approaches the end of its validity period. You need a PKI solution that
doesn't just chuck new certs onto a local disk, but can feed it into
whatever mechanism you use to keep the clients updated. And *then* one
of these two systems needs to keep tabs on which clients *should* get a
new cert (customers can terminate their contracts with you ...) and when.
2- I've heard that OpenVPN can be configured to work with username and
password instead of key-based authentication. Is this possible and
recommended?
I guess it's possible, but I don't run any such setup and thus can't
comment on it.
3- About the CN name, if I forget it, then if I open the "ca.crt" file
and click on the Details tab and check the Issuer section, then this
is the name that I have entered during generating the key?
No. The name you enter during generation of keypair and cert goes to the
cert's *Subject*, the Issuer is determined by the CA you use to sign the
cert.
4- If CN's name is Server, then I must change the ccd directory to
Server? Am I right?
If that's what the Subject CN of the cert you want to use as a client
cert says, then yes, that's it.
Of course, looking at a file "ca.crt" and seeing a CN "Server" for what
is supposed to be the *client's* cert is botched twelve ways to Gehenna
and back and will perpetually confuse anyone trying to debug your final
setup ...
In which part of the document is this said?
https://community.openvpn.net/openvpn/wiki/HOWTO
"The client must have a unique Common Name in its certificate ("client2"
in our example) [...] The next step is to create a file called client2
in the ccd directory."
https://community.openvpn.net/openvpn/wiki/HOWTO#IncludingmultiplemachinesontheclientsidewhenusingaroutedVPNdevtun
It doesn't explain how to look up the CN of a certificate from a file
containing it, though, because it assumes that you made sure to have it
created and installed in the correct location with the intended CN
"client2" beforehand and don't *need* to check "now which cert did this
client happen to end up with?".
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
smime.p7s
Description: S/MIME Cryptographic Signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 16.08.23 23:28, Jason Long wrote: 1- What is the difference between /etc/openvpn and /etc/openvpn/server directories? The systemd "unit files" that define the templates for the services you "systemctl" later on used to expect all configs - whether for a server or a client instance - to be named /etc/openvpn/SomeInstanceName.conf , i.e., configs for both modes would sit together. Later versions of systemd-enabled OpenVPN split that into /etc/openvpn/client and /etc/openvpn/server , respectively. I put my server.conf file in the /etc/openvpn directory and it worked. Then I'd say that your Debian 12 still uses the old convention, as did the how-to's Debian 10. (Over here, RHEL, Fedora, and IIRC Ubuntu as well take the new directories instead.) 2- You said [...] make those unique ideally per device, not just per user. How to make it unique per user?If I have 1000 clients, then I must generate 1000 key files??? Yes. By default, if several clients use the same cert+key, they'll keep pushing each other out of the VPN. Also, if you need to shut clients out of the service, revoking a cert is how you do it - *all* clients using that one cert will have their VPN access disabled, so clients sharing certs likely isn't what you want even if you disable the former default behavior. Also note that with "server ..." specifying only a /24 for an address pool, and with Windows clients (so that you can't use "topology p2p"), your VPN server will actually be limited to 64 simultaneous clients, anyway. 1000 clients at once require at least a /20. 3- For the CA certificate, I must use "Server" not "server". May I ask why? I never said that. If anything, the CN of your CA cert should mention "CA" somewhere, and *not* "server", no matter the capitalization. Wed Aug 16 11:01:39 2023 VERIFY OK: depth=1, CN=Server > Wed Aug 16 11:01:39 2023 VERIFY OK: depth=0, CN=server This shows that your client presents a cert with CN "server" as its *client* cert (the procedure in the how-to should result in a client cert with CN "client"), which verifies OK against a CA cert with a CN of "Server" (the how-to suggests that it should be "server", as misguided as that seems). Hence, either your client uses the *wrong* cert, or you misnamed the certs as you created them (even more than that how-to instructs you to). Anyway, in order to create a CCD file for your client using the cert it uses *now*, the CCD file would need to be named "server". Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 16.08.23 15:05, Jason Long wrote: I used "https://www.howtoforge.com/how-to-install-and-configure-openvpn-server-on-debian-10/"; tutorial to create my OpenVPN server. (No date on the article ... no date on the comments ... OpenVPN version not shown anywhere ... according to one systemctl output, probably written in September 2019, when Debian 10 and OpenSSL 1.1.1c were in fact current ... still using /etc/openvpn instead of /etc/openvpn/server and /etc/openvpn/client, respectively ... no mention of doing a "systemctl enable openvpn@ConfigFileBaseName" on the server ... no explicit description of what the VPN set up is supposed to *do* (apparently: secure Inet access for a road warrior, no other servers at the site hosting the VPN peer, no communication back to the clients) ... no discussion of how he came to pick 10.8.0.0/24 for the tunnel IPs, how (far) to check for IP conflicts, how many clients you can accomodate with that /24 ...) ... word of warning: Just because the how-to doesn't ask you to enter something at Common Name (eg: your user, host, or server name) [client]: and later has you type in ./easyrsa sign-req client client doesn't mean that you want all client certs to be named "client", or - even worse - use the same client cert for them all. Make those *unique* - ideally per device, not just per user. However, if you worked along *that* how-to, your CA certificate is indeed using the CN of "server" (not "Server", but that might be a liberty that MS took). Exactly the same as the server cert. X-C Common Name (eg: your user, host, or server name) [Easy-RSA CA]:server About the server log [...] # cat /var/log/openvpn/virt1.log 2023-08-16 06:23:18 WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible. [...] 2023-08-16 06:23:18 Initialization Sequence Completed That shows us the startup phase of the OpenVPN server. In order to check what the server thinks about the cert the client presents, you'll have to have the client make an attempt to connect, and then grab the logs from *those* couple seconds. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to use ccd-exclusive statement?
On 16.08.23 12:23, Jason Long via Openvpn-users wrote: On Wed, Aug 16, 2023 at 06:35:01AM +, Jason Long wrote: route 192.168.1.0 255.255.255.0 This tells the server "put routing towards 192.168.1.0 into the VPN" [...] So, what is the right IP for the following statement? route 192.168.1.0 255.255.255.0 Unknown. Gert told you what this config statement does, I don't remember you ever mentioning that you plan to use such a feature, much less what subnet(s) you'd want to use for that. I opened the ca.crt file on the client and clicked on the Details tab and it showed me "CN = Server". So, I must change the "Test-PC" to "Server". Am I right? ... aybe. I wouldn't be too surprised if your client-side OpenVPN config did indeed take a client cert named "Server" out of a file named "ca.crt" ... ... I would nonetheless recommend that you look at the server log (of suitable verbosity) for a line telling what cert/CN the client has actually sent, though. Kind regards -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] A question about "Local" option
On 06.08.23 22:41, Jason Long via Openvpn-users wrote: Hello,Any idea?I would be grateful if someone could guide me. On Wed, Aug 2, 2023 at 11:17 PM, Jason Long via Openvpn-users wrote: Hello,To use OpenVPN with a NIC that has multiple IP addresses set on it, I need to use the following statement in the server configuration file: Local "Virtual IP" But, when I use the following firewall rules and specify the virtual NIC, OpenVPN network card and IP range, is there still a need for Local "Virtual IP"? The "local" statement is *necessary* when and if the same port as in the OpenVPN config needs to be used somewhere else as well (be it by another OpenVPN instance, or some entirely different software), so as to use different *IP*-and-port combos instead. The conflict occurs as soon as the second software tries to start *LISTENing* on that port, with *no packets* being sent yet. Hence, your iptables setup is entirely irrelevant there. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] A question about the VPN providers
On 04.08.23 14:15, Jason Long via Openvpn-users wrote: When you rent a server from a company and they provide you the IP of different countries, it means that they have already done the routing "Yes" up to *this* point ... and you can set the IP of different countries on the NIC. ... and if you want to know what you can or cannot do with that server and its highly customized uplink, please ask the company providing it to you. (It's a design choice whether the public IPs get assigned to the server NIC (under your control) at all, or NATed away by the provider infrastructure. And proper per-customer network isolation doesn't scale well to only a *few* end-to-end-transparent public IPs per range/country.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and NIC with multiple IP Addresses
On 26.07.23 07:44, Jason Long wrote: I just created a virtual NIC and all the iptables rules that I did for a real NIC, I did for this virtual NIC too. Consider an OpenVPN server that has one NIC with three public IPs and you want to run an OpenVPN server.conf file for each IPs. You must set these three public IPs on your NIC and then launch your OpenVPN server. First off, *your* VPN server *doesn't* have public IPs; you've shown us the interface settings, and there were subnets of 10.0.0.0/8 in use. That's why I still think that your Internet access has an intervening NAT box that you haven't told us about yet. Second, here you're talking about the actual VPN connections that the clients make *to* the VPN server itself. Yes, if those three IPs (with whatever ports) are reachable from the Internet (the server's routing table may still be relevant here), that'll work. What we were talking about in the previous mail, however, was what SRC IPs the clients' traffic *through* the server will get set as they get MASQUERADEd upon exiting the server, and whether routing table and iptables' filter rules agree with *that*. Are my iptables rules wrong? Maybe. You've shown us only what you *actively changed* (no info on the chains' policies, for example), and the question what SRC IP the through traffic is MASQUERADEd to (to compare that with the filter rules) is still open. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and NIC with multiple IP Addresses
On 25.07.23 12:22, Jason Long wrote: You said "The rules seem to assume that Internet traffic *will* go out $IF_MAIN and not enp0s3.", Why enp0s3? I created a virtual NIC (enp0s3:0) and I want my traffic go through it. Am I wrong? I have no reason to doubt that you WANT to have it work like this. What did you *do* to MAKE that happen? Last time I read about similar issues - several *years* back -, the consensus IIRC was that when initiating a connection out of a physical NIC that has several IPs, the SRC IP will be chosen as -- the one *last* assigned to the NIC when running Linux, -- the *oldest* one when running Windows, and -- they all get used round-robin under BSD. I have no idea whether that does or doesn't extend from locally initiated connections to MASQUERADEd ones, though. Nailing it down with -j SNAT might be worthwhile, but since you have *several subnets* on that wire, you'd probably still need the routing table to agree with your choice. # cat /proc/sys/net/ipv4/conf/all/forwarding 1 (When you *read* the setting back, you might want to check the interfaces one by one, rather than just one "all" value ...) Unfortunately, I do not have "/var/log/kern.log" file!!! /var/log/syslog ? /var/log/messages ? journalctl ? Maybe dmesg, even? On the client routing tables are: https://pastebin.mozilla.org/QEVppj9X What is your opinion? 0.0.0.0/1 (and 128.0.0.0/1) point to the VPN and there's no more specific route to 8.8.8.8, so the pings *should* have gone into the VPN, as intended. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Server configuration file vs server
On 25.07.23 21:12, Jason Long wrote: So, if I need an auto-failover mechanism, then my servers (Physical or VM) key files must be the same Not quite. You *could* give the servers/instances certs identifying them as "vpn-in-0001" through "vpn-in-4711", and then have the client configs check only the CA's signature and the "vpn-in-" part of the cert CN, for example. Using the *exact same* key+cert across all instances is a still-simpler approach (as in, no need to verify every *single* instance's crypto setup after updates, etc.), but leaves you with empty hands if the one cert ever gets leaked/revoked. and if I don't need that mechanism, then all server configuration file can use the same keys. Am I right? You *can* use the same or different server certs, and different certs *can* be generated from the same privkey or different ones. As I said, it's *your* trade-off (vulnerable monoculture vs. maintenance complexity, yadda yadda) to make. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Server configuration file vs server
On 25.07.23 18:10, Jason Long via Openvpn-users wrote: Hello,I have a question and I'm thankful if someone clear it for me.I guess it would be better if each server has its own key files, but the server means the server configuration file or an OpenVPN (physical or VM) server?I mean, if an OpenVPN server has a lot of server configuration files (server-1.conf, server-2.conf,...) and they all use the same key files, is there a problem? OpenVPN, unlike browsers/websites or the SMTP world, does *not* come with builtin expectations that the cert must "match" the server in any way; instead, verification of the server cert is put into the hands of the client configuration (via the --remote-cert-*, --verify-x509-name etc. statements). Which is relevant because it is discouraged to have several simultaneous *certs* with the same ID, like when you want different *privkeys* to ID the same way. Having that said, if you want the clients to auto-failover between several instances, like with profiles, the client needs a *common* way to verify all those server's certs, with them all using the same keypair/cert being the simplest way to ensure that. On the other hand, if someone manages to hack a server (VM) and grabs the keys there, you have an interest to disable only *that* server, and not others just because they use the same now-compromised keypair. That trade-off is essentially yours to gauge ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN and NIC with multiple IP Addresses
On 25.07.23 09:54, Jason Long via Openvpn-users wrote: enp0s3: flags=4163 mtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 enp0s3:0: flags=4163 mtu 1500 inet 10.0.5.20 netmask 255.255.255.0 broadcast 10.0.5.255 ... so you have several distinct subnets attached to the same physical interface ... I added these iptables rules: # IF_MAIN=enp0s3:0 # IF_TUNNEL=tun2 # YOUR_OPENVPN_SUBNET=10.10.0.0/16 # iptables -I INPUT -p udp --dport 1196 -j ACCEPT # iptables -A FORWARD -i $IF_MAIN -o $IF_TUNNEL -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A FORWARD -s $YOUR_OPENVPN_SUBNET -o $IF_MAIN -j ACCEPT # iptables -t nat -A POSTROUTING -s $YOUR_OPENVPN_SUBNET -o $IF_MAIN -j MASQUERADE # iptables -A FORWARD -i enp0s8 -o enp0s3:0 -m state --state ESTABLISHED,RELATED -j ACCEPT # iptables -A FORWARD -i enp0s3:0 -o enp0s8 -j ACCEPT # iptables -A FORWARD -j LOG # iptables -t nat -A POSTROUTING -o enp0s8 -j MASQUERADE I don't see a FORWARD rule specifically permitting clients' traffic to the Internet (-i $IF_TUNNEL -o $IF_MAIN), but then again, we don't see the FORWARD chain's policy, either. The rules seem to assume that Internet traffic *will* go out $IF_MAIN and not enp0s3. Please verify that (been a while since I had a similar setup, so I'm not sure whether you'd have to look at the server's routing table(s) or something else ...). Is the server willing to do forwarding *at all* on the relevant interface(s) (e.g., 'echo 1 >/proc/sys/net/ipv4/conf/all/forwarding')? C:\>ping 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), So, what does your "-j LOG" in the FORWARD chain have to say about the fate of the ECHO REQUEST packets? What is your reverse path filtering set to (/proc/sys/net/ipv4/conf/*/rp_filter), any hint in the syslogs that "martians" got discarded (before ever being treated by iptables)? Are you familiar enough with tcpdump or Wireshark to go hunt for what packets go where during the pinging? ... oh, I almost forgot: What does the client have to say about its routing table, once the VPN is up? Do the ECHO REQUESTs actually ever go through the VPN in the first place? Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Multiple OpenVPN server on one NIC
On 23.07.23 16:35, Jason Long wrote: I have two more questions: 1- So, both of IP address and Port number must be different? 2- If the IP address is different, then the port can be the same? Please answer my questions by number. #2 is correct. For any protocol (like TCP and UDP) that uses "ports", IP address and port define an endpoint (that you can offer a distinct service on), and two endpoints define a connection. Whether it's the address, the port, or both that make an endpoint differ from another is irrelevant to everyone except the guy who has to set up the server. But what I actually wanted to tell you is that you'll have to pinpoint *which* IPs are actually relevant to your questions. If I guessed your setup correctly, then your VPN clients will connect to some public IP like, e.g., 200.100.50.25 (that's the relevant one), your NAT box forwards the connections to your OpenVPN server via its private IPs 10.20.40.80 (that's what you'll see set on its NICs), and once the client sends traffic *through* the VPN, it'll be seen coming from 100.64.32.16 (picked from the range in your server's "server" statement), rather than from whatever address the client has "in the Internet". It's important to keep all these addresses and their roles separate, as their choice/design follows different requirements. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Multiple OpenVPN server on one NIC
On 23.07.23 15:32, Jason Long via Openvpn-users wrote: 1- If the port number is different, then "server" IP can be the same? > For example, the first server use: port 1194 [...] server 10.8.0.0 255.255.255.0 The second server use: port 1195 [...] server 10.8.0.0 255.255.255.0 Or both of "port" and "server IP" must be different? Uuuhhh careful there. More below ... 2- You said, "A "NIC" can have multiple IP addresses", so, a server does not need to have multiple NAT NICs ? For example, A VPN provider can have a VPN server with a NIC that use three or four public IP addresses. The relevant IP addresses to decide whether you need to use different ports are those that the clients actually connect to to establish the VPN. (I.e., the ones in the "remote ..." statement of the clients' config.) In another list e-mail, you've shown your VPN server to use (at least two) *private* IPs to access Internet resources, so my guess is that you're going to have the clients connect to public IPs assigned to your Internet uplink, and that some separate device does NAT to redirect the traffic to your VPN server. In that case, in order to have different VPNs offered under the same port, you need two addresses *from those assigned to your Internet connection*; the VPN server can be left with just one internal IP (unless you get a *very* high number of VPN connections). However, the "server" statements in your server-side configs state what IPs the *clients* will be assigned to use for the traffic *inside* the VPN, once they have connected. You very probably want to put different IP ranges into every single config file, *regardless* of whether "port" matches between two configs or not. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] How to run multiple configuration files at the same time?
On 21.07.23 17:10, Gert Doering wrote: If you want multiple VPNs to be active at the same time, you need to run one openvpn instance with an individual config each. How to do that with systemd I wouldn't know (I'm a FreeBSD person). https://community.openvpn.net/openvpn/wiki/Systemd I.e., from a "template" unit file installed with OpenVPN, you derive one systemd service for each config file, and administrate those like you would a "standalone" service. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Updating OpenSSL broke OpenVPN's Support for CApath ... ?
Hello everyone, I have a weird problem and am looking for ideas how to analyze/fix it ... I have a CentOS 9 Stream VM that is set up as a VPN server, using the CentOS-repos-supplied openvpn-2.5.9-1.el9.x86_64 and OpenSSL packages. Originally, the OpenVPN instance was configured to use a CApath, and things worked OK. In early April, I updated the VM, and openssl-1:3.0.7-2.el9.x86_64 was replaced with openssl-1:3.0.7-5.el9.x86_64. From that point on, clients attempting to connect would yield server log entries like: VERIFY ERROR: depth=2, error=self-signed certificate in certificate chain: CN=binect.de, ... (for client certs issued by an intermediate CA, the error message referring to the root CA cert, both CAs using 2048 bit RSA keypairs and SHA256) or VERIFY ERROR: depth=0, error=unable to get local issuer certificate: ..., CN=CNG-Jochen, ... (for client certs issued directly from a different root CA, the error message referring to the client cert, the CA using 8192 bit RSA and SHA512). The workaround back then was to have OpenVPN use a CA *file* instead, containing the exact same three CA certs concatenated. (There are no CRLs - so far.) Today, I re-tested with openssl-1:3.0.7-18.el9.x86_64 (which the VM had been updated to in the meantime) and openssl-1:3.0.7-20.el9.x86_64 (fresh update), the problem persists. No AVCs, no other errors in the logs. Did a c_rehash on the CApath just to make sure, symlinks remain the same. OpenVPN runs as nobody, but everything around the CApath's world readable. (While the CA *file*, one dir above the CApath's files and symlinks, is happily root-only.) Checking client certs manually, as in "openssl verify --CAfile [CAfile] [ClientCertFile]" and "openssl verify --CApath [dir] [ClientCertFile]", "OK"s all combinations. (As it should.) How can I try to further narrow down the root cause? Thanks in advance, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
