मुख्य सामग्री पर जाएं

RadSec: TLS पर RADIUS किस प्रकार WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है

यह आधिकारिक तकनीकी संदर्भ बताता है कि कैसे RadSec (RFC 6614) पारंपरिक RADIUS ट्रैफ़िक को TLS एन्क्रिप्शन में लपेटकर एंटरप्राइज WiFi ऑथेंटिकेशन को सुरक्षित करता है। IT प्रबंधकों और नेटवर्क आर्किटेक्ट्स के लिए डिज़ाइन किया गया, यह कॉर्पोरेट और गेस्ट नेटवर्क पर अनएन्क्रिप्टेड UDP RADIUS ट्रैफ़िक के जोखिमों को कम करने के लिए आर्किटेक्चर, डिप्लॉयमेंट रणनीतियों और व्यावहारिक चरणों को कवर करता है।

📖 4 मिनट का पाठ📝 871 शब्द🔧 2 हल किए गए उदाहरण3 अभ्यास प्रश्न📚 8 मुख्य परिभाषाएं

इस गाइड को सुनें

पॉडकास्ट ट्रांसक्रिप्ट देखें
RadSec: TLS पर RADIUS किस प्रकार WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है एक Purple एंटरप्राइज WiFi इंटेलिजेंस ब्रीफिंग अनुमानित समय: 10 मिनट --- [परिचय और संदर्भ — लगभग 1 मिनट] Purple एंटरप्राइज WiFi इंटेलिजेंस सीरीज़ में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एक ऐसे विषय पर बात कर रहे हैं जो नेटवर्क सुरक्षा और परिचालन जोखिम के ठीक चौराहे पर स्थित है: RadSec — जिसे औपचारिक रूप से RFC 6614 में परिभाषित किया गया है — और यह आपके इन्फ्रास्ट्रक्चर रोडमैप पर क्यों होना चाहिए यदि यह पहले से नहीं है। यदि आप एक IT प्रबंधक, नेटवर्क आर्किटेक्ट, या CTO हैं जो किसी होटल समूह, रिटेल एस्टेट, स्टेडियम, या सार्वजनिक क्षेत्र के परिसर में एंटरप्राइज WiFi के लिए जिम्मेदार हैं, तो यह ब्रीफिंग आपके लिए है। हम कवर करने जा रहे हैं कि RadSec वास्तव में क्या है, पारंपरिक RADIUS प्रोटोकॉल आपको असुरक्षित क्यों छोड़ता है, वास्तविक दुनिया के वातावरण में RadSec को कैसे तैनात किया जाए, और वे कमियां जो टीमों को फंसाती हैं। केवल सिद्धांत के लिए सिद्धांत नहीं — बस वह जानकारी जिसकी आपको इस तिमाही में निर्णय लेने के लिए आवश्यकता है। आइए शुरू करते हैं। --- [तकनीकी गहन विश्लेषण — लगभग 5 मिनट] तो, चलिए समस्या से शुरू करते हैं। RADIUS — रिमोट ऑथेंटिकेशन डायल-इन यूजर सर्विस — 1990 के दशक से एंटरप्राइज WiFi ऑथेंटिकेशन की रीढ़ रहा है। जब कोई उपयोगकर्ता या उपकरण आपके कॉर्पोरेट या गेस्ट WiFi से जुड़ता है, तो एक्सेस पॉइंट एक RADIUS क्लाइंट के रूप में कार्य करता है, ऑथेंटिकेशन अनुरोधों को एक RADIUS सर्वर पर फॉरवर्ड करता है, जो आपकी निर्देशिका (Active Directory, LDAP, या क्लाउड पहचान प्रदाता) के विरुद्ध क्रेडेंशियल्स को सत्यापित करता है — और या तो पहुंच प्रदान करता है या अस्वीकार करता है। यह 802.1X ऑथेंटिकेशन मॉडल है जो WPA2-Enterprise और WPA3-Enterprise नेटवर्क को आधार प्रदान करता है। समस्या यह है कि पारंपरिक RADIUS को एक अलग युग के लिए डिज़ाइन किया गया था। यह पोर्ट 1812 और 1813 पर UDP — यूजर डेटाग्राम प्रोटोकॉल — पर चलता है। UDP कनेक्शन रहित (connectionless) है, जिसका अर्थ है कि कोई हैंडशेक नहीं है, कोई सेशन स्टेट नहीं है, और गंभीर रूप से, कोई नेटिव एन्क्रिप्शन नहीं है। आपके एक्सेस पॉइंट और आपके RADIUS सर्वर के बीच एकमात्र सुरक्षा एक शेयर्ड सीक्रेट है — अनिवार्य रूप से एक पासवर्ड — जिसका उपयोग MD5 हैशिंग का उपयोग करके पारगमन (transit) में उपयोगकर्ता के पासवर्ड को छिपाने के लिए किया जाता है। MD5, जैसा कि आप में से अधिकांश लोग जानते होंगे, क्रिप्टोग्राफिक रूप से टूट चुका है। यह वर्षों से टूटा हुआ है। व्यावहारिक रूप से इसका क्या अर्थ है? इसका अर्थ है कि किसी भी नेटवर्क सेगमेंट पर जहां एक हमलावर RADIUS ट्रैफ़िक को इंटरसेप्ट कर सकता है — और इसमें समझौता किए गए स्विच, आपके प्रबंधन VLAN पर नकली उपकरण, या रिमोट एक्सेस पॉइंट और क्लाउड-होस्टेड RADIUS सर्वर के बीच का कोई भी बिंदु शामिल है — वे संभावित रूप से ऑथेंटिकेशन एक्सचेंजों को कैप्चर कर सकते हैं, शेयर्ड सीक्रेट के खिलाफ ऑफलाइन डिक्शनरी हमलों का प्रयास कर सकते हैं, और कुछ कॉन्फ़िगरेशन में, उपयोगकर्ता क्रेडेंशियल्स को पूरी तरह से उजागर कर सकते हैं। 200 संपत्तियों में गेस्ट WiFi चलाने वाले होटल समूह के लिए, या प्रत्येक स्टोर में एक्सेस पॉइंट वाले रिटेल चेन के लिए जो सार्वजनिक इंटरनेट पर एक केंद्रीय RADIUS सर्वर पर बैकहॉल कर रहे हैं, यह कोई सैद्धांतिक जोखिम नहीं है। यह एक लाइव अटैक सरफेस है। RadSec बिल्कुल इसी समस्या को हल करता है। RadSec — जिसे RFC 6614 में परिभाषित किया गया है और RFC 7360 द्वारा अपडेट किया गया है — RADIUS ट्रैफ़िक को एक TLS टनल के भीतर लपेटता है। UDP के बजाय, यह पोर्ट 2083 पर TCP का उपयोग करता है। शेयर्ड सीक्रेट और MD5 के बजाय, यह X.509 सर्टिफिकेट के साथ म्यूचुअल TLS ऑथेंटिकेशन का उपयोग करता है। RADIUS क्लाइंट और RADIUS सर्वर दोनों सर्टिफिकेट प्रस्तुत करते हैं, एक-दूसरे की पहचान सत्यापित करते हैं, और कोई भी ऑथेंटिकेशन डेटा एक्सचेंज होने से पहले एक एन्क्रिप्टेड सेशन स्थापित करते हैं। TLS 1.3 वर्तमान अनुशंसित संस्करण है, जो फॉरवर्ड सीक्रेसी प्रदान करता है और पुराने सिफर की कई कमजोरियों को समाप्त करता है। व्यावहारिक प्रभाव महत्वपूर्ण है। क्रेडेंशियल डेटा, उपयोगकर्ता एट्रिब्यूट्स और सेशन टोकन एक्सेस पॉइंट — या RadSec प्रॉक्सी — और RADIUS सर्वर के बीच एंड-टू-एंड एन्क्रिप्टेड होते हैं। तार (wire) पर ट्रैफ़िक को इंटरसेप्ट करने वाले हमलावर को केवल एन्क्रिप्टेड TLS रिकॉर्ड दिखाई देते हैं। शेयर्ड सीक्रेट अभी भी बैकवर्ड कम्पैटिबिलिटी के लिए मौजूद है, लेकिन यह अब कोई सार्थक सुरक्षा कार्य नहीं कर रहा है — TLS पूरा भार उठा रहा है। यहाँ एक और आयाम है जो तेजी से प्रासंगिक हो रहा है: रोमिंग। पूरे यूरोप और उससे आगे के विश्वविद्यालयों और अनुसंधान संस्थानों द्वारा उपयोग किया जाने वाला Eduroam फेडरेशन, अपने अंतर-संस्थागत रोमिंग इन्फ्रास्ट्रक्चर के हिस्से के रूप में वर्षों से RadSec चला रहा है। हाल ही में, Wi-Fi Alliance का OpenRoaming मानक — जो भाग लेने वाले स्थलों पर निर्बाध WiFi रोमिंग सक्षम बनाता है — सभी फेडरेशन ट्रैफ़िक के लिए RadSec को अनिवार्य करता है। यदि आप OpenRoaming-सक्षम इन्फ्रास्ट्रक्चर तैनात कर रहे हैं, तो RadSec वैकल्पिक नहीं है; यह एक पूर्वापेक्षा है। Purple अपने Connect लाइसेंस के तहत OpenRoaming का समर्थन करता है, फेडरेशन के भीतर एक पहचान प्रदाता के रूप में कार्य करता है, और RadSec इस बात के केंद्र में है कि वह सुरक्षित रोमिंग फैब्रिक कैसे काम करता है। अनुपालन के दृष्टिकोण से, RadSec तेजी से PCI-DSS 4.0 के लिए प्रासंगिक हो रहा है, जो पारगमन में ऑथेंटिकेशन डेटा की सुरक्षा के आसपास की आवश्यकताओं को कड़ा करता है। यदि आपका WiFi इन्फ्रास्ट्रक्चर भुगतान कार्ड वातावरण को छूता है — और रिटेल और हॉस्पिटैलिटी में, यह अक्सर ऐसा करता है — तो पारंपरिक RADIUS में एन्क्रिप्शन का अंतर एक बड़ी कमी साबित हो सकता है। GDPR को इसी तरह व्यक्तिगत डेटा की सुरक्षा के लिए उचित तकनीकी उपायों की आवश्यकता होती है; आपके नेटवर्क पर अनएन्क्रिप्टेड बहने वाले उपयोगकर्ता क्रेडेंशियल्स और सेशन मेटाडेटा का डेटा सुरक्षा ऑडिट में बचाव करना कठिन है। अब आइए आर्किटेक्चर के बारे में बात करते हैं। RadSec के लिए दो प्राथमिक डिप्लॉयमेंट पैटर्न हैं। पहला आपके RADIUS सर्वर और एक्सेस पॉइंट्स पर नेटिव RadSec सपोर्ट है। FreeRADIUS 3.0 और उससे ऊपर नेटिव रूप से RadSec का समर्थन करता है। Microsoft NPS वर्तमान रिलीज़ के अनुसार नेटिव रूप से RadSec का समर्थन नहीं करता है, जो Windows-केंद्रित इन्फ्रास्ट्रक्चर चलाने वाले संगठनों के लिए एक महत्वपूर्ण बाधा है। Cisco ISE RadSec का समर्थन करता है। Aruba ClearPass RadSec का समर्थन करता है। यदि आपका RADIUS सर्वर और आपका एक्सेस पॉइंट विक्रेता दोनों नेटिव रूप से RadSec का समर्थन करते हैं, तो यह सबसे साफ रास्ता है — दोनों सिरों पर TLS सर्टिफिकेट कॉन्फ़िगर करें, अपने फ़ायरवॉल पर TCP 2083 खोलें, और आप RADIUS ट्रैफ़िक को एंड-टू-एंड एन्क्रिप्ट कर रहे हैं। दूसरा पैटर्न एक RadSec प्रॉक्सी है। यह व्यवहार में अधिक सामान्य डिप्लॉयमेंट है, विशेष रूप से पुराने RADIUS इन्फ्रास्ट्रक्चर या मिश्रित-विक्रेता वातावरण वाले संगठनों के लिए। एक RadSec प्रॉक्सी — radsecproxy सबसे व्यापक रूप से तैनात ओपन-सोर्स इम्प्लीमेंटेशन है — आपके एक्सेस पॉइंट्स और आपके RADIUS सर्वर के बीच बैठता है। एक्सेस पॉइंट स्थानीय नेटवर्क पर प्रॉक्सी को UDP पर मानक RADIUS भेजते हैं। प्रॉक्सी उस कनेक्शन को समाप्त करता है, RADIUS ट्रैफ़िक को एक TLS टनल के भीतर फिर से एनकैप्सुलेट करता है, और इसे TCP 2083 पर अपस्ट्रीम RADIUS सर्वर पर फॉरवर्ड करता है। यह दृष्टिकोण आपको अपने RADIUS सर्वर को बदले बिना मौजूदा इन्फ्रास्ट्रक्चर में RadSec जोड़ने की अनुमति देता है, और यह विशेष रूप से तब उपयोगी होता है जब आपका RADIUS सर्वर क्लाउड में होस्ट किया जाता है या सार्वजनिक इंटरनेट पर एक्सेस किया जाता है। सर्टिफिकेट प्रबंधन वह परिचालन जटिलता है जिसके लिए आपको योजना बनाने की आवश्यकता है। म्यूचुअल TLS के लिए उपयोग किए जाने वाले X.509 सर्टिफिकेट जारी करने और प्रबंधित करने के लिए आपको एक PKI — पब्लिक की इन्फ्रास्ट्रक्चर — की आवश्यकता होगी। इसका मतलब है एक सर्टिफिकेट अथॉरिटी, प्रत्येक RADIUS क्लाइंट और सर्वर के लिए सर्टिफिकेट जारी करना, और समाप्ति से पहले सर्टिफिकेट रोटेशन की एक प्रक्रिया। बिना ध्यान दिए समाप्त होने वाले सर्टिफिकेट आपके नेटवर्क पर एक साथ हर उपयोगकर्ता के लिए ऑथेंटिकेशन को तोड़ देंगे — और यह एक ऐसा परिदृश्य है जिससे आप बचना चाहते हैं। ACME या अपने CA के API का उपयोग करके सर्टिफिकेट नवीनीकरण को स्वचालित करें, और समाप्ति तिथियों से काफी पहले निगरानी अलर्ट सेट करें। --- [इम्प्लीमेंटेशन सिफारिशें और कमियां — लगभग 2 मिनट] मैं आपको व्यावहारिक सिफारिशें देता हूँ। पहला: तैनात करने से पहले ऑडिट करें। अपने वातावरण में प्रत्येक RADIUS क्लाइंट — एक्सेस पॉइंट्स, VPN कंसंट्रेटर्स, 802.1X करने वाले स्विच — और प्रत्येक RADIUS सर्वर का मानचित्रण (map) करें। समझें कि कौन से नेटिव रूप से RadSec का समर्थन करते हैं और किसे प्रॉक्सी की आवश्यकता होगी। यह ऑडिट आमतौर पर उन पुराने उपकरणों को सामने लाता है जो बिल्कुल भी TLS का समर्थन नहीं करते हैं, और उन्हें आपके प्रतिस्थापन (replacement) रोडमैप पर होना चाहिए। दूसरा: उच्चतम जोखिम वाले ट्रैफ़िक से शुरू करें। यदि आपके पास सार्वजनिक इंटरनेट से गुजरने वाला RADIUS ट्रैफ़िक है — रिमोट साइट्स, क्लाउड-होस्टेड RADIUS, बहु-संपत्ति होटल समूह — तो यह आपकी पहली प्राथमिकता है। एक अच्छी तरह से खंडित (segmented) प्रबंधन VLAN पर स्थानीय RADIUS ट्रैफ़िक कम जोखिम वाला है, लेकिन यह अभी भी रोडमैप पर होना चाहिए। तीसरा: गो-लाइव से पहले म्यूचुअल TLS का पूरी तरह से परीक्षण करें। RadSec डिप्लॉयमेंट में सबसे आम विफलता मोड सर्टिफिकेट सत्यापन त्रुटियां हैं — बेमेल कॉमन नेम, समाप्त हो चुके मध्यवर्ती (intermediate) सर्टिफिकेट, या क्लाइंट जो सर्वर सर्टिफिकेट पर हस्ताक्षर करने वाले CA पर भरोसा नहीं करते हैं। प्रोडक्शन ट्रैफ़िक को शुरू करने से पहले TLS हैंडशेक का परीक्षण करने के लिए openssl s_client का उपयोग करें। चौथा: निगरानी की उपेक्षा न करें। RadSec एक TCP कनेक्शन लेयर जोड़ता है जो पारंपरिक RADIUS में नहीं होती है। TCP कनेक्शन की विफलताएं, TLS हैंडशेक टाइमआउट और सर्टिफिकेट त्रुटियां आपके उपयोगकर्ताओं के लिए ऑथेंटिकेशन विफलताओं के रूप में प्रकट होंगी। सुनिश्चित करें कि आपके RADIUS सर्वर लॉग और आपके प्रॉक्सी लॉग आपके SIEM या मॉनिटरिंग प्लेटफॉर्म में फीड हो रहे हैं ताकि आप ऑथेंटिकेशन नीति की समस्या से RadSec कनेक्टिविटी समस्या में अंतर कर सकें। मैं जो कमी सबसे अधिक देखता हूँ वह यह है कि संगठन सर्वर साइड पर RadSec तैनात करते हैं लेकिन अपने फ़ायरवॉल नियमों को अपडेट करना भूल जाते हैं। प्रत्येक RADIUS क्लाइंट और RADIUS सर्वर या प्रॉक्सी के बीच TCP 2083 खुला होना चाहिए। यदि आप UDP 1812 नियमों को प्रबंधित करने के आदी हैं, तो फ़ायरवॉल परिवर्तन प्रक्रिया में TCP 2083 छूट सकता है। --- [रैपिड-फायर प्रश्नोत्तर — लगभग 1 मिनट] आइए मैं कुछ ऐसे सवालों पर नज़र डालूँ जो मैं नियमित रूप से सुनता हूँ। "क्या RadSec 802.1X को प्रतिस्थापित करता है?" नहीं। RadSec एक्सेस पॉइंट और RADIUS सर्वर के बीच ट्रांसपोर्ट लेयर को सुरक्षित करता है। 802.1X क्लाइंट डिवाइस और एक्सेस पॉइंट के बीच ऑथेंटिकेशन फ्रेमवर्क है। वे विभिन्न परतों पर काम करते हैं और एक-दूसरे के पूरक हैं। "क्या RadSec सभी एक्सेस पॉइंट विक्रेताओं पर समर्थित है?" सार्वभौमिक रूप से नहीं। Cisco, Aruba, Ruckus, और Meraki सभी के पास RadSec समर्थन के विभिन्न स्तर हैं — अपने विशिष्ट फर्मवेयर संस्करण की जांच करें। जहां नेटिव सपोर्ट अनुपस्थित है, वहां RadSec प्रॉक्सी आपका समाधान है। "DTLS — DTLS पर RADIUS के बारे में क्या?" RFC 7360 DTLS पर RADIUS को परिभाषित करता है, जो TCP के बजाय UDP का उपयोग करता है, एन्क्रिप्शन जोड़ते समय पारंपरिक RADIUS की कुछ कनेक्शन रहित विशेषताओं को संरक्षित करता है। यह TLS पर RadSec की तुलना में कम व्यापक रूप से तैनात है लेकिन यदि हाई-थ्रूपुट वातावरण में लेटेंसी एक चिंता का विषय है तो यह मूल्यांकन करने योग्य है। "यह रोमिंग प्रदर्शन को कैसे प्रभावित करता है?" RadSec का TCP कनेक्शन लगातार (persistent) बना रहता है, जो वास्तव में बाद के ऑथेंटिकेशन अनुरोधों के लिए कनेक्शन सेटअप ओवरहेड को कम करके फेडरेटेड वातावरण में रोमिंग प्रदर्शन में सुधार कर सकता है। --- [सारांश और अगले कदम — लगभग 1 मिनट] समाप्त करने के लिए: RadSec पारंपरिक RADIUS में एक वास्तविक सुरक्षा अंतर का परिपक्व, मानकों-आधारित उत्तर है। यदि आप बड़े पैमाने पर एंटरप्राइज WiFi चला रहे हैं — कई साइटों पर, इंटरनेट पर, या PCI-DSS या GDPR के अधीन वातावरण में — तो सवाल यह नहीं है कि RadSec को तैनात किया जाए या नहीं, बल्कि यह है कि कब और कैसे। आपके अगले कदम: इस सप्ताह अपने RADIUS इन्फ्रास्ट्रक्चर का ऑडिट करें। अपने उच्चतम जोखिम वाले ट्रैफ़िक प्रवाह की पहचान करें। नेटिव RadSec समर्थन के लिए अपने RADIUS सर्वर और एक्सेस पॉइंट विक्रेता के दस्तावेज़ों की जांच करें। यदि आप FreeRADIUS चला रहे हैं, तो आप एक दिन में एक परीक्षण RadSec डिप्लॉयमेंट चला सकते हैं। यदि आप Microsoft NPS पर हैं, तो प्रॉक्सी या RadSec-सक्षम सर्वर पर माइग्रेशन पथ का मूल्यांकन करना शुरू करें। Purple का प्लेटफ़ॉर्म एंटरप्राइज RADIUS इन्फ्रास्ट्रक्चर के साथ एकीकृत करने के लिए डिज़ाइन किया गया है, जो कॉर्पोरेट और गेस्ट WiFi दोनों वातावरणों के लिए सुरक्षित ऑथेंटिकेशन प्रवाह का समर्थन करता है। यदि आप यह समझना चाहते हैं कि RadSec आपके विशिष्ट डिप्लॉयमेंट में कैसे फिट बैठता है, तो Purple टीम इस प्रक्रिया में आपका मार्गदर्शन कर सकती है। सुनने के लिए धन्यवाद। अगली बार तक। --- स्क्रिप्ट का अंत

header_image.png

Executive Summary

Traditional RADIUS over UDP (ports 1812/1813) was not designed for the modern enterprise threat landscape. Relying solely on a shared secret and MD5 hashing, it leaves authentication credentials and session attributes vulnerable to interception, particularly when traversing public networks or large distributed estates like hospitality and retail chains. RadSec (RADIUS over TLS, RFC 6614) solves this fundamental security gap by encapsulating RADIUS traffic within a TCP-based TLS 1.3 tunnel over port 2083.

For CTOs and network architects, deploying RadSec is no longer just a best practice—it is a critical requirement for protecting corporate wifi , maintaining PCI DSS 4.0 compliance, and participating in modern federated roaming frameworks like OpenRoaming. This guide details the architecture, implementation patterns, and operational requirements for securing your authentication infrastructure.

Technical Deep-Dive: RADIUS vs. RadSec

The Vulnerability in Traditional RADIUS

In a standard 802.1X deployment, the access point (authenticator) forwards client credentials to the RADIUS server (authentication server). In traditional RADIUS, this payload is sent over UDP. The only protection is a pre-shared key (PSK) used to obfuscate the password via MD5.

This architecture presents three critical risks:

  1. Lack of Transport Encryption: User attributes, MAC addresses, and session data are transmitted in cleartext.
  2. Cryptographic Weakness: MD5 is vulnerable to offline dictionary attacks if an attacker captures the traffic.
  3. No Mutual Authentication: The access point cannot cryptographically verify it is talking to the legitimate RADIUS server, enabling rogue server attacks.

The RadSec Architecture (RFC 6614)

RadSec addresses these flaws by shifting the transport layer from UDP to TCP and wrapping the entire payload in TLS.

architecture_overview.png

  • Transport: TCP Port 2083 ensures reliable delivery and stateful connections, improving performance in high-latency environments.
  • Encryption: TLS 1.2 or 1.3 provides robust, end-to-end encryption of all RADIUS attributes.
  • Mutual Authentication: Both the RADIUS client (or proxy) and the server must present valid X.509 certificates issued by a trusted Certificate Authority (CA). The shared secret is retained only for backwards compatibility; TLS provides the actual security. This architecture is essential for distributed environments, such as Retail chains or Hospitality venues, where access points backhaul authentication requests over the public internet to a central or cloud-hosted RADIUS server.

Implementation Guide

Deploying RadSec typically follows one of two patterns: Native Support or Proxy-based.

Pattern 1: Native RadSec

If your infrastructure supports it natively (e.g., FreeRADIUS 3.0+, Cisco ISE, Aruba ClearPass), you configure TLS certificates directly on the RADIUS server and the access points/controllers. This provides true end-to-end encryption from the edge to the core.

Pattern 2: The RadSec Proxy

Many legacy RADIUS servers (notably Microsoft NPS) do not natively support RadSec. In these environments, a proxy (such as radsecproxy) is deployed.

  1. Local Leg: The AP sends standard UDP RADIUS to the local proxy.
  2. WAN Leg: The proxy encapsulates the traffic in TLS and sends it over TCP 2083 to the upstream server.

This pattern allows you to secure wide-area traffic without replacing legacy infrastructure.

deployment_checklist.png

Integration with Purple

Purple's Guest WiFi and WiFi Analytics platforms integrate seamlessly with enterprise RADIUS infrastructure. Under the Connect licence, Purple acts as a free identity provider for OpenRoaming, where RadSec is a mandatory requirement for securing federation traffic between venues and the central hub.

Best Practices

  1. Certificate Lifecycle Management: Mutual TLS relies on valid certificates. Implement automated renewal (e.g., via ACME) and strict monitoring. An expired certificate will cause a total authentication outage.
  2. Firewall Configuration: Ensure TCP port 2083 is explicitly allowed both outbound from the venue and inbound to the RADIUS server. Do not assume existing UDP 1812 rules will apply.
  3. Prioritise High-Risk Traffic: Begin deployment on links that traverse the public internet or untrusted WANs before moving to local management VLANs.

For more on securing the edge, read our guide on Access Point Security: Your 2026 Enterprise Guide .

Troubleshooting & Risk Mitigation

When RadSec fails, it is rarely an authentication issue; it is almost always a TLS or TCP issue.

  • Symptom: Access points show as disconnected from the RADIUS server.
    • Check: Firewall rules for TCP 2083. Traditional RADIUS uses UDP; network teams frequently forget to open the TCP port.
  • Symptom: TCP connection establishes, but authentication fails immediately.
    • Check: Certificate validation. Verify that the Common Name (CN) or Subject Alternative Name (SAN) matches, the certificate has not expired, and the client trusts the signing CA. Use openssl s_client -connect :2083 to debug the handshake.

Ensure your network fundamentals are solid. Review our advice on Protect Your Network with Strong DNS and Security .

ROI & Business Impact

Implementing RadSec is a risk mitigation investment. The ROI is measured in the avoidance of data breaches, compliance fines (PCI DSS, GDPR), and reputational damage. Furthermore, it enables participation in modern roaming federations like OpenRoaming, which can significantly enhance the guest experience in Healthcare and Transport environments.

Listen to the Briefing

For a deeper dive into the operational realities of deploying RadSec, listen to our 10-minute technical briefing:

For specific configuration steps on client devices, refer to How to Set Up Enterprise WiFi on iOS and macOS with 802.1X or the Portuguese version Como Configurar WiFi Corporativo em iOS e macOS com 802.1X .

मुख्य परिभाषाएं

RadSec

RADIUS प्रोटोकॉल का एक विस्तार जो TCP पोर्ट 2083 पर एक TLS टनल के भीतर RADIUS ट्रैफ़िक को एनकैप्सुलेट करता है।

अविश्वसनीय नेटवर्क से गुजरते समय ऑथेंटिकेशन ट्रैफ़िक को सुरक्षित करने के लिए उपयोग किया जाता है, जिससे क्रेडेंशियल इंटरसेप्शन को रोका जा सके।

Mutual TLS (mTLS)

एक सुरक्षा प्रक्रिया जहां क्लाइंट और सर्वर दोनों एक एन्क्रिप्टेड कनेक्शन स्थापित करने से पहले एक-दूसरे की पहचान सत्यापित करने के लिए X.509 सर्टिफिकेट प्रस्तुत करते हैं।

RadSec का मुख्य ऑथेंटिकेशन तंत्र, जो स्थिर शेयर्ड सीक्रेट्स पर निर्भरता को प्रतिस्थापित करता है।

802.1X

पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए IEEE मानक, जिसका उपयोग LAN या WLAN से कनेक्ट करने का प्रयास करने वाले उपकरणों को ऑथेंटिकेट करने के लिए किया जाता है।

वह फ्रेमवर्क जो किसी निर्देशिका (directory) के विरुद्ध उपयोगकर्ता क्रेडेंशियल्स को सत्यापित करने के लिए RADIUS (और विस्तार से, RadSec) पर निर्भर करता है।

radsecproxy

एक ओपन-सोर्स डेमन जो एक प्रॉक्सी के रूप में कार्य करता है, मानक UDP RADIUS ट्रैफ़िक को RadSec (TCP पर TLS) में और इसके विपरीत परिवर्तित करता है।

तब तैनात किया जाता है जब एक्सेस पॉइंट्स या Microsoft NPS जैसे पुराने RADIUS सर्वर से नेटिव RadSec सपोर्ट गायब होता है।

OpenRoaming

Wi-Fi Alliance द्वारा विकसित एक फेडरेशन मानक जो उपयोगकर्ताओं को विश्व स्तर पर भाग लेने वाले WiFi नेटवर्क से सहज और सुरक्षित रूप से कनेक्ट करने की अनुमति देता है।

OpenRoaming स्थलों और पहचान प्रदाताओं के बीच ऑथेंटिकेशन ट्रैफ़िक को सुरक्षित करने के लिए RadSec के उपयोग को अनिवार्य करता है।

Shared Secret

पारंपरिक RADIUS में पासवर्ड को छिपाने और अनुरोधों के स्रोत को सत्यापित करने के लिए उपयोग की जाने वाली एक स्थिर टेक्स्ट स्ट्रिंग।

हालांकि तकनीकी रूप से बैकवर्ड कम्पैटिबिलिटी के लिए RadSec कॉन्फ़िगरेशन में अभी भी मौजूद है, लेकिन इसे TLS एन्क्रिप्शन द्वारा प्रतिस्थापित कर दिया गया है।

FreeRADIUS

एक व्यापक रूप से तैनात ओपन-सोर्स RADIUS सर्वर जो RadSec के लिए नेटिव सपोर्ट प्रदान करता है।

अपनी लचीलेपन और नेटिव TLS क्षमताओं के कारण अक्सर एंटरप्राइज वातावरण और रोमिंग फेडरेशन में उपयोग किया जाता है।

PKI (Public Key Infrastructure)

डिजिटल सर्टिफिकेट बनाने, प्रबंधित करने, वितरित करने और निरस्त करने के लिए आवश्यक भूमिकाओं, नीतियों और सॉफ़्टवेयर का ढांचा।

RadSec को तैनात करने के लिए एक पूर्वापेक्षा, क्योंकि आपको सभी RADIUS क्लाइंट और सर्वर के लिए सर्टिफिकेट जारी और प्रबंधित करने होंगे।

हल किए गए उदाहरण

एक 200-संपत्ति वाला होटल समूह कर्मचारियों के ऑथेंटिकेशन के लिए केंद्रीय रूप से Microsoft NPS का उपयोग करता है। प्रत्येक होटल के एक्सेस पॉइंट वर्तमान में UDP 1812 के माध्यम से सार्वजनिक इंटरनेट पर RADIUS अनुरोध भेजते हैं। CTO सभी ऑथेंटिकेशन ट्रैफ़िक के लिए एन्क्रिप्शन को अनिवार्य करता है, लेकिन इस वर्ष NPS को बदलना कोई विकल्प नहीं है।

प्रत्येक होटल साइट पर एक RadSec प्रॉक्सी (जैसे, radsecproxy) और NPS सर्वर के सामने केंद्रीय डेटा सेंटर में एक संबंधित प्रॉक्सी तैनात करें। स्थानीय AP स्थानीय प्रॉक्सी को UDP RADIUS भेजते हैं। स्थानीय प्रॉक्सी इंटरनेट के माध्यम से केंद्रीय प्रॉक्सी के लिए TCP 2083 पर एक म्यूचुअल TLS टनल स्थापित करती है। केंद्रीय प्रॉक्सी TLS टनल को समाप्त करती है और NPS सर्वर को मानक UDP RADIUS फॉरवर्ड करती है।

परीक्षक की टिप्पणी: यह दृष्टिकोण मुख्य सुरक्षा लक्ष्य को प्राप्त करता है—अविश्वसनीय WAN पर ऑथेंटिकेशन डेटा को एन्क्रिप्ट करना—इसके लिए मुख्य Microsoft NPS इन्फ्रास्ट्रक्चर को महंगे और विघटनकारी तरीके से बदलने (rip-and-replace) की आवश्यकता नहीं होती है। यह प्रॉक्सी के लिए सर्टिफिकेट प्रबंधन ओवरहेड पेश करता है, जिसे स्वचालित किया जाना चाहिए।

एक बड़ा विश्वविद्यालय आने वाले शिक्षाविदों के लिए निर्बाध पहुंच की अनुमति देने के लिए अपने पूरे परिसर में OpenRoaming तैनात कर रहा है। वे FreeRADIUS 3.0 चला रहे हैं।

FreeRADIUS के भीतर नेटिव RadSec सक्षम करें। OpenRoaming फेडरेशन द्वारा विश्वसनीय CA से X.509 सर्टिफिकेट जनरेट करें। फेडरेशन हब के लिए इनबाउंड और आउटबाउंड TCP 2083 ट्रैफ़िक की अनुमति देने के लिए कैंपस फ़ायरवॉल को कॉन्फ़िगर करें। सभी फेडरेशन-बाउंड ऑथेंटिकेशन अनुरोधों के लिए RadSec का उपयोग करने के लिए वायरलेस LAN कंट्रोलर्स को कॉन्फ़िगर करें।

परीक्षक की टिप्पणी: चूंकि FreeRADIUS नेटिव रूप से RadSec का समर्थन करता है, इसलिए किसी प्रॉक्सी की आवश्यकता नहीं है। यह सबसे साफ आर्किटेक्चर है। यहाँ महत्वपूर्ण निर्भरता यह सुनिश्चित करना है कि सर्टिफिकेट OpenRoaming फेडरेशन की विशिष्ट PKI आवश्यकताओं के अनुरूप हों।

अभ्यास प्रश्न

Q1. आपकी टीम ने आपके रिमोट ब्रांच एक्सेस पॉइंट्स और आपके केंद्रीय FreeRADIUS सर्वर के बीच नेटिव RadSec तैनात किया है। AP सर्वर को पिंग कर सकते हैं, लेकिन ऑथेंटिकेशन अनुरोध पूरी तरह से टाइम आउट हो रहे हैं, और कोई भी ट्रैफ़िक RADIUS लॉग तक नहीं पहुंच रहा है।

संकेत: RadSec पारंपरिक RADIUS की तुलना में एक अलग ट्रांसपोर्ट प्रोटोकॉल और पोर्ट का उपयोग करता है।

मॉडल उत्तर देखें

फ़ायरवॉल संभवतः TCP पोर्ट 2083 को ब्लॉक कर रहा है। पारंपरिक RADIUS के आदी नेटवर्क टीमें अक्सर केवल UDP पोर्ट 1812/1813 की अनुमति देती हैं। आपको स्पष्ट रूप से शाखा से आउटबाउंड और RADIUS सर्वर पर इनबाउंड TCP 2083 की अनुमति देनी होगी।

Q2. आप एक रिटेल क्लाइंट के WiFi आर्किटेक्चर का ऑडिट कर रहे हैं। वे केंद्रीय रूप से Microsoft NPS का उपयोग करते हैं। उनके स्टोर AP एक IPsec VPN के माध्यम से इंटरनेट पर ऑथेंटिकेशन अनुरोध भेजते हैं। क्या यहाँ RadSec की आवश्यकता है?

संकेत: पहले से मौजूद एन्क्रिप्शन की परतों पर विचार करें।

मॉडल उत्तर देखें

हालांकि RadSec सर्वोत्तम अभ्यास है, IPsec VPN पहले से ही अविश्वसनीय इंटरनेट पर UDP RADIUS ट्रैफ़िक के लिए ट्रांसपोर्ट लेयर एन्क्रिप्शन प्रदान कर रहा है। यहाँ RadSec को तैनात करना गहन सुरक्षा (defence-in-depth) प्रदान करेगा लेकिन यह उसकी तुलना में कम जरूरी है यदि ट्रैफ़िक नेटिव रूप से इंटरनेट से गुजर रहा होता।

Q3. एक सफल RadSec प्रॉक्सी डिप्लॉयमेंट के एक सप्ताह बाद, पूरे एंटरप्राइज में सभी WiFi ऑथेंटिकेशन सोमवार को सुबह 09:00 बजे एक साथ विफल हो जाते हैं। नेटवर्क टीम पुष्टि करती है कि फ़ायरवॉल नियम अपरिवर्तित हैं।

संकेत: TLS टनल के लिए प्राथमिक ऑथेंटिकेशन तंत्र क्या है?

मॉडल उत्तर देखें

म्यूचुअल TLS ऑथेंटिकेशन के लिए उपयोग किए जाने वाले X.509 सर्टिफिकेट संभवतः समाप्त हो गए हैं। जब सर्टिफिकेट समाप्त हो जाते हैं, तो TLS हैंडशेक विफल हो जाता है, TCP कनेक्शन टूट जाता है, और RADIUS ट्रैफ़िक प्रवाहित नहीं हो पाता है। इसे रोकने के लिए स्वचालित सर्टिफिकेट निगरानी और रोटेशन लागू करें।

इस श्रृंखला में आगे पढ़ें

Staff और Guest WiFi नेटवर्क को सुरक्षित रूप से कैसे अलग करें

यह आधिकारिक तकनीकी गाइड IT लीडर्स को VLAN और 802.1X का उपयोग करके staff, guest और IoT WiFi नेटवर्क को सुरक्षित रूप से अलग करने के लिए व्यावहारिक रणनीतियाँ प्रदान करती है। यह विवरण देती है कि एंटरप्राइज़ इन्फ्रास्ट्रक्चर को कैसे सुरक्षित किया जाए, PCI DSS अनुपालन कैसे बनाए रखा जाए, और फर्स्ट-पार्टी डेटा कैप्चर करने के लिए captive portals का लाभ कैसे उठाया जाए।

गाइड पढ़ें →

सर्वश्रेष्ठ DNS filtering: व्यवसायों के लिए एक व्यापक गाइड

यह तकनीकी संदर्भ गाइड बताती है कि कैसे एंटरप्राइज़ DNS filtering रिज़ॉल्यूशन लेयर पर दुर्भावनापूर्ण डोमेन को ब्लॉक करके सार्वजनिक नेटवर्क को सुरक्षित करता है - इससे पहले कि कोई कनेक्शन स्थापित हो। यह IT डायरेक्टर्स, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशंस टीमों को वह डिप्लॉयमेंट आर्किटेक्चर, फ़ायरवॉल कॉन्फ़िगरेशन और अनुपालन संदर्भ देता है जो उन्हें हॉस्पिटैलिटी, रिटेल और पब्लिक-सेक्टर के वातावरण में गेस्ट WiFi की सुरक्षा के लिए चाहिए। Purple Shield 80,000+ से अधिक लाइव वेन्यू में DNS स्तर पर मैलवेयर, बॉटनेट्स और अनुचित सामग्री को ब्लॉक करता है।

गाइड पढ़ें →

Cisco SUDI को समझना: सुरक्षित नेटवर्क एक्सेस कंट्रोल में हार्डवेयर-एंकर वाली पहचान

यह गाइड बताती है कि Cisco SUDI एंटरप्राइज़ नेटवर्क इंफ्रास्ट्रक्चर के लिए हार्डवेयर-एंकर वाली, क्रिप्टोग्राफ़िक रूप से सुरक्षित पहचान कैसे प्रदान करता है। सीखें कि अपने स्थान के नेटवर्क एक्सेस कंट्रोल को सुरक्षित करने के लिए स्पूफ़ किए जा सकने वाले MAC पते को अपरिवर्तनीय 802.1AR प्रमाणपत्रों से कैसे बदलें।

गाइड पढ़ें →