Project

General

Profile

Bug #1199

virtual ip assignment sequence when use %radius

Added by richard hu over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
10.11.2015
Due date:
Estimated time:
Affected version:
5.3.3
Resolution:
Fixed

Description

when use ikev2 and eap-radius, set rightsourceip=%radius,172.16.0.0/16
found strongswan will use 172.16.0.x although radius response a valid Framed-IP-Address
if set rightsourceip=%radius, then strongswan can get radius response ip.
is this by design? I think radius should be first because it write in front of 172.16

Associated revisions

Revision fdfbd401 (diff)
Added by Tobias Brunner over 4 years ago

eap-radius: Compare address family when handing out virtual IPs

This also ensures that the actually released virtual IP is removed from
the list of claimed IPs.

Fixes #1199.

History

#1 Updated by richard hu over 4 years ago

log shows assign two ip, but finally client use 172.16.x.x
Nov 10 07:07:41 07[CFG] <IOS8_IKEV2i_MSCHAP|2> reassigning offline lease to 'aaa'
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> assigning virtual IP 172.16.0.1 to peer 'aaa'
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> peer requested virtual IP %any6
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> assigning virtual IP 172.26.11.20 to peer 'aaa'
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> building INTERNAL_IP4_DNS attribute
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> building INTERNAL_IP4_NETMASK attribute
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> CHILD_SA IOS8_IKEV2i_MSCHAP{2} established with SPIs c30b630f_i 0a5413bf_o and TS 0.0.0.0/0 === 172.16.0.1/32 172.26.11.20/32

#2 Updated by Tobias Brunner over 4 years ago

  • Status changed from New to Feedback

There is definitely a problem with the address assignment in the RADIUS plugin as there is no comparison of the IP address family. So this should never happen:

Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> peer requested virtual IP %any6
Nov 10 07:07:41 07[IKE] <IOS8_IKEV2i_MSCHAP|2> assigning virtual IP 172.26.11.20 to peer 'aaa'

I pushed a fix for this to the 1199-radius-vip-family branch.

I think radius should be first because it write in front of 172.16

That depends on the order in which attribute providers register themselves, basically the plugin load order. If the stroke plugin (which provides the in-memory pools defined in ipsec.conf) is loaded before the eap-radius plugin it will be queried first for a virtual IP. The order within the rightsourceip option is irrelevant (unless you define multiple in-memory pools). I've added a note to VirtualIP.

#3 Updated by richard hu over 4 years ago

Tobias Brunner wrote:
If I want get %radius ip first, I need apply the fix and change plugin order?

There is definitely a problem with the address assignment in the RADIUS plugin as there is no comparison of the IP address family. So this should never happen:

[...]

I pushed a fix for this to the 1199-radius-vip-family branch.

I think radius should be first because it write in front of 172.16

That depends on the order in which attribute providers register themselves, basically the plugin load order. If the stroke plugin (which provides the in-memory pools defined in ipsec.conf) is loaded before the eap-radius plugin it will be queried first for a virtual IP. The order within the rightsourceip option is irrelevant (unless you define multiple in-memory pools). I've added a note to VirtualIP.

#4 Updated by Tobias Brunner over 4 years ago

If I want get %radius ip first, I need apply the fix and change plugin order?

Just change the plugin order. As long as the client requests an IPv4 address first that should work fine without the patch.

#5 Updated by richard hu over 4 years ago

Tobias Brunner wrote:

If I want get %radius ip first, I need apply the fix and change plugin order?

Just change the plugin order. As long as the client requests an IPv4 address first that should work fine without the patch.

then what the patch fixed?

#6 Updated by Tobias Brunner over 4 years ago

  • Tracker changed from Issue to Bug
  • Category set to libcharon
  • Target version set to 5.3.4
  • Resolution set to Fixed

Just change the plugin order. As long as the client requests an IPv4 address first that should work fine without the patch.

then what the patch fixed?

It prevents the eap-radius plugin from handing out IPv4 addresses if the client requested an IPv6 address and vice versa (as can be seen in your log). If you only assign one Framed-IP-Address attribute, let the eap-radius assign IPs first (by changing the plugin order) and the client sends the IPv4 attribute request first then the current code does not cause problems.

#7 Updated by Tobias Brunner over 4 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF