PDF(10.0 KB) View with Adobe Reader on a variety of devices
ePub(73.6 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(77.4 KB) View on Kindle device or Kindle app on multiple devices
Updated:April 25, 2017
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This documents describes the expected results of configuring corporate L2TP APNs with the authentication imsi-auth or authentication msisdn-auth.
Problem: The msisdn-auth and imsi-auth APN Configuration Options have a Speciffic (non obvious) Result for L2TP based APNs
The official documentation (for release 19) states:
imsi-auth - Configures the APN to attempt to authenticate the subscriber based on their International Mobile Subscriber Identification (IMSI) number.
msisdn-auth - Configures the APN to attempt to authenticate the subscriber based on their Mobile Station International Integrated Services Digital Network (MSISDN) number as described in the Usage section of this command.
apn ecs-apn ims-auth-service IMSA dns primary 192.168.1.128 dns secondary 192.168.1.129 ip access-group CSS_ACL in ip access-group CSS_ACL out authentication imsi-auth username-strip-apn prefer-chap-pco <<<<<<<<<<<<<<<<<<<<<<<<<<< ip context-name Gi tunnel l2tp peer-address 184.108.40.206 encrypted secret +A3oxne9nnyqmuz16dddqucwcqz92p2hi4t8z21nx3hmmpcgvh4ida preference 1 <<<<<<<<<<<<<<<<<<<<<<<<<<< tunnel l2tp peer-address 220.127.116.11 encrypted secret +A2dbz9joxajmv80jxmr5aycl1ka2s6nzmu7s2bte3nnz4o2hgkqxn preference 2 <<<<<<<<<<<<<<<<<<<<<<<<<<< loadbalance-tunnel-peers prioritized <<<<<<<<<<<<<<<<<<<<<<<<<<< exit
Friday April 07 2017 <<<<OUTBOUND 09:57:08:295 Eventid:25001(0) PPP Tx PDU (20) PAP 20: Auth-Req(1), Name=421917667546, Passwd=<-- username is replaced with MSISDN as the APN is configured with “msisdn-auth”
The option doesn’t work if there is a username provided by UE. In this case, GGSN/PGW sends the username and password configured inside the APN. If nothing is configured there
Friday April 07 2017 INBOUND>>>>> 09:47:51:254 Eventid:141004(3) [PGW-S5/S2a/S2b]GTPv2C Rx PDU, from 18.104.22.168:35824 to 22.214.171.124:2123 (279) TEID: 0x00000000, Message type: EGTP_CREATE_SESSION_REQUEST (0x20) Sequence Number: 0x5C4D6C (6049132) GTP HEADER Version number: 2 TEID flag: Present Piggybacking flag: Not present Message Length: 0x0113 (275)
INFORMATION ELEMENTS IMSI: Type: 1 Length: 8 Inst: 0 Value: 231014450903030 Hex: 0100 0800 3201 4154 9030 30F0
Friday April 07 2017 <<<<OUTBOUND 09:47:51:334 Eventid:25001(0) PPP Tx PDU (16) PAP 16: Auth-Req(1), Name=null, Passwd=null <-- username is the same as in the APN
Observed behavior is expected as per design.
The authentication imsi-auth username-strip-apn prefer-chap-pco (or authentication msisdn-auth username-strip-apn prefer-chap-pco) configuration is used when there is no Protocol Configuration Options (PCO) username coming in.
This is the order of precedence for Network Access Identifier (NAI) construction configuration:
If outbound username <1-128 char string> is configured inside the APN, this overrides all other configurations/IEs and is sent in PAP/CHAP req.
If UE sends PCO username/password it is sent from the UE, it is sent to LNS in Password Authentication Protocol/Challenge Handshake Authentication Protocol (PAP/CHAP) req.
If no username is sent from UE, then msisdn/imsi@APN is sent by default as username in PAP/CHAP req.
Further this CLI - authentication msisdn/imsi-auth username-strip-apn can be used to strip the APN and send only the msisdn/imsi in PAP/CHAP req.
Note that in case the authentication is done by Radius (localy) the IMSI (or MSISDN) are sent in Access-Request messages as expected.
As well in scenario of L2TP, if authentication is done by RADIUS (on LAC side), the expected username (IMSI or MSISDN) is seen in Access-Request messages, but not in Auth-Req towards LNS.