Static IP-Adress in User is not working with pptp access

Works as designed. -> manual p.248

When you use a radius server then local users cannot be authenticated with PPTP anymore...

Btw. The radius server can pass back parameters like a client ip

Works as designed. -> manual p.248

When you use a radius server then local users cannot be authenticated with PPTP anymore...

Btw. The radius server can pass back parameters like a client ip

Thank you. I´ve configured a static ip-address in the user profile (dialin section) in the active directory and the radius server assigning the address.

All,
I'm trying to do something similar (authenticating via RADIUS on a Windows server), but with the following difference:
Remote Access >> PPTP > Assign IP addresses by DHCP Server

In Active Directory, I've set a static IP address on a particular user's 'Dial-in' properties, but during a connection attempt, ASG's PPTP daemon is logging the fact that the DHCP server (windows server) is simply trying to allocate the next available IP address from its address pool, rather than the user-specific IP address. The connection attempt fails after the PPTP daemon records;
'Peer is not authorized to use remote address 192.168.0.xx'
(this is the DHCP server allocated address).
Is it because of the 'Assign IP address by DHCP Server' setting in Remote ACcess >> PPTP ?
I've tried changing this from 'DHCP Server' to  'IP address pool', but Webadmin just will not allow me to 'apply' the change. I press the 'Apply' button, and nothing happens. If I navigate away from the page, then go back, the setting has returned to the previous 'DHCP Server' state.

(ASG 7.011)

I never tested my configuration with the setting "Assign IP adress by: DHCP Server", but with the IP-Adress-Pool it is working fine and I had no problems to assign the settings in Webadmin.

I´am using the IE 7. Do you have tried another browser ? Your problems looks like a browser problem.

Is your radius configuration working fine ? Do you have configured remote access policies for pptp (Nas-identifier pptp) ?

Hi Sebastian,
In answer to your last question, as far as I can tell, my RADIUS config is working fine, although I have not manually configured any remote access policies. On the remote user's active directory properties, I have simply set the 'remote access permission (dial-in or VPN)' on the 'Dial-in' tab, to 'Allow access'.

Following a fair amount of testing, I've found the following:

If the active directory user's dial-in properties 'Assign a Static IP Address' is NOT set, the remote user is successfully authenticated, a DHCP server assigned IP address is obtained (in accordance with my ASG PPTP config), and the connection is set up successfully.

If the active directory user 'dial-in' properties has a static IP address specified, the connection is terminated before the user is authenticated. The message 'Peer is not authorized to use remote address ' is included in the ASG's PPTP daemon logfile.

However, if the 'Remote Access >> PPTP > Assign ip addresses by' is set to IP address pool (Pool network = VPN Pool (PPTP) ), the remote user is able to establish a PPTP connection, even if the AD dial-in properties specify a static IP address completely outside the range of the ASG VPN Pool. The ASG Pool addresses are ignored, and the user gets the static address.

Any suggestions why the connection success differs between 'DHCP assign IP' and 'IP address Pool' configurations?

I've attached samples of the PPTP daemon logfiles showing a connection attempt under different ASG / Active directory configs.


As for the difficulty in changing the 'Remote Access >> PPTP > Assign ip addresses by' from 'DHCP Server' to 'IP address pool', I've conluded it's an issue with IE7:
Both Firefox 2.0.0.9, and Opera 9.24 seem to be able to apply the change. In IE7, you can change from 'IP address pool' to 'DHCP server', but one the change has been applied, there's no going back, unless you do a factory reset and reconfigure all of ASG, or simply use Firefox/Opera to apply the change. If anyone has had conflicting experiences I'd be interested to know, but I've managed to reproduce this over and over (on both real, and virtual PC's). Until now, I've always used IE7, and I've experienced what appear to be plenty of issues in which the webadmin interface becomes unresponsive. These problems seem to centre largely in and around the packet filter. Using Firefox or Opera, these problems seem to have all but disappeared [:)]

Sebastian, thanks for the suggestion re: browser compatibility. I've been a die-hard IE user, but I may have finally seen the light (problem now is do I prefer Opera or Firefox?)