RadSec: কীভাবে RADIUS over TLS WiFi অথেন্টিকেশন সিকিউরিটি উন্নত করে
এই প্রামাণিক টেকনিক্যাল রেফারেন্সটি ব্যাখ্যা করে কীভাবে RadSec (RFC 6614) ঐতিহ্যবাহী RADIUS ট্রাফিককে TLS এনক্রিপশনে র্যাপ করে এন্টারপ্রাইজ WiFi অথেন্টিকেশন সুরক্ষিত করে। আইটি ম্যানেজার এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য ডিজাইন করা এই গাইডে কর্পোরেট এবং গেস্ট নেটওয়ার্ক জুড়ে আনএনক্রিপ্টেড UDP RADIUS ট্রাফিকের ঝুঁকি কমানোর আর্কিটেকচার, ডিপ্লয়মেন্ট স্ট্র্যাটেজি এবং ব্যবহারিক পদক্ষেপগুলো কভার করা হয়েছে।
এই গাইডটি শুনুন
পডকাস্ট ট্রান্সক্রিপ্ট দেখুন
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:
- Lack of Transport Encryption: User attributes, MAC addresses, and session data are transmitted in cleartext.
- Cryptographic Weakness: MD5 is vulnerable to offline dictionary attacks if an attacker captures the traffic.
- 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.
- 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.
- Local Leg: The AP sends standard UDP RADIUS to the local proxy.
- 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.
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
- 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.
- 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.
- 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 :2083to debug the handshake.
- 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
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-এর সাথে কানেক্ট করার চেষ্টাকারী ডিভাইসগুলোকে অথেন্টিকেট করতে ব্যবহৃত হয়।
যে ফ্রেমওয়ার্কটি একটি ডিরেক্টরির বিপরীতে ইউজার ক্রেডেনশিয়াল যাচাই করতে RADIUS (এবং এক্সটেনশন হিসেবে, RadSec)-এর ওপর নির্ভর করে।
radsecproxy
একটি ওপেন-সোর্স ডেমন যা প্রক্সি হিসেবে কাজ করে, স্ট্যান্ডার্ড UDP RADIUS ট্রাফিককে RadSec (TLS over TCP)-এ রূপান্তর করে এবং এর বিপরীতটিও করে।
অ্যাক্সেস পয়েন্ট বা 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 ক্লায়েন্ট এবং সার্ভারের জন্য সার্টিফিকেট ইস্যু এবং ম্যানেজ করতে হবে।
সমাধানকৃত উদাহরণসমূহ
একটি ২০০-প্রপার্টির হোটেল গ্রুপ স্টাফ অথেন্টিকেশনের জন্য সেন্ট্রালি Microsoft NPS ব্যবহার করে। প্রতিটি হোটেলের অ্যাক্সেস পয়েন্টগুলো বর্তমানে UDP 1812-এর মাধ্যমে পাবলিক ইন্টারনেটে RADIUS রিকোয়েস্ট পাঠায়। CTO সমস্ত অথেন্টিকেশন ট্রাফিকের জন্য এনক্রিপশন বাধ্যতামূলক করেছেন, কিন্তু এই বছর NPS প্রতিস্থাপন করা সম্ভব নয়।
প্রতিটি হোটেল সাইটে একটি RadSec প্রক্সি (যেমন, radsecproxy) এবং NPS সার্ভারের সামনে সেন্ট্রাল ডেটা সেন্টারে একটি সংশ্লিষ্ট প্রক্সি ডিপ্লয় করুন। লোকাল AP-গুলো লোকাল প্রক্সিতে UDP RADIUS পাঠায়। লোকাল প্রক্সি ইন্টারনেটের মাধ্যমে সেন্ট্রাল প্রক্সিতে TCP 2083-এর ওপর একটি মিউচুয়াল TLS টানেল স্থাপন করে। সেন্ট্রাল প্রক্সি TLS টানেলটি টার্মিনেট করে এবং NPS সার্ভারে স্ট্যান্ডার্ড UDP RADIUS ফরোয়ার্ড করে।
একটি বড় বিশ্ববিদ্যালয় ভিজিটিং শিক্ষাবিদদের নিরবচ্ছিন্ন অ্যাক্সেস দেওয়ার জন্য তাদের ক্যাম্পাস জুড়ে OpenRoaming ডিপ্লয় করছে। তারা FreeRADIUS 3.0 ব্যবহার করছে।
FreeRADIUS-এর মধ্যে নেটিভ RadSec এনাবল করুন। OpenRoaming ফেডারেশন দ্বারা বিশ্বস্ত একটি CA থেকে X.509 সার্টিফিকেট জেনারেট করুন। ফেডারেশন হাবগুলোতে ইনবাউন্ড এবং আউটবাউন্ড TCP 2083 ট্রাফিক অনুমোদন করতে ক্যাম্পাস ফায়ারওয়াল কনফিগার করুন। সমস্ত ফেডারেশন-বাউন্ড অথেন্টিকেশন রিকোয়েস্টের জন্য RadSec ব্যবহার করতে ওয়্যারলেস LAN কন্ট্রোলারগুলো কনফিগার করুন।
অনুশীলনী প্রশ্নসমূহ
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 ডিপ্লয় করা ডিফেন্স-ইন-ডেপথ প্রদান করবে, তবে ট্রাফিক যদি নেটিভভাবে ইন্টারনেট অতিক্রম করত তার তুলনায় এটি কম জরুরি।
Q3. একটি সফল RadSec প্রক্সি ডিপ্লয়মেন্টের এক সপ্তাহ পর, সোমবার সকাল ০৯:০০ টায় এন্টারপ্রাইজ জুড়ে সমস্ত WiFi অথেন্টিকেশন একসাথে ব্যর্থ হয়। নেটওয়ার্ক টিম নিশ্চিত করে যে ফায়ারওয়াল রুলগুলো অপরিবর্তিত রয়েছে।
ইঙ্গিত: TLS টানেলের নিজস্ব প্রাথমিক অথেন্টিকেশন মেকানিজম কী?
মডেল উত্তর দেখুন
মিউচুয়াল TLS অথেন্টিকেশনের জন্য ব্যবহৃত X.509 সার্টিফিকেটগুলোর মেয়াদ সম্ভবত শেষ হয়ে গেছে। সার্টিফিকেটের মেয়াদ শেষ হলে, TLS হ্যান্ডশেক ব্যর্থ হয়, TCP কানেকশন ড্রপ করে এবং RADIUS ট্রাফিক ফ্লো করতে পারে না। এটি প্রতিরোধ করতে অটোমেটেড সার্টিফিকেট মনিটরিং এবং রোটেশন বাস্তবায়ন করুন।
এই সিরিজে পড়া চালিয়ে যান
কীভাবে নিরাপদে Staff এবং Guest WiFi নেটওয়ার্ক পৃথক করবেন
এই তথ্যবহুল টেকনিক্যাল গাইডটি IT লিডারদের VLAN এবং 802.1X ব্যবহার করে নিরাপদে staff, guest এবং IoT WiFi নেটওয়ার্ক পৃথক করার জন্য কার্যকর কৌশল প্রদান করে। এটি কীভাবে এন্টারপ্রাইজ ইনফ্রাস্ট্রাকচার সুরক্ষিত করতে হয়, PCI-DSS কমপ্লায়েন্স বজায় রাখতে হয় এবং ফার্স্ট-পার্টি ডেটা সংগ্রহ করার জন্য captive portal ব্যবহার করতে হয় তার বিস্তারিত বিবরণ দেয়।
সেরা DNS filtering: ব্যবসার জন্য একটি ব্যাপক নির্দেশিকা
এই প্রযুক্তিগত রেফারেন্স নির্দেশিকাটি ব্যাখ্যা করে যে কীভাবে এন্টারপ্রাইজ DNS filtering কোনো কানেকশন স্থাপন করার আগেই - রেজোলিউশন স্তরে ক্ষতিকারক ডোমেনগুলিকে ব্লক করে পাবলিক নেটওয়ার্কগুলিকে সুরক্ষিত করে। এটি আইটি ডিরেক্টর, নেটওয়ার্ক আর্কিটেক্ট এবং ভেন্যু অপারেশন টিমকে ডেপ্লয়মেন্ট আর্কিটেকচার, ফায়ারওয়াল কনফিগারেশন এবং কমপ্লায়েন্সের প্রসঙ্গ প্রদান করে যা হসপিটালিটি, রিটেল এবং পাবলিক সেক্টর এনভায়রনমেন্টে গেস্ট WiFi সুরক্ষিত রাখতে তাদের প্রয়োজন। Purple Shield ৮০,০০০+ এরও বেশি লাইভ ভেন্যু জুড়ে DNS স্তরে ম্যালওয়্যার, বটনেট এবং অনুপযুক্ত কন্টেন্ট ব্লক করে।
Cisco SUDI বোঝা: Secure Network Access Control-এ হার্ডওয়্যার-অ্যাঙ্কর্ড আইডেন্টিটি
এই নির্দেশিকাটি ব্যাখ্যা করে যে কিভাবে Cisco SUDI এন্টারপ্রাইজ নেটওয়ার্ক পরিকাঠামোর জন্য হার্ডওয়্যার-অ্যাঙ্কর্ড, ক্রিপ্টোগ্রাফিকভাবে সুরক্ষিত আইডেন্টিটি প্রদান করে। আপনার ভেন্যুর নেটওয়ার্ক অ্যাক্সেস কন্ট্রোল সুরক্ষিত করতে সহজে স্পুফ করা যায় এমন MAC অ্যাড্রেসের পরিবর্তে অপরিবর্তনীয় 802.1AR সার্টিফিকেট কিভাবে ব্যবহার করবেন তা জানুন।