Bug 1698532
| Summary: | [RFE] Provide auto-auth-retry option for 802.1x connection when connection fails | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Steffen Froemer <sfroemer> | ||||
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 8.0 | CC: | atragler, bgalvani, cww, dennis.schridde, fgiudici, heri, jmaxwell, lrintel, pasik, ptalbert, rkhan, sukulkar, thaller, tsales, vbenes | ||||
| Target Milestone: | rc | Keywords: | FutureFeature | ||||
| Target Release: | 8.2 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | NetworkManager-1.22.0-0.1.el8 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-04-28 16:52:36 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1738635, 1755139 | ||||||
| Attachments: |
|
||||||
In best case, while the connection is upgraded, established connections should survive. Perhaps NM should implement a 802.1x.fallback-noauth option that allows to fall back to unauthenticated access when authentication fails. Windows has a similar option: https://social.technet.microsoft.com/Forums/getfile/1233569 . Related discussion: https://bugzilla.gnome.org/show_bug.cgi?id=723084 When the authentication fails, NM would keep retrying periodically to upgrade to an authenticated access. Maybe an option would be, to build some junction between non-authorized, limited network connection and appropriate authenticated connection. This might provide some more security, to only fall back to connections, which are wanted to use. Just as an idea. Is there a way to get this discussion in [1] to get more speed? I see it's very old and such feature is still not existing. Only the timeout was improved, which is totally related to this request. [1]: https://bugzilla.gnome.org/show_bug.cgi?id=723084 Hi, we are currently evaluating different approaches to implement this functionality. In the first, a new 'optional' boolean property is added to the 802-1x setting. When it is set to true, the failure of 802.1X doesn't cause a connection failure. Instead, upon failure NM continues with activation and keeps wpa_supplicant alive. If the supplicant is able to complete authentication later, NM restarts DHCP to guarantee a fresh address is obtained for the authenticated network. Since it makes sense to have different firewall zones for authenticated and non-authenticated networks we would probably need also a new '802-1x.fallback-zone' property. In the second approach two profiles are defined, one for the authenticated network and one for the unauthenticated one; the first profile references the second one in the '802-1x.fallback-connection' property. When the first connection fails to authenticate, NM swaps the settings in the current ActiveConnection with the ones from the second profile and reapplies them without tearing the device down. When doing it, it also keeps the supplicant alive so that the swap can done again later if the authentication succeeds. These profile swaps are something new and they need core changes that might not be trivial to implement. The advantage of this second approach is that it becomes possible to define different settings (like the firewall zone, or IP configuration) for the two connections. But perhaps from a user point of view it is simpler to just set an 802-1x.optional=yes flag instead of defining two profiles. I will update you when there are news regarding the development of this feature. Hi, this sounds really interesting. I looking forward to get some news. Thanks. Hi, in the support cases attached to this bz, the customer mentions that running wpa_supplicant alone without NM on the interface lets the client connect to network even if the authentication server is temporarily down, as the client is put in a limited-access network. I have a few questions regarding this setup. Does the limited-access network use a different DHCP server than the authenticated one? If so, what happens after the infrastructure is restored, does the client have to wait the lease expiration to get a valid address in the authenticated network? Also, how does the switch completes authentication when the authentication server is not available? I tried this locally and I see the switch performs 3 authentication attempts, each returning a failure, and afterwards it sends an EAP-success, putting the client into a separate VLAN. But since I couldn't find any documentation in standards about this behavior, I'm wondering if it is implemented in the same way by all vendors. Would it be possible to ask the customer to provide a packet capture of the authentication and DHCP phases when using wpa_supplicant alone during the outage? And, if possible, also a capture of what happens when the infrastructure comes up again. Thanks! Hey Beniamino, I've talked with my customer, and beside the questions from your side totally make sense, they are not applicable to their environment. If the client is unauthenticated, it's basically impossible to do anything. The connection is limited to a few basic protocols like DHCP, ICMP and DNS. Anything else is blocked by infrastructure (switch). If there is an outage of Authentication service, e.g. RADIUS, it will be out of scope. The only thing, which matter is if 802.1x available, NetworkManager should try to authenticate. If there is nothing like this available, stay at "fallback"-connection and try to authenticate from time to time. Does it make sense? /steffen Hi Steffen, I have prepared a RFC branch [1] that adds a new 'optional' property to the 802-1x setting. When it is set to TRUE, NM will not fail the activation upon authentication timeout or failure, and will instead continue, leaving wpa_supplicant running. wpa_supplicant tries to reauthenticate every 60 seconds. I think should address the customer's needs, please let me know otherwise. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/249 Created attachment 1615997 [details]
test script
Merged upstream: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/495ae4a6761b1c458fa40cca501652e201243cac Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8. Will the fix become available in Fedora 31, too? (In reply to Dennis Schridde from comment #34) > Is see that this is Fixed In Version: NetworkManager-1.22.0-0.1.el8. Will > the fix become available in Fedora 31, too? Yes, it is already in F31 (NetworkManager-1.20.6-1.fc31). Hi Vlad, connection.auth-retries is the number of retries with a new password supplied by a secret agent. If there is no agent (i.e. no '--ask') the activation fails after the first attempt (after 20 seconds). Ideally the reproducer for this RFE would be similar to the script attached to this bz. But if it is too complicated, we can check that when setting 802-1x.optional=yes and there is no authenticator, the connection is established after the timeout period. test @8021x_auto_auth_retry_with_backup_network added Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:1847 |
1. Proposed title of this feature request [RFE] Provide auto-auth-retry option for 802.1x connection when connection fails 3. What is the nature and description of the request? The 802.1x connection is used for network access control of clients. If the client is not able to authenticate, it will fall back to a limited-access network. This could happen during infrastructure outage, where the authentication will fail and the limited-access connection chosen. If the infrastructure is back again, the client should automatically check if authentication is possible and upgrade to 802.1x authenticated connection 4. Why does the customer need this? (List the business requirements here) To cover infrastructure outage and automatically re-authenticate 5. How would the customer like to achieve this? (List the functional requirements here) If a client that has chosen a non 802.1x authenticated connection should continue to try authenticating and if possible upgrade to a 802.1x authenticated connection. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. With following network configuration, the outage of RADIUS server should degrade the connection to 'lan_eth0' and when the RADIUS server is back online, the conenction 'lan_eth0_nac' will be used again without manual interaction. expecting, ifname=eth0 FQDN=host1.exmaple.com nmcli connection add \ type ethernet \ ifname $ifname \ con-name lan_${ifname} \ connection.autoconnect yes \ connection.autoconnect-priority 0 \ ipv4.method auto \ ipv4.ignore-auto-dns yes \ ipv4.may-fail yes \ ipv4.never-default no \ ipv6.method ignore \ ipv6.may-fail yes nmcli connection add \ type ethernet \ ifname $ifname \ con-name lan_${ifname}_nac \ connection.autoconnect yes \ connection.autoconnect-priority 50 \ ipv4.method auto \ ipv4.ignore-auto-dns no \ ipv4.may-fail yes \ ipv4.never-default no \ ipv6.method ignore \ ipv6.may-fail yes \ 802-1x.identity "$(hostname -s)" \ 802-1x.eap tls \ 802-1x.ca-cert "/etc/wpa_supplicant/CA-Certs.pem" \ 802-1x.client-cert "/etc/wpa_supplicant/${FQDN}.crt" \ 802-1x.private-key "/etc/wpa_supplicant/${FQDN}.key" \ 802-1x.private-key-password-flags 4 \ 802-1x.auth-timeout 10 \ connection.auth-retries 1 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? no 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? asap 9. Is the sales team involved in this request and do they have any additional input? no 10. List any affected packages or components. NetworkManager 11. Would the customer be able to assist in testing this functionality if implemented? sure