RADIUS Authentication Fails (Server 2008R2)

pairughdocks

Hello OpenVPN Community!

I have a small issue with the RADIUS Authentication aspect of OpenVPN.

My RADIUS server is (192.168.1.1) and has a properly configured NPS. I followed this (http://docs.openvpn.net/how-to-tutorialsguides/administration/configuring-active-directory-windows-2008-server-r2-radius-server-for-openvpn-access-server/) guide 100% to allow OpenVPN clients to connect with their AD credentials.

OpenVPN is running inside Debian 7 and is 192.168.1.3 on my network. IPTABLES on my Linux machine running OpenVPN is set to allow tcp 943, UDP 1194, tcp 22, tcp 443, and udp 1812 (for RADIUS)

When I try to connect from an external client (not a domain member), I receive "invalid user name or password" if I switch access to local type and create a user, I can connect no problem.

Any thoughts/ideas as to what I'm doing wrong?

pairughdocks

Please BUMP this so hopefully someone can shed some light.

rsenio

The event viewer (security) on your NPS server will shed light on why you can't authenticate. Most likely due to your connection request policy or network policy. Pretty easy to troubleshoot

pairughdocks

Which I have gone through, and am still not able to locate the cause of the issue. Like I said, I followed the guide provided by OpenVPN and am in need of some minor assistance. Thank you.

rsenio

That's what I'm trying to do. If it is failing on the Radius authentication, then there HAS to be a corresponding event log of the failure. Without information no one can assist you.

It will be logged as an Audit Failure in the security log. If not, then it isn't even reaching your NPS or you have an issue with the Radius Client settings, shared key perhaps. Have you made sure the Firewall on your 2008r2 box isn't getting in the way.

pairughdocks

Yes, the firewall has the appropriate rules to pass through RADIUS authentication, I copied a rule from another server and replaced the IP address with the address of my Debian server running OpenVPN. I will look through the logs again and see if I can find an audit failure. I wasn't trying to be snarky either, I apologize if I came off as such.

rsenio

Yeah the logs should show you a failure. It really doesn't take much time, perhaps delete both the connection request policy and your radius client entry. Then start from scratch.

pairughdocks

Here is a generated failure log.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 1/22/2014 5:17:37 PM
Event ID: 6273
Task Category: Network Policy Server
Level: Information
Keywords: Audit Failure
User: N/A
Computer: zeus.eatvac.local
Description:
Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
Security ID: NULL SID
Account Name: mtmorrow
Account Domain: -
Fully Qualified Account Name: -

Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
OS-Version: -
Called Station Identifier: -
Calling Station Identifier: -

NAS:
NAS IPv4 Address: -
NAS IPv6 Address: -
NAS Identifier: OpenVPN.ares
NAS Port-Type: -
NAS Port: -

RADIUS Client:
Client Friendly Name: ares.eatvac.local
Client IP Address: 192.168.1.3

Authentication Details:
Connection Request Policy Name: -
Network Policy Name: -
Authentication Provider: -
Authentication Server: zeus.eatvac.local
Authentication Type: -
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 49
Reason: The RADIUS request did not match any configured connection request policy (CRP).

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>6273</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12552</Task>
<Opcode>0</Opcode>
<Keywords>0x8010000000000000</Keywords>
<TimeCreated SystemTime="2014-01-22T22:17:37.594767100Z" />
<EventRecordID>164779</EventRecordID>
<Correlation />
<Execution ProcessID="608" ThreadID="2936" />
<Channel>Security</Channel>
<Computer>zeus.eatvac.local</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-0-0</Data>
<Data Name="SubjectUserName">mtmorrow</Data>
<Data Name="SubjectDomainName">-</Data>
<Data Name="FullyQualifiedSubjectUserName">-</Data>
<Data Name="SubjectMachineSID">S-1-0-0</Data>
<Data Name="SubjectMachineName">-</Data>
<Data Name="FullyQualifiedSubjectMachineName">-</Data>
<Data Name="MachineInventory">-</Data>
<Data Name="CalledStationID">-</Data>
<Data Name="CallingStationID">-</Data>
<Data Name="NASIPv4Address">-</Data>
<Data Name="NASIPv6Address">-</Data>
<Data Name="NASIdentifier">OpenVPN.ares</Data>
<Data Name="NASPortType">-</Data>
<Data Name="NASPort">-</Data>
<Data Name="ClientName">ares.eatvac.local</Data>
<Data Name="ClientIPAddress">192.168.1.3</Data>
<Data Name="ProxyPolicyName">-</Data>
<Data Name="NetworkPolicyName">-</Data>
<Data Name="AuthenticationProvider">-</Data>
<Data Name="AuthenticationServer">zeus.eatvac.local</Data>
<Data Name="AuthenticationType">-</Data>
<Data Name="EAPType">-</Data>
<Data Name="AccountSessionIdentifier">-</Data>
<Data Name="ReasonCode">49</Data>
<Data Name="Reason">The RADIUS request did not match any configured connection request policy (CRP).</Data>
<Data Name="LoggingResult">Accounting information was written to the local log file.</Data>
</EventData>
</Event>

The Connection Request policy is set up to allow connections from 192.168.1.3 (ares.eatvac.local). The only condition is to allow ALL requests from Client IP 192.168.1.3. So, I don't see the breakdown issue. So I created a new condition and deleted the old IP condition, allowing ALL requests from NAS Identifier OpenVPN.ares (as listed) and I get connection time outs.

These are my current IPTables rules on my Debian server:

ryan@ares:~# nano iptables.rules
GNU nano 2.2.6 File: iptables.rules

:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [306:156896]
:AS0_WEBACCEPT - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j AS0_WEBACCEPT
-A INPUT -d 192.168.1.3/32 -p tcp -m state --state NEW -m tcp --dport 943 -j AS$
-A INPUT -p tcp -m tcp --dport 943 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m udp --dport 1723 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1812 -j ACCEPT
-A AS0_WEBACCEPT -j ACCEPT
COMMIT
# Completed on Sun Jan 19 22:48:06 2014

On my firewall:
WAN TCP/UDP 1812 is NAT'd to 192.168.1.3
and LAN->LAN traffic has no restrictions.

rsenio

Hmmm, something doesn't sound right.

You have the IP range specified in your connection request policy or network policy?

Mine is specified in the network policy, only accepting requests from the IP of my OpenVPN server, from my active directory VPN group. Where as my connection request policy is fairly wide open. If you have authentication methods specified in your connection request policy it is going to override the auth method you have specified in your network policy.

As per the error you have, it's a problem with your connection request policy

pairughdocks

So what you are saying is I do not need a connection request policy at all? It should just be a network request policy to allow (in my case the DOMAIN\Members group) since all of my users have VPN access.

pairughdocks

This issue has been resolved. Thank you rsenio, for making me dig through my logs to determine the ROOT cause of the issue. My clients can now happily authenticate via Active Directory 🙂

rsenio

Hey no problem, glad you have it figured out!

Wheelz

Does anyone know what plugin is used on the Access Server to do RADIUS authentication?
I am trying to use a RADIUS server with my community version of OpenVPN but havent had any luck....