Framed-IP-Address not sent to ASA/NAS in proxy mode
Hi Setup: Cisco ASA (NAS) -> FRAD -> MS-NPS -> Active Directory I having some issues with one aspect of this setup. I am trying to make the Framed-IP-Address received back from the NPS be forwarded back to the ASA in the same Access-Accept packet as the Class value (Group Policy name) is being sent. Based on the debug below, we see that the static IP defined in a users object is returned to FR, but it is not being taken into account and added to the next part. If I remove the static IP from the Active Directory user object, the Framed-IP-Address is not returned to the FR by the NPS as expected. If i define in sites-enabled/default update reply { Framed-IP-Address = "10.42.7.150" } the Access-Accept packet is updated and the ASA hands out the IP to the VPN client. I also tried to define a update reply like this without success: update reply { Framed-IP-Address = "%{ Framed-IP-Address }" } No matter in what section I placed this in the sites-enabled/default file, it had a null value and returned the error: "ERROR: Failed parsing value "" for attribute Framed-IP-Address: Failed to find IP address for". I know too little about running querys / variables like this, so I'm clueless. The the other aspect, the dynamic ip pool which is setup on the ASA, works as a fallback when the Framed-IP-Address is not sent in the Access-Accept packet. In other words, this works as expected and is OK. I've spent good few days (read weeks) trying to find the solution myself, with several clean setups, but I simply can't get it to work. I hope some of you have done this and know what my issue might be with my configuration. I've touched very little of the default config, apart from adding the config below. There has been no change to any dictionary files either. Thank you very much in advance Regards Aleksander =============== freeradius -v freeradius: FreeRADIUS Version 2.1.12, for host x86_64-pc-linux-gnu, built on Dec 16 2012 at 13:28:43 =============== freeradius/proxy.conf =============== home_server domain.dco1 { type = auth ipaddr = 192.168.1.10 port = 1812 secret = pass require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 } home_server_pool domain_pool { type = fail-over home_server = domain.dco1 } realm "domain.com" { strip auth_pool = domain_pool # acct_pool = LOCAL } =============== freeradius/users: default config =============== freeradius/sites-enabled/default: Uncommented attr_filter.post-proxy in the post-proxy section to get freeradius/attrs to work. =============== freeradius/attrs: =============== domain.com Class := "ou=domain.com-GP" DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, Login-Service == Rlogin, Login-Service == TCP-Clear, Login-TCP-Port <= 65536, Framed-IP-Address == 255.255.255.254, Framed-IP-Netmask == 255.255.255.255, Framed-Protocol == PPP, Framed-Protocol == SLIP, Framed-Compression == Van-Jacobson-TCP-IP, Framed-MTU >= 576, Framed-Filter-ID =* ANY, Reply-Message =* ANY, Proxy-State =* ANY, EAP-Message =* ANY, Message-Authenticator =* ANY, MS-MPPE-Recv-Key =* ANY, MS-MPPE-Send-Key =* ANY, MS-CHAP-MPPE-Keys =* ANY, State =* ANY, Session-Timeout <= 28800, Idle-Timeout <= 600, Port-Limit <= 2 =============== DEBUG ON CONN (let me know if this output doesn't cover the needed insight) =============== 3.3.3.3 = ASA 192.168.1.10 = NPS [.....] WARNING: Empty pre-proxy section. Using default return values. Sending Access-Request of id 74 to 192.168.1.10 port 1812 User-Name = "test" User-Password = "test" NAS-Port = 200704 Called-Station-Id = "1.1.1.1" Calling-Station-Id = "2.2.2.2" NAS-Port-Type = Virtual Tunnel-Client-Endpoint:0 = "2.2.2.2" NAS-IP-Address = 3.3.3.3 Cisco-AVPair = "ip:source-ip=2.2.2.2" Vendor-3076-Attr-146 = 0x44656661756c7457454256504e47726f7570 Vendor-3076-Attr-150 = 0x00000002 Proxy-State = 0x3534 Proxying request 0 to home server 192.168.1.10 port 1812 Sending Access-Request of id 74 to 192.168.1.10 port 1812 User-Name = "test" User-Password = "test" NAS-Port = 200704 Called-Station-Id = "1.1.1.1" Calling-Station-Id = "2.2.2.2" NAS-Port-Type = Virtual Tunnel-Client-Endpoint:0 = "2.2.2.2" NAS-IP-Address = 3.3.3.3 Cisco-AVPair = "ip:source-ip=2.2.2.2" Vendor-3076-Attr-146 = 0x44656661756c7457454256504e47726f7570 Vendor-3076-Attr-150 = 0x00000002 Proxy-State = 0x3534 Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Accept packet from host 192.168.1.10 port 1812, id=74, length=88 Proxy-State = 0x3534 Framed-Protocol = PPP Service-Type = Framed-User Framed-IP-Address = 10.42.7.150 Class = 0xacf7099d0000013700010200ac12e01a0000000058e653601a8d0a8101cf70306d8babb900000000000000bc # Executing section post-proxy from file /etc/freeradius/sites-enabled/default +- entering group post-proxy {...} [attr_filter.post-proxy] expand: %{Realm} -> domain.com attr_filter: Matched entry domain.com at line 103 ++[attr_filter.post-proxy] returns updated [eap] No pre-existing handler found ++[eap] returns noop Found Auth-Type = Accept Auth-Type = Accept, accepting the user # Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 54 to 3.3.3.3 port 48206 Class := 0x6f753d566f6963652e6e6f2d4755 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 54 with timestamp +18 Ready to process requests.
On 22/05/14 13:21, Aleksander Roer Olsen wrote:
I also tried to define a update reply like this without success: update reply { Framed-IP-Address = "%{ Framed-IP-Address }" }
That's bad syntax. See "man unlang" Anyway, your problem is almost certain this: [attr_filter.post-proxy] expand: %{Realm} -> domain.com attr_filter: Matched entry domain.com at line 103 You have an attribute filter defined. Ensure Framed-IP-Address is in there.
Thank you Phil. I changed it to this and it works like I hoped. If this what you would recommend I don't know, but I suppose it's OK. freeradius/attrs: [...] domain.com Class := "ou=domain.com-GP", Framed-IP-Address =* ANY, Framed-IP-Netmask = 255.255.255.0 [...] Sending Access-Accept of id 78 to xx.xx.xx.xx port 48206 Class := 0x6f753d566f6963632e6e6f2d4752 Framed-IP-Netmask := 255.255.255.0 Framed-IP-Address = 10.42.7.150 Thank you very very much :-) On Thu, May 22, 2014 at 2:46 PM, Phil Mayers <p.mayers@imperial.ac.uk>wrote:
On 22/05/14 13:21, Aleksander Roer Olsen wrote:
I also tried to define a update reply like this without success: update
reply { Framed-IP-Address = "%{ Framed-IP-Address }" }
That's bad syntax. See "man unlang"
Anyway, your problem is almost certain this:
[attr_filter.post-proxy] expand: %{Realm} -> domain.com attr_filter: Matched entry domain.com at line 103
You have an attribute filter defined. Ensure Framed-IP-Address is in there. - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Hello, Is it possible in unlang to copy the value of a "string" attribute into an "octets" attribute, without escaping taking effect ? I'm doing something like : update control { Attr-Octets = "%{control:Attr-String}" } Attr-String start with a 0x01 (escaped to \001). -> Attr-Octets gets "0x5c303031..." (instead of what I would like: "0x01...") Is there a way to force the assignement without the string being escaped ? This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 22/05/14 17:19, Chaigneau, Nicolas wrote:
Attr-String start with a 0x01 (escaped to \001). -> Attr-Octets gets "0x5c303031..." (instead of what I would like: "0x01...")
Is there a way to force the assignement without the string being escaped ?
In 3.x yes: Attr-Octets = &control:Attr-String ...and maybe the <cast> stuff (haven't looked at it). Not sure in older versions - there might be some kind of unlang xlat magic voodoo you can do, but I don't think so, it'll be the pairparsevalue() that is doing the interpretation.
Phil Mayers wrote:
In 3.x yes:
Attr-Octets = &control:Attr-String
...and maybe the <cast> stuff (haven't looked at it).
The <cast> is only for "if" conditions. It isn't needed anywhere else.
Not sure in older versions - there might be some kind of unlang xlat magic voodoo you can do, but I don't think so, it'll be the pairparsevalue() that is doing the interpretation.
It's almost impossible in older versions. Alan DeKok.
participants (4)
-
Alan DeKok -
Aleksander Roer Olsen -
Chaigneau, Nicolas -
Phil Mayers