• Trainer Sagar Dhawan
• Posted on September 5, 2025
• No Comments

[Day 132] Cisco ISE Mastery Training: SMS Gateway & OTP Authentication

---

Introduction

Imagine a visitor at Reception: instead of the receptionist reading out credentials, the visitor enters their mobile number and instantly receives a one-time code on their phone — quick, frictionless, and auditable. SMS OTP is the simplest multi-factor flow for guest access: low barrier for users, high adoption rate, and works on any phone.

In Cisco ISE environments SMS/OTP is used for:

• Guest self-registration and sponsor approval (send OTP or credentials by SMS).
• OTP as a second factor for employee VPN or web-auth flows.
• Temporary device onboarding where email is not available.

Today we build a secure, production-grade SMS gateway integration and OTP flow — covering provider selection, ISE configuration, guest portal changes, API examples, and all the validation you need to teach this live.

---

Problem Statement

Real challenges this solves:

• Guests frequently have no corporate email; SMS is universal.
• Manual distribution of credentials is error prone and unscalable.
• Delivering an OTP securely and reliably across carriers and countries is tricky: rate limits, sender ID restrictions, international formats and delivery latency matter.
• Administrators must be able to test, validate and troubleshoot deliveries quickly.

We’ll design a flow that is scalable, auditable, secure, and resilient to deliverability problems.

---

Solution Overview

High level flow options (we’ll implement the common, recommended pattern):

1. ISE native guest flow + SMS gateway: Guest enters phone number on ISE portal → ISE generates OTP or password → ISE calls configured SMS gateway (HTTP POST or SMTP-to-SMS) with a templated message including the OTP → the guest receives code and uses it to login.
2. External portal + call ISE ERS API: External cloud portal collects phone → calls ISE ERS to create a guest and then uses an external SMS provider (e.g., Twilio) to send the generated credentials. Use when you want more UI/analytics control.
3. OTP for VPN/mfa: Use SMS OTP as a step in the authentication flow (e.g., RADIUS proxying to an MFA system) or use a custom workflow where the VPN API calls a backend that sends an OTP and validates it before granting RADIUS success.

Security controls:

• Use HTTPS (TLS) to call SMS APIs; store API keys in secure vaults; restrict API calls to minimal scopes; rate-limit OTP attempts; apply brute-force protections (lockouts) and logging.

---

Sample Lab Topology

Platform: VMware or EVE-NG for ISE + lab hosts; SMS provider is external (public cloud).

Components

• ISE (PAN + PSN) — 10.10.10.10 / 10.10.10.11
• Wireless controller or switch (redirects guests)
• Guest client (phone/browser)
• Lab automation host (Ubuntu) to simulate SMS gateway or to run curl tests — 10.10.99.50
• Public SMS provider (e.g., Twilio) OR a mock HTTP SMS gateway hosted on lab host (for offline lab)

Topology:

Notes

• For production, place ISE PSN and SMS provider calls over HTTPS; if using a cloud portal, secure with VPN or private link where possible.

---

Step-by-Step GUI Configuration Guide (steps with screenshot placeholders + CLI / curl)

Pattern A — Configure SMS Gateway inside ISE (HTTP or SMTP)

Pre-reqs: ISE Admin account, portal created (Guest Self-Reg), and admin access to SMS provider credentials or an SMTP relay.

A.1 — Add SMS Gateway (GUI)

1. Login to ISE (admin).
2. Go to Administration > System > Settings > SMS Gateway.
   • [Screenshot: ISE Administration > System > Settings > SMS Gateway]

1. Click Add → Select gateway type:
   • SMTP (email-to-SMS): configure mail server, from address and To templates (e.g., +<phone>@txt.att.net) — useful in labs but fragile in multi-carrier production.

1. HTTP/REST: configure POST URL (https://api.example.com/sms), HTTP Method (POST), authentication (Basic / Bearer token), and request template (body and headers).
2. Example HTTP request template (JSON):

{
  "to": "${phone_number}",
  "body": "Your MyCorp guest code is: ${guest_password}. Valid for ${valid_minutes} minutes."
}

5. Add any required headers (e.g., Authorization: Bearer <API_KEY>, Content-Type: application/json). Save.

Validation: Click Test SMS (if available) to send a test message; check provider logs.

A.2 — Map SMS template to Guest Portal

1. Work Centers > Guest Access > Portals & Components > Guest Portals. Edit the guest portal (Self-Reg).
2. Under Portal Configuration or Notifications, find SMS templates or Notifications and select the configured SMS gateway and the SMS text template. Use variables: ${guest_password}, ${ui_user_name}, ${ui_time_left} etc.
   • [Screenshot: Guest Portals > SMS template binding]

Validation: Create a test guest in the ISE GUI and select Send SMS. Look in Work Centers > Guest Access > Monitor for guest record and send status.

A.3 — Test full flow

1. From a test client, connect to Guest SSID and open browser → redirected to ISE Portal.
2. Self-register and enter cell phone number in form.
3. ISE creates guest account and sends SMS via configured gateway.
4. Guest receives OTP/password, logs in, and ISE authorizes session.

ISE Live Logs (validation):

• Operations > RADIUS > Live Logs — look for Access-Request/Accept and portal actions.
• Work Centers > Guest Access > Monitor — check guest status and SMS send logs.

---

Pattern B — External SMS Provider (Twilio example) — recommended for production

Use an external provider and either let ISE call it (via HTTP gateway) or call it from your cloud portal. Below shows a simple direct call from a backend and sample cURL for Twilio.

B.1 — Generate credentials in ISE & get the OTP value

When ISE creates a guest (self-reg), it either generates password or you can create a random OTP server-side (if using an external portal). If using ISE native portal, use the substitution variable ${guest_password} in SMS template.

B.2 — Twilio example (send SMS via REST) — sample cURL

# Replace placeholders
ACCOUNT_SID="ACxxxxxxxxxxxxxxxxxxxx"
AUTH_TOKEN="your_auth_token"
FROM="+15551234567"    # Twilio number
TO="+447700900000"     # international format
MSG="Your MyCorp guest code is 123456 (valid 60 min)."

curl -s -X POST "https://api.twilio.com/2010-04-01/Accounts/${ACCOUNT_SID}/Messages.json" \
--data-urlencode "To=${TO}" \
--data-urlencode "From=${FROM}" \
--data-urlencode "Body=${MSG}" \
-u "${ACCOUNT_SID}:${AUTH_TOKEN}"

Notes: In production, use server side code (Node/Python/Java) and never embed API keys in client code.

B.3 — ISE → External portal → Twilio flow (recommended)

1. Guest portal (cloud) collects phone.
2. Portal calls ISE ERS API to create guest (guest password generated).
3. Portal calls Twilio API to send SMS using guest_password from ERS response.
4. Guest uses password to authenticate to ISE.

Sample ERS create guest (cURL, simplified):

curl -k -u ers_admin:ERS_PASS \
-H "Content-Type: application/json" \
-X POST https://10.10.10.11:9060/ers/config/guestuser \
-d '{
 "GuestUser": {
  "name": "visitor_jdoe",
  "guestInfo": {"emailAddress":"", "phoneNumber":"+447700900000"},
  "guestAccessInfo":{"validDays":1}
 }
}'

Use the returned GuestUser object to read the generated password and send via Twilio.

Validation: Check Twilio message log, ISE guest record (Monitor), and have a test device authenticate using password.

---

Troubleshooting & Diagnostics

1 — SMS not delivered (no message received)

• Check provider logs (Twilio console or SMS gateway logs). Look for HTTP 200/201 response or error codes (rate limit, unauthorized, invalid number).
• Check ISE Live Logs: Work Centers > Guest Access > Monitor — find guest and look for SMS send status.
• Test API from ISE/automation host:

curl -vk --data-urlencode "To=${TO}" ... -u "${SID}:${TOKEN}" "https://api.twilio.com/2010-04-01/Accounts/${SID}/Messages.json"

• Carrier issues: some countries restrict sender IDs. Test with a local number or contact provider.

---

2 — ISE “Test SMS” fails

• Validate DNS and TLS from PSN: curl -v https://api.twilio.com/ from an ISE shell (lab only — ISE shell access might be limited). If not possible, run curl from lab host that simulates ISE network.
• Confirm firewall permits outbound TCP 443 to provider IPs. Packet capture: tcpdump -i eth0 host api.twilio.com and tcp port 443.

---

3 — Wrong phone number format → rejected

• Use E.164 format: +<CountryCode><Number> (e.g., +447700900000). Validate input sanitization on portal form. Provide client-side & server-side normalization.

---

4 — OTP brute-force or replay

• Implement back-off and lockouts on the portal or ISE workflow — limit attempts per guest username or per phone number. Log attempts. Use short OTP validity (2–10 min) depending on security needs.

---

5 — Delayed SMS delivery

• Check provider for queued deliveries or carrier delays. Avoid long OTP windows – balance UX vs security. Implement fallback: offer Voice OTP (call) as secondary channel.

---

6 — Rate limiting & quotas

• Providers throttle messages per second/day. For events (conference) pre-warm quota, scale provider or shard across multiple numbers/providers.

---

7 — Debugging tools & commands

• ISE GUI: Work Centers → Guest Access → Monitor (guest send status). Operations → Live Logs for portal auth events.
• Network: curl -vk to provider endpoint.
• Capture: sudo tcpdump -i eth0 tcp and host api.twilio.com -w sms_api.pcap
• Provider: check message SID, status (queued, sent, delivered, failed).

---

Lab Walkthroughs with Validation (2 scenarios)

Lab 1 — ISE native portal + HTTP SMS gateway (mock) — full test

Goal: Use a mock HTTP SMS endpoint running on lab host to observe ISE calling it.

Setup

• Run a simple HTTP server on lab host that logs POST bodies:

# quick mock server using netcat (example)
while true; do nc -l 8080 > last_request.txt; done

(Use Python Flask for realistic JSON parsing in a real lab.)

Steps

1. Configure ISE SMS Gateway → HTTP → http://10.10.99.50:8080/sms with template using ${guest_password}.
2. Create a Self-Reg portal that requests phone number and configures SMS send on success.
3. From a test client, self-register with phone +1555... — ISE will POST to mock server.
4. Check last_request.txt for JSON with phone & message. Validate that guest_password appears.
5. Use guest_password to log in and verify ISE authorizes session.

Validation: ISE guest monitor shows SMS sent; mock server record contains message; client can authenticate.

---

Lab 2 — External portal + Twilio + ERS flow

Goal: External portal calls ISE ERS to create guest and uses Twilio to send OTP.

Steps

1. Build a small Node/Python script that: (a) posts to ISE ERS create guest, (b) receives guest password from response, (c) calls Twilio API to send SMS.
2. Run script with test phone.
3. Verify Twilio logs and ISE Guest Monitor.
4. Use guest password to authenticate.

Validation: Twilio returns message SID and status; ISE guest entry has status: Active after login; Live Logs show Access-Accept.

---

Expert Level Use Cases (step-by-step mapping + validation)

Use Case 1 — High-volume event registration (conference)

1. Pre-register bulk guests via ERS API (CSV import). Use Twilio Notify or pooled numbers to manage throughput.
2. Send OTP or credentials via SMS in batches with retry logic for failures.
3. Validate: sample 1,000 sends in lab; monitor provider API rate limits and ISE PSN load.

Validation: Twilio status callbacks, ISE guest monitor, and sampling delivery confirmation.

---

Use Case 2 — Two-step employee VPN login (RADIUS + SMS OTP)

1. User authenticates to VPN (RADIUS) → initial acceptance with Challenge response requiring OTP.
2. Backend (or ISE in custom flow) sends SMS OTP, user responds with OTP, then RADIUS Access-Accept is issued.
3. Validate with VPN client and RADIUS logs; ensure OTP validated and timing enforced.

---

Use Case 3 — Recovery & notification on suspicious login

1. If ISE posture or external detection flags suspicious activity, automatically trigger an SMS alert (not OTP) to endpoint owner telling them to reauthorize or contact SOC.
2. Automate via ISE event -> SOAR or script -> call SMS API.

Validation: Confirm event triggers, SMS dispatch logs, and user acknowledgement.

---

FAQs

Q1 — What SMS gateway types does ISE support?

A: ISE supports HTTP/REST gateway integrations (custom POST templates) and SMTP (email-to-SMS) methods. HTTP/REST is preferred for reliability, tracking, and international support.

---

Q2 — How do I format phone numbers to maximize deliverability?

A: Use E.164 format: +<CountryCode><Number> (e.g., +447700900000). Normalize inputs on the portal (client + server side) and validate with regex before sending.

---

Q3 — Should I use SMTP-to-SMS in production?

A: No (not recommended). SMTP-to-SMS is carrier dependent, fragile, and has deliverability problems. Use a reputable SMS API provider (Twilio, Nexmo/Vonage, MessageBird, etc.) for production.

---

Q4 — How do I handle rate limits during a conference/event?

A: Pre-book capacity with the provider, use multiple sender numbers/short codes if necessary, stagger sends, and implement retries with exponential backoff. Always test at scale ahead of the event.

---

Q5 — Where do I store provider API keys securely?

A: Do not hardcode in scripts. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) or a secure server env variable with restricted access. Rotate keys regularly.

---

Q6 — How long should an OTP be valid?

A: Typical window: 2–10 minutes. Shorter is more secure but increases support calls. For guest access, 10 minutes is commonly used; for sensitive actions pick 2–5 minutes.

---

Q7 — How does ISE generate the OTP/password?

A: ISE can auto-generate guest credentials when creating a guest account. For custom OTP flows (external portal), generate a cryptographically secure random code server-side; store it pending validation for its TTL.

---

Q8 — How do I guard against SMS interception or SIM swap?

A: SMS is not cryptographically secure. For high-security use cases prefer TOTP apps or push notifications. Mitigate risks with device binding, small OTP windows, and secondary confirmation for risky actions.

---

Q9 — Where do I look in ISE when SMS fails?

A: Work Centers > Guest Access > Monitor for guest send status and timestamps; Operations > Live Logs for portal session traces. Use provider dashboards for delivery errors.

---

Q10 — How to test SMS in a lab if no public internet?

A: Use a local mock HTTP service that logs requests (Flask) or a local SMPP simulator. This lets students see payloads and debug formatting without sending real SMS.

---

YouTube Link

For more in-depth Cisco ISE Mastery Training, subscribe to my YouTube channel Network Journey and join my instructor-led classes for hands-on, real-world ISE experience

---

Closing Notes (key takeaways)

• SMS OTP is a high-utility, low-friction method for guest authentication — easy to deploy but requires attention to deliverability, formatting, rate limits and security trade-offs.
• Prefer HTTP/REST SMS providers over SMTP-to-SMS for production. Use secure storage for API keys and monitor provider delivery logs.
• Always validate with three views: ISE Live Logs (guest creation), network (tcpdump/curl), and provider dashboard (message SID/status).
• For high-risk MFA, consider stronger factors (TOTP, push, hardware tokens) over SMS.

---

Upgrade Your Skills — Start Today

For more in-depth Cisco ISE Mastery Training, subscribe to Network Journey on YouTube and join my instructor-led 4-month Fast-Track to Cisco ISE Mastery Pro — hands-on labs, runbooks and 1:1 lab reviews: https://course.networkjourney.com/ccie-security/

Enroll Now & Future‑Proof Your Career
Email: info@networkjourney.com
WhatsApp / Call: +91 97395 21088

---