Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1311
Views
5
Helpful
22
Replies

Route Based S2S IPSEC Slow/Missing Packets?

Go to solution
rtarson98
Level 1
Level 1

‎01-08-2025 08:52 AM - edited ‎01-08-2025 08:53 AM

So I have a PTP S2S IPSEC tunnel created for a location I was able to get the connection up I can ping all the Endpoints in the route okay on both sides. However I noticed connecting to RDP or doing SMB it was SLLLOOOOOW. Or just disconnected due to timeout. I thought maybe it was the DNS. But the dns was reaching but noticed that was having a delay in name resolution. 

So then I got down the rabithole of inspecting the packets and doing ping with packet size. I tried with paramters -f and -l. I tested what my largest acceptable packet over IPSEC and noticed that it taps out around 1410. On my FTD the WAN that is connecting the Firepower/Tunnel is set at a MTU of 1500. The extranet device has MSS Clamping with TCP Connection Segment size of 1452 and the MTU is 1500. 

I have a feeling it all has to do with the MTU from my readings but if someone thinks other wise I am all ears.

Now to fix Is this something I have to do via the Flexconfig to fix? I read something about adding sysopt_basic. However it looks like it will size all tcp traffic, should I configure to only to size the IPSEC routes only? Also what is the recommended MSS TCP segment size for MTU of 1500 over IPSEC? 

Labels:
22 Replies 22

Go to solution
MHM Cisco World
VIP
VIP
In response to rtarson98

‎01-12-2025 06:48 AM

I am sure it routing issue 
can I see RIB in both Peers 
also you need to check mac address in wiresharke <<- you can add column for mac source and destination in wiresharke this make it easy for you to check if Peer forward the traffic via correct interface.  

MHM

0 Helpful

Go to solution
rtarson98
Level 1
Level 1
In response to MHM Cisco World

‎01-12-2025 08:31 AM

Good morning, 

I'm gravitating to that as well but its weird everything looks to be in the right spot.

 

Here is the Routes on the Extranet Router(I put *** to point it out):

10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
10.0.1.0/24 dev br1001 proto kernel scope link src 10.0.1.1
10.0.2.0/24 dev br1002 proto kernel scope link src 10.0.2.1
10.0.3.0/24 dev br1003 proto kernel scope link src 10.0.3.1
10.0.10.0/24 dev br1010 proto kernel scope link src 10.0.10.1
10.0.60.0/24 dev br1060 proto kernel scope link src 10.0.60.1
10.1.0.0/24 dev vti64 proto static scope link metric 30
10.1.2.0/24 dev vti64 proto static scope link metric 30
10.1.3.0/24 dev vti64 proto static scope link metric 30
10.1.60.0/24 dev vti64 proto static scope link metric 30
10.2.0.0/24 dev vti64 proto static scope link metric 30
***10.2.2.0/24 dev vti73 proto static scope link metric 30***
10.3.0.0/24 dev vti65 proto static scope link metric 30
10.3.2.0/24 dev vti65 proto static scope link metric 30
10.3.3.0/24 dev vti65 proto static scope link metric 30
10.4.0.0/24 dev vti67 proto static scope link metric 30
10.4.2.0/24 dev vti67 proto static scope link metric 30
10.4.3.0/24 dev vti67 proto static scope link metric 30
10.5.0.0/24 dev vti66 proto static scope link metric 30
10.5.2.0/24 dev vti66 proto static scope link metric 30
10.5.3.0/24 dev vti66 proto static scope link metric 30
10.6.0.0/24 dev vti68 proto static scope link metric 30
10.6.2.0/24 dev vti68 proto static scope link metric 30
10.6.3.0/24 dev vti68 proto static scope link metric 30
10.9.0.0/24 dev vti69 proto static scope link metric 30
10.9.2.0/24 dev vti69 proto static scope link metric 30
10.9.3.0/24 dev vti69 proto static scope link metric 30
10.10.0.0/24 dev vti70 proto static scope link metric 30
10.10.2.0/24 dev vti70 proto static scope link metric 30
10.10.3.0/24 dev vti70 proto static scope link metric 30
10.11.0.0/24 dev vti71 proto static scope link metric 30
10.11.2.0/24 dev vti71 proto static scope link metric 30
10.11.3.0/24 dev vti71 proto static scope link metric 30
10.190.0.0/24 dev br1090 proto kernel scope link src 10.190.0.1
10.255.1.0/30 dev vti73 proto kernel scope link src 10.255.1.2
71.115.138.0/24 dev eth0 proto kernel scope link src 71.115.xxx.164
172.16.0.8/29 dev br1072 proto kernel scope link src 172.16.0.10
192.168.1.0/24 dev vti64 proto static scope link metric 30
192.168.61.0/24 dev vti64 proto static scope link metric 30

This is interface vti73

vti73: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1419
        inet 10.255.1.2  netmask 255.255.255.252  destination 10.255.1.2
        inet6 fe80::200:5efe:4773:8aa4  prefixlen 64  scopeid 0x20<link>
        tunnel   txqueuelen 1000  (IPIP Tunnel)
        RX packets 12  bytes 838 (838.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 1567 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On the FTD side now

Gateway of last resort is 74.106.X.1 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [20/0] via 74.106.X.1, ISP-WAN
S        10.0.0.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.2.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.3.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.60.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
C        10.2.2.0 255.255.255.0 is directly connected, Supply-Wired-Clients
L        10.2.2.1 255.255.255.255 is directly connected, Supply-Wired-Clients
S        10.3.0.0 255.255.255.0 [5/0] via 10.255.2.2, DWT-SVTI
S        10.3.2.0 255.255.255.0 [5/0] via 10.255.2.2, DWT-SVTI
S        10.3.3.0 255.255.255.0 [5/0] via 10.255.2.2, DWT-SVTI
V        10.4.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.4.2.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.4.3.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.2.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.3.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.7.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
C        10.254.0.0 255.255.255.248 
           is directly connected, Supply-Ubiquiti-MGMT
L        10.254.0.1 255.255.255.255 
           is directly connected, Supply-Ubiquiti-MGMT
C        10.255.1.0 255.255.255.252 is directly connected, CIC-SVTI
L        10.255.1.1 255.255.255.255 is directly connected, CIC-SVTI
C        10.255.2.0 255.255.255.252 is directly connected, DWT-SVTI
L        10.255.2.1 255.255.255.255 is directly connected, DWT-SVTI
C        10.255.255.1 255.255.255.255 is directly connected, S2S-Loopback
C        74.106.X.0 255.255.255.0 is directly connected, ISP-WAN
L        74.106.X.118 255.255.255.255 is directly connected, ISP-WAN
C        192.168.1.0 255.255.255.0 is directly connected, Legacy-Subnet-192
L        192.168.1.1 255.255.255.255 is directly connected, Legacy-Subnet-192

 Here is the screenshot of the packet capture showing the DestMAC

 

No Response

rtarson98_0-1736699337594.png

The one with a response:

rtarson98_1-1736699451086.png

 

0 Helpful

Go to solution
MHM Cisco World
VIP
VIP
In response to rtarson98

‎01-18-2025 06:28 AM 

S        10.0.0.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.2.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.3.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
S        10.0.60.0 255.255.255.0 [5/0] via 10.255.1.2, CIC-SVTI
V        10.4.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.4.2.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.4.3.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.2.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.6.3.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN
V        10.7.0.0 255.255.255.0 
           connected by VPN (advertised), ISP-WAN

Hi Friend 

sorry for late reply 
are above correct ? how same subnet is learn from ISP-WAN and VTI ??

this make issue sure 

MHM

0 Helpful

Go to solution
rtarson98
Level 1
Level 1
In response to MHM Cisco World

‎01-20-2025 03:35 PM

After support calls with cisco and ubiquiti. I took another glimpse. Turned out to be LACP config issue. I thought LACP On in cisco world meant LACP negotation. My Switching LACP to active corrected everything crazy stuff literally a dropdown.

Go to solution
rtarson98
Level 1
Level 1
In response to MHM Cisco World

‎01-12-2025 11:38 AM - edited ‎01-12-2025 11:39 AM

Also Here is the only route I have in FMC per Cisco documentation for that tunnel. 

Internal Subnet selected include

10.0.0.0/24

10.0.60.0/24

10.0.2.0/24

10.0.3.0/24

rtarson98_0-1736710658825.png

With a metric of 4. The General WAN traffic has metric 20

 

0 Helpful

Go to solution
Joseph W. Doherty
Hall of Fame
Hall of Fame

‎01-12-2025 12:34 PM

The usual Cisco recommendation for crypto is to use a MTU and MSS, 1,000 less.  On Cisco router interfaces, such as their VTIs, this is often accomplished by setting IP MTU 1400 and IP TCP ADJUST-MSS 1360.

0 Helpful

Go to solution
rtarson98
Level 1
Level 1
In response to Joseph W. Doherty

‎01-12-2025 12:42 PM

Now is there a way to just do this on the VTI. Or do I have to do on the uplink. Cause if that’s the case I most likely would want second uplink for tunnels? Leave my regular traffic with mtu of 1500

0 Helpful

Go to solution
Joseph W. Doherty
Hall of Fame
Hall of Fame
In response to rtarson98

‎01-12-2025 03:14 PM

Not familiar with your Firepower, but on Cisco routers, you only need to apply those commands on the VTI.

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card