Ticket#25: Server Reachable via Ping but Not SSH – TCP MSS Clamp Missing on Firewall [CCNP Enterprise]

Problem Summary

A remote branch server (e.g., 10.1.20.10) was reachable via ping, but users could not SSH or access HTTPS applications hosted on it. The server was behind a firewall that performed NAT and IPSec VPN termination.

• Ping: Success
• SSH / HTTPS: Timeout or session hangs
• Affected: All clients coming over site-to-site VPN or MPLS links
• Direct LAN access: Works fine from within the same subnet

---

Symptoms Observed

• Ping (ICMP) to server succeeds from remote sites
• SSH (TCP/22) and HTTPS (TCP/443) hang or drop
• Packet capture shows TCP SYN sent → SYN-ACK received → ACK sent → No further response
• No logs on server indicating dropped SSH attempts
• Wireshark shows “TCP Retransmission”, “TCP Window Full,” or fragmented packets
• Jumbo frames disabled on intermediate links

---

Root Cause Analysis

On closer inspection, the following factors were discovered:

• The server has a default MSS of 1460 bytes.
• The IPSec VPN overhead introduced packet fragmentation (adding headers reduces usable MTU).
• ICMP is not affected because it’s smaller and not session-based.
• The firewall did not have MSS Clamping enabled, so it didn’t adjust the TCP MSS in the SYN packets during VPN/NAT traversal.
• As a result, TCP sessions broke mid-handshake due to exceeding the Path MTU, and packet drops occurred silently.

Root Cause: TCP MSS Clamping was not configured on the firewall or router doing NAT/VPN, causing MTU mismatch and TCP fragmentation issues.

---

The Fix

Solution: Enable MSS Clamping on VPN/NAT Interface

Cisco IOS Example (Router doing NAT or VPN):

interface Tunnel0
  ip tcp adjust-mss 1350

Or, on physical WAN interface:

interface GigabitEthernet0/0
  ip tcp adjust-mss 1350

Cisco ASA Firewall Example:

policy-map global_policy
  class inspection_default
    set connection advanced-options tcp-options

tcp-map TCP-MSS-CLAMP
  set mss 1350

access-list VPN_ACL extended permit ip any any

class-map VPN_CLASS
  match access-list VPN_ACL

policy-map outside_policy
  class VPN_CLASS
    set connection advanced-options TCP-MSS-CLAMP

Adjust the MSS value to ~1350 to account for IPsec overhead (ESP, GRE, etc.)

---

EVE-NG Lab Topology

• Simulate TCP sessions with and without MSS clamp
• Use tools like iperf, Wireshark, ping -l, and telnet for testing

---

Verification

Commands to Use:

Cisco Router:

show interface Tunnel0 | include MSS

ASA:

show run tcp-map
show conn detail
debug crypto ipsec

Client Side:

telnet 10.1.20.10 22
ssh user@10.1.20.10
curl https://10.1.20.10

Wireshark:

• Look for retransmissions or Fragmentation Needed ICMP messages
• Look at TCP handshake sequence and MSS values in SYN packets

---

Key Takeaways

• Ping success ≠ full connectivity; TCP needs a full 3-way handshake
• MTU mismatch and TCP MSS issues are common with VPN, NAT, and tunnels
• Always configure TCP MSS clamping on interfaces with IPsec/GRE/NAT
• Use ip tcp adjust-mss or ASA tcp-map to avoid silent drops
• TCP clamping is especially critical for mobile VPN clients, cloud tunnels, MPLS links

---

Best Practices / Design Tips

1. Set MSS clamp on all tunnel/NAT interfaces (e.g., 1350–1380)
2. Test with real application traffic, not just pings
3. Prefer ip mtu and ip tcp adjust-mss over increasing MTU if fragmentation occurs
4. Monitor TCP retransmissions with Wireshark and NetFlow
5. Adjust MSS to 20–40 bytes lower than effective MTU
6. Enable ICMP Path MTU Discovery in firewalls and routers
7. Always check MSS values in SYN packets when debugging
8. Document MSS policies in VPN/NAT configuration guidelines
9. Configure default policies in ASA using TCP maps
10. Verify every tunnel-based topology with iperf, curl, and ssh
11. Use ip mtu carefully — not all devices honor it across tunnels

---

FAQs

1. Why does ping work but SSH fails?

Answer: ICMP (ping) uses small packets without session overhead. TCP (SSH) needs full handshakes and larger packets, which break if there’s a MTU or MSS mismatch.

---

2. What is TCP MSS?

Answer: Maximum Segment Size (MSS) defines the largest segment of TCP data that a device is willing to accept, excluding TCP/IP headers.

---

3. Why is MSS clamping required on VPNs?

Answer: VPN headers (IPsec, GRE) reduce the usable MTU. Without MSS adjustment, TCP packets may exceed the MTU and get silently dropped.

---

4. What value should I set for MSS?

Answer: Common safe values:

• IPsec VPN: 1350 bytes
• GRE Tunnel: 1400 bytes
• Generic NAT: 1452 bytes

---

5. How to check MSS value in a TCP SYN packet?

Answer: Use Wireshark → Open SYN packet → Look for Maximum Segment Size under TCP options.

---

6. Will setting MSS fix HTTPS access too?

Answer: Yes. All TCP-based services (SSH, HTTPS, SMB, etc.) benefit from proper MSS adjustment.

---

7. What if I set MSS too low?

Answer: The connection still works but at a slightly reduced efficiency (more overhead). It’s safe but less optimal.

---

8. Does ASA support MSS clamping for remote VPN clients?

Answer: Yes, via tcp-map and applying it under policy-map.

---

9. How is MSS different from MTU?

Answer: MTU is the total frame size, including IP headers. MSS is the TCP payload size, typically MTU – 40 bytes.

---

10. Do I need to configure both MSS and MTU?

Answer: Usually, adjusting MSS is enough. MTU tuning is needed only in complex fragmentation scenarios.

---

11. Can I simulate this in EVE-NG?

Answer: Yes! Use a topology with VPN/NAT, disable MSS clamp, test with SSH or iperf, then re-enable and observe the difference.

---

12. How to confirm MSS clamping is working?

Answer: Check SYN packets from the router — MSS value should reflect the clamp (e.g., 1350 instead of 1460).

---

13. What’s the risk if MSS clamp is missing in production?

Answer: Broken TCP sessions, failed applications (like Citrix, RDP, SSL), and hard-to-diagnose connectivity issues.

---

14. Do cloud VPNs like AWS/GCP require MSS clamp?

Answer: Often yes. They also recommend setting MSS to 1379 or 1380 depending on encryption settings.

---

15. Does IPv6 have similar MSS issues?

Answer: Yes. Although IPv6 does not fragment in transit, MSS clamping is still needed to avoid dropped packets over tunnels.

---

YouTube Link

Watch the Complete CCNP Enterprise: Server Reachable via Ping but Not SSH – TCP MSS Clamp Missing on Firewall Lab Demo & Explanation on our channel:

---

Final Note

Understanding how to differentiate and implement Server Reachable via Ping but Not SSH – TCP MSS Clamp Missing on Firewall is critical for anyone pursuing CCNP Enterprise (ENCOR) certification or working in enterprise network roles. Use this guide in your practice labs, real-world projects, and interviews to show a solid grasp of architectural planning and CLI-level configuration skills.

If you found this article helpful and want to take your skills to the next level, I invite you to join my Instructor-Led Weekend Batch for:

CCNP Enterprise to CCIE Enterprise – Covering ENCOR, ENARSI, SD-WAN, and more!

Get hands-on labs, real-world projects, and industry-grade training that strengthens your Routing & Switching foundations while preparing you for advanced certifications and job roles.

Email: info@networkjourney.com
WhatsApp / Call: +91 97395 21088

Upskill now and future-proof your networking career!

---