MikroTik as RADIUS client to Windows NPS, Framed-Pool not being respected/ where are DHCP responses coming from??

libove · Mon Jan 16, 2017 12:43 pm

Hi MikroTik community,
I've got a RouterBOARD 951Ui 2HnD (RouterOS v6.38) set up as a VPN server (SSTP). Everything works fine when the VPN clients (Windows 10 workstations) use local authentication from the RouterBOARD (that is, they login using ID+password from /ppp secret).
However, I've recently turned on the RADIUS client on the RouterBOARD to forward authentication to a Windows Server 2012R2 Active Directory Domain Controller, so that it is not necessary to manually maintain /ppp secret on the RouterBOARD, and so that Windows clients can both connect to the RouterBOARD VPN and authenticate to the Windows Domain at the same time.
The MikroTik is 192.168.255.3 and the Windows server is 192.168.255.8.

It works, except:
The problem is that whereas local auth on the RouterBOARD respects the IP-Pool setting (/ppp profile remote-address=VPNpool1), the Windows NPS RADIUS server is returning an IP addresse from ... I can't even figure out where, and sends that IP address in a Framed-IP-Address RADIUS response attribute, despite that I've configured these RADIUS attributes in the Windows server's Network Policy:
Framed-Protocol: PPP
Service-Type: Framed
Framed-Pool: VPNpool1

The only DHCP server on the whole network is the Windows Server's DHCP server. It has two ranges configured:
192.168.255.10-192.168.255.62
192.168.255.64-79

Here is the MikroTik's IP pool VPNpool1:

> /ip pool print det
 0 name="VPNpool1" ranges=192.168.255.80-192.168.255.89

The IP address which my SSTP VPN client is getting from the MikroTik SSTP VPN is 192.168.255.32.
The IP address 192.168.255.32 does not appear in the Windows Server's DHCP server's list of Address Reservations nor Leases.
Packet capturing on port 67 or port 68 on the MikroTik and on the Windows Server sees no DHCP messages.
Packet capturing the RADIUS dialogue between the MikroTik and the Windows Server clearly shows Framed-IP-Pool: 192.168.255.32 being returned by the Windows Server's RADIUS server to the MikroTik's RADIUS client, and packet capturing on the MikroTik itself then clearly shows that 192.168.255.32 being returned to the SSTP VPN client, and I see the SSTP VPN client settings its IP address on the SSTP VPN connection to 192.168.255.32.
But I simply cannot figure out where the Windows Server is deciding on this 192.168.255.32 address!

I'm sure I'm missing something obvious and I'll feel quite silly once it's found... Anyone please want to help me figure out what I'm being blind to here?
Configuration details below.

thanks!

> /ppp secret print
Flags: X - disabled 
 #   NAME                            SERVICE CALLER-ID                         PASSWORD                         PROFILE                         REMOTE-ADDRESS 
 0 X user1.local                     any                                       **********                       default-encryption             
 1 X user2.local                     any                                       **********                       default-encryption

(So, that avoids any local /ppp secret from authenticating the connection and being what supplies the IP address, which means that the MikroTik's SSTP VPN server will fall through to RADIUS authentication, which we do see it doing correctly.)

> /ppp profile print
Flags: * - default 
 0 * name="default" use-mpls=default use-compression=default use-encryption=default only-one=default change-tcp-mss=yes use-upnp=default address-list="" 
     on-up="" on-down="" 

 1 * name="default-encryption" local-address=192.168.255.125 remote-address=VPNpool1 use-mpls=default use-compression=default use-encryption=yes 
     only-one=default change-tcp-mss=yes use-upnp=default address-list="" dns-server=192.168.255.8 on-up="" on-down=""

It is ppp profile #1 above which is active (default-encryption). 192.168.255.125 is a local IP address on the MikroTik which is the MikroTik's SSTP Server VPN endpoint for SSTP client VPN connections. 192.168.255.8 is the Windows Server 2012R2, Active Directory Domain Controller, DNS server, DHCP server, and NPS/RADIUS server. We do see that the route pushed by the MikroTik SSTP VPN server to the SSTP VPN client does show 192.168.255.125 as the server end of the SSTP VPN connection, so I am confident that it is indeed /ppp profile 1 which is being selected by the MikroTik.

> /ppp aaa print
                     use-radius: yes
                     accounting: yes
  use-circuit-id-in-nas-port-id: no
                 interim-update: 0s

PPP AAA is enabled.

 > /ip dhcp-server print
Flags: X - disabled, I - invalid 
 #   NAME                                 INTERFACE                               RELAY           ADDRESS-POOL                               LEASE-TIME ADD-ARP
 0 X default                              ether2-master-local                                     VPNpool1                                   10m

There is no active DHCP server on the MikroTik.

> /radius print det
Flags: X - disabled 
 0   service=ppp called-id="" domain="AD3.felines.org" address=192.168.255.8 secret="***********************************************" 
     authentication-port=1812 accounting-port=1813 timeout=300ms accounting-backup=no realm=""

The MikroTik RADIUS client is configured to talk to my Windows server's Active Directory Domain AD3.felines.org on the Windows server's IP address 192.168.255.8. (This works. The SSTP VPN clients do authenticate successfully to the Windows Active Directory).

Here's a /log print of a MikroTik SSTP VPN session, RADIUS access request and accept:

11:16:58 radius,debug new request 1b:38 code=Access-Request service=ppp called-id=0.0.0.0 domain=ad3.felines.org 
11:16:58 radius,debug sending 1b:38 to 192.168.255.8:1812 
11:16:58 radius,debug,packet sending Access-Request with id 49 to 192.168.255.8:1812 
11:16:58 radius,debug,packet     Signature = 0x********
11:16:58 radius,debug,packet     Service-Type = 2 
11:16:58 radius,debug,packet     Framed-Protocol = 1 
11:16:58 radius,debug,packet     NAS-Port = 9 
11:16:58 radius,debug,packet     NAS-Port-Type = 0 
11:16:58 radius,debug,packet     User-Name = "user1" 
11:16:58 radius,debug,packet     Calling-Station-Id = "74.130.23.57" 
11:16:58 radius,debug,packet     Called-Station-Id = "0.0.0.0" 
11:16:58 radius,debug,packet     MS-CHAP-Domain = "ad3.felines.org" 
11:16:58 radius,debug,packet     MS-CHAP-Challenge = 0x********
11:16:58 radius,debug,packet     MS-CHAP2-Response = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ****
11:16:58 radius,debug,packet     NAS-Identifier = "MikroTik1" 
11:16:58 radius,debug,packet     MT-Realm = 0x********
11:16:58 radius,debug,packet     NAS-IP-Address = 192.168.255.3 
11:16:58 radius,debug,packet received Access-Accept with id 49 from 192.168.255.8:1812 
11:16:58 radius,debug,packet     Signature = 0x********
11:16:58 radius,debug,packet     Framed-Protocol = 1 
11:16:58 radius,debug,packet     Service-Type = 2 
11:16:58 radius,debug,packet     Framed-IP-Address = 192.168.255.32 
11:16:58 radius,debug,packet     Class = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet     MS-MPPE-Recv-Key = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ****
11:16:58 radius,debug,packet     MS-MPPE-Send-Key = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ****
11:16:58 radius,debug,packet     MS-CHAP2-Success = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet     MS-CHAP-Domain = 0x********
11:16:58 radius,debug received reply for 1b:38 
11:16:58 radius,debug new request 1b:00 code=Accounting-Request service=ppp called-id=0.0.0.0 domain=ad3.felines.org 
11:16:58 radius,debug sending 1b:00 to 192.168.255.8:1813 
11:16:58 radius,debug,packet sending Accounting-Request with id 50 to 192.168.255.8:1813 
11:16:58 radius,debug,packet     Signature = 0x********
11:16:58 radius,debug,packet     Service-Type = 2 
11:16:58 radius,debug,packet     Framed-Protocol = 1 
11:16:58 radius,debug,packet     NAS-Port = 9 
11:16:58 radius,debug,packet     NAS-Port-Type = 0 
11:16:58 radius,debug,packet     User-Name = "user1" 
11:16:58 radius,debug,packet     Calling-Station-Id = "74.130.23.57" 
11:16:58 radius,debug,packet     Called-Station-Id = "0.0.0.0" 
11:16:58 radius,debug,packet     MS-CHAP-Domain = "ad3.felines.org" 
11:16:58 radius,debug,packet     Class = 0x********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet       ********
11:16:58 radius,debug,packet     Acct-Session-Id = "********" 
11:16:58 radius,debug,packet     Framed-IP-Address = 192.168.255.32 
11:16:58 radius,debug,packet     Acct-Authentic = 1 
11:16:58 radius,debug,packet     Event-Timestamp = 1484561818 
11:16:58 radius,debug,packet     Acct-Status-Type = 1 
11:16:58 radius,debug,packet     NAS-Identifier = "MikroTik1" 
11:16:58 radius,debug,packet     Acct-Delay-Time = 0 
11:16:58 radius,debug,packet     MT-Realm = 0x********
11:16:58 radius,debug,packet     NAS-IP-Address = 192.168.255.3 
11:16:58 radius,debug,packet received Accounting-Response with id 50 from 192.168.255.8:1813 
11:16:58 radius,debug,packet     Signature = 0x********
11:16:58 radius,debug received reply for 1b:00 
11:16:58 radius,debug request 1b:00 processed 
11:16:58 sstp,ppp,info,account user1 logged in, 192.168.255.32 
11:16:58 sstp,ppp,info SSTP1: authenticated 
11:16:59 sstp,ppp,info SSTP1: connected

I just cannot figure out where that Framed-IP-Address = 192.168.255.32 is coming from.

Help much appreciated.

thanks!
-Jay

libove · Thu Mar 09, 2017 8:18 am

Right, so this is weird.
On one Windows 10 VPN client it works. The client gets an IP address from the VPNpool1 statically configured VPN IP address range on the Mikrotik.
On another Windows 10 VPN client, it still fails as before. The client is getting that 192.168.255.32 address which mysteriously doesn't appear in the logs or active configuration report of the one DHCP server on the network (the Windows Server).
I don't like mysteries

Well, sh*t.
I looked in the Active Directory Users and Computers applet on the Windows Server to view the Attributes of the user of the Windows 10 VPN client which was mysteriously getting this not-configured-in-any-DHCP-server IP address, and I found two Attributes of interest:
msRADIUSFramedIPAddress
msRASSavedFramedIPAddress

One of these is described in:
https://msdn.microsoft.com/en-us/librar ... 2147217396
.. as "used internally. Do not edit".

I cleared both of these, and lo and behold the NPS is no longer shoving this incorrect IP address down the VPN client's throat.

My theory is that earlier in testing I may have assigned a remote IP address as a user Attribute for this Windows Domain user, and even though I long ago removed that from the user's profile (in the Dial-In tab of AD Users and Computers for that user) it stuck in the Windows Domain Server (NPS, RADIUS server)'s memory in this obscure Attribute.

So I think my configuration is working now.

We'll see if it stays working!

MikroTik as RADIUS client to Windows NPS, Framed-Pool not being respected/ where are DHCP responses coming from??

MikroTik as RADIUS client to Windows NPS, Framed-Pool not being respected/ where are DHCP responses coming from??

Re: MikroTik as RADIUS client to Windows NPS, Framed-Pool not being respected/ where are DHCP responses coming from??