I download to download a copy of "pfSense 2.4.2-RELEASE-p1"
-
OK, let's cut to the case.
If you were in my shoes what would you do if you had >10k mobile device in the field with CRTs that will expire in 6 months?
-
@ipguy Get started now ;) heheheh Make that 6 months ago..
Without some details its hard to say to be honest.. I don't even know if I would use pfsense if had 10k some remote devices trying to vpn in..
Management of certs for that many devices is no small feat.. Openvpn in pfsense might not be the best choice from a management stand point. Your going to have to do some heavy lifting most likely.
Are they these all company controlled laptops (windows?) Are they byod, are there other device types like phones or tablets involved?
Managing that many remote devices for vpn is not your typical scenario for openvpn on pfsense would be my gut reaction..
Are these devices that come into the office now and then, or are they 100% remote workers? Where you could push new vpn stuff while they are on prem, or do you need to update them all remotely while they are connected to the vpn, etc.
-
LOL
Pfsense works perfectly well with that number, no issues at all
More than 10K modems, each modem has a unique username and password but they all share/use the same server CRT
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
Pfsense works perfectly well with that number, no issues at all
Not saying it wouldn't work ;) What I am saying is the management of the certs for the clients could be a lot of heavy lifting ;)
Not using client certs makes it easier to manage.. How long was the original CA set for.. I never make a CA less than 10 years myself..
Getting the devices a new CA prob going to be painful..
-
Really the only reason to want that installer version would be to recover back to that version because you know that works. Which is not unreasonable IMO.
But otherwise you can import the config from 2.4.2p1 directly into 2.6 as others have said. I would at least try that as a test.
Steve
-
As mentioned earlier, I inherited this problem.
The new server has been successfully set up, thoroughly tested, and validated.
I have successfully transferred the CA (Certificate Authority) and CRTs (certificates) from the "old server" to the new one, ensuring seamless connectivity for remote modems.
Currently, I am facing a challenge related to CA/CRT renewal. I am exploring possibilities to avoid the need for updating CRTs on thousands of modems. My objective is to determine if there is a solution to update the CA/CRT without extensive updates required on the modems.
-
@ipguy what does that have to do with 2.4.2 version - I am confused to what that would get you?
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
what does that have to do with 2.4.2 version
I guess the intention was do the migration 1 step at a time
- Upgrade hardware but keep old software & configuration
- Upgrade software.
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
The migration to the new server is successfully accomplished, save for a couple of troublesome elements
Sound like gave up and did the hardware and software migration in one step.
-
Both servers are currently operational, and I have the ability to route traffic from the remote appliances to either one. The remote appliances (modems) are connecting without issue, primarily due to the utilization of the existing CA/CRT (which is set to expire in 6 months).
My objective is to determine if it's feasible to "renew" the expiring CRT and utilize it on the new server, which is running the latest version of pfSense, without requiring CRT updates on the remote appliances (modems) that are currently in production.
I would greatly appreciate any insights or advice regarding the possibility of achieving this goal. However, if it turns out that updating thousands of CRTs on the remote production appliances is the only viable solution, I will proceed accordingly. Nonetheless, I'm exploring alternatives to avoid this scenario if possible.
-
SHA256 (pfSense-netgate-memstick-2.4.2-RELEASE-p1-amd64.img.gz) = fa77c20d0d7582470cfaf1bd0ee4b64b350ef36c678d4121c5ba68385fa994e3Is this what you are searching for?
-Rico
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
My objective is to determine if it's feasible to "renew" the expiring CRT
Problem is if the CA is expiring - the modems copy of that CA will not be renewed.. And they will not trust the renewed cert once their copy of the CA expires.. You need to update the CA on the modem so it will trust your cert that has been renewed.
There is really no point in "renewing" the old CA.. You should just create a new one.. With a new server cert off this CA.. The problem is getting the new CA to the remote boxes.
Since your not using client certs you don't have to reissue 10k certs.. You just need the remote devices to get the new CA, so then you can issue a new server cert via this new CA. That they will trust.
One way to combat this problem, is use of multiple CAs - If your CA has a life of 10 years, this should be longer then the life of the deployed remote device.. You would as the CA and certs be it server and or client, once the CA is say over 1 year old and you are going to deploy new devices you would use a different CA for these devices as they get deployed. Now any remote device should be good for the 10 years..
The heavy lifting part is going to be getting the new CA to your 10k remote devices.
-
Thank you for your clear and concise answer
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
One way to combat this problem, is use of multiple CAs - If your CA has a life of 10 years, this should be longer then the life of the deployed remote device.. You would as the CA and certs be it server and or client, once the CA is say over 1 year old and you are going to deploy new devices you would use a different CA for these devices as they get deployed. Now any remote device should be good for the 10 years..
I've explored some aspects of CAs and CRTs before, but this experience is taking me into much deeper territory.
I may be mistaken but by the looks of the "-text -noout" of the CRT currently in use on the remote modems, see below
Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: C=MARS, ST=NYC, L=London, O=thanos/emailAddress=ca@network.thanos.com, CN=thanos-ca.network Validity Not Before: Jan 19 22:34:22 2014 GMT Not After : Jan 17 22:34:22 2024 GMT Subject: C=MARS, ST=NYC, L=London, O=thanos/emailAddress=ca@network.thanos.com, CN=thanos-ca.network Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:f4:94:86:07:f8:d7:dc:ef:ac:6a:cc:a2:c2:28: ... ... ... ... 0d:1c:79:e8:66:b1:bf:12:2c:50:2e:12:5b:e1:f7: 6a:93 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 58:E0:8B:60:1C:A9:61:92:CA:57:5C:53:8C:99:12:96:03:99:B0:91 X509v3 MARSthority Key Identifier: keyid:58:E0:8B:60:1C:A9:61:92:CA:57:5C:53:8C:99:12:96:03:99:B0:91 DirName:/C=MARS/ST=NYC/L=London/O=thanos/emailAddress=ca@network.thanos.com/CN=thanos-ca.network serial:00 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 2f:c8:26:32:25:29:af:37:05:b2:04:cd:80:a2:9f:3d:72:84: ... ... ... ... 30:c9:c4:a7:b6:53:7f:d4:8b:be:38:13:10:09:85:f0:af:dc: 64:18:b2:02The modem's are using a client CRT and a CA ?
Or am I mistaken ?
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
CA:TRUE
That is your CA cert.. Thought you said you were only using username:password to auth.. And not client certs..
So on your openvpn server setup.. What are you using?
I use only cert ssl/tls setting.
I you are using only "user auth" then there is no client cert.
If you are using the last one then you need both a client cert and user auth to connect..
If your not using client certs, then the only thing that needs to be deployed is the new CA cert to your remote devices. If you were using client certs you would need to deploy both the CA and the client cert.. Which would mean you would need to generate 10k new certs..
edit: One method to combat this problem is multiple instances of your openvpn server where every year say or every 2 you fire up a new instance of CA and server cert good for 10 years, even if using clients issued off this CA.. So new clients or replaced remote clients get the latest instance.. And should have a life of 9 to 10 years..
Part of the reason I brought up if was working with 10k remote devices not sure if would use openvpn on pfsense. There is going to be some lifting involved in making sure you don't run into a situation like your in where you have 10k devices that in 6 months are all going to be expired. If you plan for it - its not something that can't be handled.. But seems you fell into a mess.. Sorry but off the top of my head I can really think of a easy solution. You prob should just bite the bullet and figure out how you can get get the new CA deployed to all your devices..
Do you have control or access to these remote devices - or do only the local people have access. If you issue a new CA, and communicate to your remote sites they need to make the change on their client and point to the new instance running the new CA and server cert.. I would do that now, so they have 6 months to make the move.
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
I you are using only "user auth" then there is no client cert.
We are using "User Auth"
This experience has truly opened my eyes, as I realized that my understanding of (CAs) and (CRTs) was not as solid as I initially thought.
Let me make sure I understand correctly: I should first deploy a new (CA) to the remote appliances, and after that, proceed with renewing the (CRT) on the server
Am i correct?
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
proceed with renewing the (CRT) on the server
You wouldn't be able to "renew" if you create a new CA.. Either way your going to have to get either an update CA (renewed) or New one.. With a new one you can use say ecdsa vs old rsa..
Since you have to get either new or updated CA cert to the remote clients either way. You prob best creating a new CA, and issue a new server cert so you can make sure you using current best practice, etc. Where you can move to new ecdsa vs rsa..
Even if you just renew the CA and then renew the server cert - the CA still has to be gotten to the remotes..
Look on the bright side, you don't have to generate 10k new client certs ;)
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
Look on the bright side, you don't have to generate 10k new client certs ;)
Getting an additional, but new, CA on the modems is less risky than trying to replace/ renew the existing one
Thanks for your tireless input, it's greatly appreciated
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
Getting an additional, but new, CA on the modems is less risky than trying to replace/ renew the existing one
I would think so - because if doesn't work they should just be able to use the old one and connect to the old instance until you work out what is wrong.
-
I am confident that implementing an additional "new" CA on the remote devices will enable me to continue using the existing old CA along with the current old server CRT.
Moreover, it will provide me with the flexibility to update a DNS A record, directing the devices to the new server with the new CRT.
As you said
-
Mmm, there's probably quite a few people who'd benefit from your experiences with this. Let us know how it goes.
