pfSense 2.4.4-RELEASE-p2 is now available!
-
Sure, that's fine!
I prefer to keep the problems separate that way it's easier to help those with issues individually rather than getting all the conversations tangled up in a single large thread.
-
Hi, i've lost swap file after update to 2.4.4_2
-
@ataru75 said in pfSense 2.4.4-RELEASE-p2 is now available!:
Hi, i've lost swap file after update to 2.4.4_2
And you can't read:
@jimp said in pfSense 2.4.4-RELEASE-p2 is now available!:If you have a problem, please start a new thread in the appropriate category here on the forum rather than making a reply to this post.
-
-
Successful upgrade here from 2.4.4_1 to 2.4.4_2. This is on a native ZFS install running a Celeron J3455 and an Intel I340-T4. No errors and the system came up clean afterwards. Thanks for the bugfix release!
-
Successful upgrade on Netgate SG-3100.
-
Successful upgrade here from 2.4.4 to 2.4.4_2 on a Netgate SG-88601U. Did it remote (after a backup), and it took less than 10 minutes.
Jeff
-
Updated to 2.4.4_2 worked perfect. Ruuning on a i7-7500u. Took about 2 minutes.
-
Here too: 2.4.4-p1 -> 2.4.4-p2 on a APU2C0 without problems!
-
Update to 2.4.4_2 was successful on Intel i5. Took around 2 minutes.
-
upgraded from 2.4.4 to 2.4.4_2 on Intel Celeron J3455 with no problems, removed installed packages first then upgraded. after upgrade completed I reinstalled the packages and all is good. probably < 4 minutes with the package re-installs. Thank you Devs!
-
One of the resolved bugs - Bug #9178
Fixes or introduces the population of the 'Calling-Station-ID' attribute.
But it seems that the attribute is populated with the listening address and port of the OpenVPN server.
And the Called-Station-ID attribute is populated with the MAC address and hostname of the OpenVPN server.In my opinion, the calling-station-id should be populated with the IP address of the connecting client because this is the caller that is "calling" into the service,
And the Called-station-id should be the IP address of the OpenVPN server because that is the address of service that has been "called".So there is still no reference to the IP address and therefore the location of the connecting client.
Most Radius servers and 2FA systems use the calling-station-id to assess the location of the connecting client to help make a decision of whether to allow, deny or to further challenge the user.
Most commercial remote access products I have used work in this way. And I'm pretty sure the OpenVPN Access Server also populates the calling-station-id with the client IP address.This seems backward to me.
I cannot imagine any scenario where the MAC address of the OpenVPN server will be of any relevance to the Radius server.... -
@josef "If you have a problem, please start a new thread in the appropriate category here on the forum rather than making a reply to this post."
