Project

General

Profile

Issue #1456

Missing Tunnel-Client-Endpoint & Tunnel-Server-Endpoint AVP in RADIUS Accounting Start/Stop messages

Added by Danny Kulchinsky about 5 years ago. Updated about 5 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.3.5
Resolution:

Description

Hi,

We are implementing strongSwan 5.3.5 with EAP-RADIUS and EAP-AKA Authentication, our AAA server expects to receives Tunnel-Client-Endpoint and Tunnel-Server-Endpoint AVPs in RADIUS Account Start/Stop messages, but strongSwan is not sending them.

These AVPs are defined in RFC 2868 (https://www.ietf.org/rfc/rfc2868.txt), section 3.3 & 3.4

Type
      66 for Tunnel-Client-Endpoint.
Type
      67 for Tunnel-Server-Endpoint.

Network capture between strongSwan and Radius/AAA:

RADIUS Protocol
    Code: Accounting-Request (4)
    Packet identifier: 0x9c (156)
    Length: 195
    Authenticator: 0ccec6ba3dca3338a1cf777fca24a4ef
    [The response to this request is in frame 1841]
    Attribute Value Pairs
        AVP: l=6 t=Acct-Status-Type(40): Start(1)
        AVP: l=14 t=Acct-Session-Id(44): 1456235532-2
        AVP: l=6 t=NAS-Port-Type(61): Virtual(5)
        AVP: l=6 t=Service-Type(6): Framed(2)
        AVP: l=6 t=NAS-Port(5): 2
        AVP: l=14 t=NAS-Port-Id(87): XXXXXXX
        AVP: l=6 t=NAS-IP-Address(4): xxx.xxx.xxx.xxx
        AVP: l=22 t=Called-Station-Id(30): xxx.xxx.xxx.xxx[4500]
        AVP: l=21 t=Calling-Station-Id(31): xxx.xxx.xxx.xxx[4500]
        AVP: l=56 t=User-Name(1): xxxxx@yyyy.com
        AVP: l=6 t=Framed-IP-Address(8): xxx.xxx.xxx.xxx
        AVP: l=12 t=NAS-Identifier(32): strongSwan

History

#1 Updated by Tobias Brunner about 5 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Priority changed from High to Normal

None of the attributes defined in RFC 2868 are currently supported (neither are the Acct-Status-Type values defined in RFC 2867). But as you can see in the capture the Called-Station-Id and Calling-Station-Id attributes probably contain what you want (even though these technically are defined to contain phone numbers). Couldn't you just use these attributes?

#2 Updated by Danny Kulchinsky about 5 years ago

Tobias Brunner wrote:

None of the attributes defined in RFC 2868 are currently supported (neither are the Acct-Status-Type values defined in RFC 2867). But as you can see in the capture the Called-Station-Id and Calling-Station-Id attributes probably contain what you want (even though these technically are defined to contain phone numbers). Couldn't you just use these attributes?

Dear Tobias,

Thank you for your prompt response.

The reason for asking for "Tunnel-*-endpoint" attributes is because we are introducing strongSwan into an existing environment, it needs to coexist with VPN Gateways from a different Vendor and a AAA service that was already developed to extract the IPs from "Tunnel-*-endpoint" attributes.

Changing to a different AVP is possible, but will require development and certification effort.

Is there any plan to introduce support for RFC 2868 ?

Regards,
Danny

#3 Updated by Tobias Brunner about 5 years ago

Is there any plan to introduce support for RFC 2868 ?

Not at the moment.

Also available in: Atom PDF