Cisco router blocking some computers

[kben4cisco]

Have two Cisco C1101-4p routers set for a site-to-site ipsec vpn. There is no nat. The issue is some computers cannot use the resources on the other end. Some have no problem. Some can access some resources. Some cannot access anything. The version of windows does not matter i.e Win2000, Win7, Win8.1, Win10, Win11, and Linux. It appears the router just drops the packets. Tried with firewall off, no difference. There must have been a software update in May because the situation got worse. Some computers that did have access, suddenly did not.

What am I looking for to troubleshoot this issue?

[MHM Cisco World]

First remove 

crypto ipsec df-bit clear

Second under interface 

interface GigabitEthernet0/0/0

Add ip tcs adj mss 1400' friend ipsec header can be up to 70 bytes. So be in safety side put the mss to 1400.

MHM

[Joseph W. Doherty]

---

@MHM Cisco World wrote:

First remove 

crypto ipsec df-bit clear

Well, actually, I would recommend not using the old interface crypto map approach.

However, you're aware of this Cisco statement?

"IPsec prefragmentation for IPsec VPNs functionality depends on the crypto ipsec df-bit configuration of the interface to which the crypto map is applied, and on the incoming packet “do not fragment” (DF) bit state."

Found in "https://www.cisco.com/c/en/us/td/docs/interfaces_modules/shared_port_adapters/configuration/6500series/sipspasw/76cfvpnb.pdf

Personally, haven't dived deeper to see if that matters or not. in this case.  Again, interface cyrpto maps is OLD technology.

---

@MHM Cisco World wrote:

Second under interface 

interface GigabitEthernet0/0/0

Add ip tcs adj mss 1400' friend ipsec header can be up to 70 bytes. So be in safety side put the mss to 1400.

---

Actually, according to this Cisco table (same document as above):

Unsure if above also allows for GRE (another 24 bytes) if you're using GRE/IPSec, but the above has an IPSec combination a tad more than 70 bytes.

But even if 70 bytes, with a MTU of 1500, and usual minimum IP and TCP headers (20 bytes each), your MSS would be 1460.  Subtract 70 bytes, and your MSS would be 1390, not 1400.

Again, Cisco's usual recommendation for encrypted tunnels, using Ethernet, is an IP MTU of 1400 and a MSS of 1360.

This recommendation usually allows for overhead.  However, it doesn't allow for IP or TCP headers much larger than the usual minimum (each, I recall, can be up to 120 bytes), and it doesn't take full advantage of actual larger MTUs.

Understand, adjust IP MTU and using adjust TCP MSS are to optimize performance avoiding fragmentation.  In a properly working network, traffic should still work with fragmentation.

To verify fragmentation works, try pinging with packets larger than MTU.  (BTW, pinging with 64KB packets can help load up a slow link.)

[kben4cisco]

Tried the changes and there appears to be no change in access.

Had run two cisco 881's for about ten years with no issues. Upgraded to the c1101-4p for additional speed with essentially the same configuration, just changed the ipsec encryption from 3des to aes. Have had problems ever since.

I am attaching the latest config.

[Joseph W. Doherty]

"Tried the changes and there appears to be no change in access."

What @MHM Cisco World suggested in his one reply, i.e. the clear DF and use tcp adjust-mss 1400?

Unsure it has anything to do with your problem, but overhead for AES more than for 3DES, see the table I highlighted from @MHM Cisco World referenced link.  So, again, for AES, a 1400 MSS setting might be too large.

I vaguely recall the command "crypto ipsec df-bit clear" was to always allow fragmentation, otherwise the too large packet would be dropped, and an ICMP message sent to sender packet too large.  Besides that, some devices tended to drop some ICMP messages, for "security".  Also, the earlier versions of ICMP too large didn't inform the host what the actual MTU was, so host had to experiment with multiple sizes, to determine what's MTU, or just go very small, like the IP 576 guaranteed size.  (Oh, and host may have something like a timer on reduced sized MTUs, to try larger again, to see if current path now accepts.  [If you see things in Cisco recommended settings, which clearing the DF may have been, there often a reason for it.])

Also, since you upgraded from 3DES to AES, I would also suggest considering upgrading to a VTI tunnel, assuming both sides can support it.  Direct crypto mapped interfaces is pretty old technology.  (I also vaguely recall the earliest versions ran packets, logically, through the crypto interface twice.)

Also, as an aside, much about your posted config attachment, has me somewhat scratching my head for its purpose.

I don't recall seeing a reply to whether a traceroute, to an interface on the other side of router worked.  Was this tried?

[kben4cisco]

Had to undo the changes as computers that could connect suddenly could not. Traceroute works to items I can connect to but fails otherwise. Wireshark shows the packets to non-connecting items are just dropped. Tried different sizes on the tcp adjust-mss combined with ping and specifying packet size; sizes below the setting worked. The clear DF bit is to allow fragmentation of oversized packets but should rarely, if ever, be invoked. I am out of ideas again. I have not worked with a VTI tunnel, so if I try the remote site will be down while I going through my learning curve; last resort. Will try some debug commands to see if any thing shows up. Any suggestions? Thanks

[MHM Cisco World]

please share 
show crypto session detail 

MHM

[kben4cisco]

crypto session

[Joseph W. Doherty]

"The clear DF bit is to allow fragmentation of oversized packets but should rarely, if ever, be invoked."

Actually, often not that rare, unless host PMTUD is NOT enabled.  This because, protocols like TCP (used by many network apps) will try to fill a packet to MTU, and if MTU is reduced, like by crypto, packet will be oversized and will need to be fragmented.

Back to traceroute, again, what I'm looking for is, from both good and bad hosts, on your LAN network (192.168.200.0/24) what happens if they ping and/or traceroute that router's WAN interface IP ("ip address xxxxxxxx 255.255.255.128")?

You believe your router is blocking/dropping some traffic going through it.  I believe, if there's a problem, it's on the WAN side, so I want to try to verify, all traffic can route between just the LAN and WAN interfaces.

As I wrote earlier, some configuration statements have me scratching my head, why they are there.

It would also be helpful, if you could post the other crypto device's config.

Does your C1101 run IOS or IOS-XE?  What version?

I have a copy of CML.  With it, I might be able to recreate you environment on it and/or show you a VTI config or you might skim Configuring a Virtual Tunnel Interface with IP Security.  Also you might want to glance at: Migration to IPsec Virtual Tunnel Interface – Cisco IOS XE White Paper (the beginning of the white paper has some interesting things to say about the crypto map approach!) and IPsec Virtual Tunnel Interface .

Not of those references show using ip tcp adjust-mss, but that would still be worthwhile on a VTI too!

I would also expect, VTI would be more likely to support Next Generation Cryptography  than crypto maps.

[kben4cisco]

Traceroutes and configs

[Joseph W. Doherty]

Thank you for that additional infomation, but as my one reference notes:

1. Why migrate to IPsec virtual tunnel interface?

If you are reading this document, you’re either already convinced or curious about the potential advantages that Cisco’s IPsec Virtual Tunnel Interface (VTI) will bring.

This is a normal transition, and some new platforms and software releases will exclusively support IPsec VTIs.

As time goes on, we at Cisco will cease using the Cisco IPsec Static Crypto Map (SCM) and Dynamic Crypto Map (DCM) features of Cisco® IOS XE, so it’s better to get prepared for the transition.

Personally, I don't want to spend my free time attempting to fix an issue with technology that Cisco appears to be slated for elimination.  If you have a Cisco support contract, open a TAC case.

I do appreciate you want to eliminate your issue, but possibly the best way to do that would be to move to a later VPN technology.

I recall (???) for some VPN migrations it's possible to have new and old VPN technologies active, concurrently, using the same interface.  Which, if true, allows a much simpler migration.  I.e. confirm you have the new technology working, shift traffic to it, if, after a while, all appears good, eliminate the old technology.

If you cannot run both, concurrently, migration is much more difficult, especially if you only remote configuration is via tunnel, but it can be done (very, very carefully).

BTW, I did try to find whether both can be used concurrently, but didn't find an answer.

Hopefully, @MHM Cisco World, or others, will continue to help you find a resolution still using cyrpto maps.

[Joseph W. Doherty]

---

@kben4cisco wrote:

Google ip tcp adjust-mss 1452 for cisco diocument

---

What's the actual reference link?

Again, a 1452 MSS would be suitable for PPPoE.

You'll find "This command IP TCP ADJUST-MSS 1452 is recommended in the PPPoE configurations." in Cisco Technote: 

Ethernet MTU and TCP MSS Adjustment Concept for PPPoE Connections

Also BTW, adjust MSS command is only for TCP, it does nothing for other traffic kinds.  Also, when not used or incorrect, TCP should still work.  The command's purpose is to preclude TCP packet fragmentation, with or without PMTUD.

[kben4cisco]

All computers see the first router with a ping response.

[paul driver]

Hello
Can you share a topology diagram and the run cfg of the rtrs please