01-10-2008 11:35 AM - edited 02-21-2020 03:28 PM
OK, I have an odd issue and was wondering if anyone here had any insight.
I have an 1841 router at our main office that serves as the local endpoint for our L2L IPSec tunnels. For 12-14 months now it has had 3 tunnels coming into it.
I recently replaced the PIX 501 at my home (which had a L2L IPSec tunnel to the 1841 for almost a year with no issues) with a Cisco 877W router. I deleted the old tunnel and recreated the tunnel between the 1841 and my 877W.
Here's where the weirdness starts. I have the tunnel up and can ping across, but when I initiate an RDP connection to any machine at the office the connection times out before it can be built. This also happens with ICA connections. I am sure that routing is configured properly as I can ping the machines with no issues, as well as hit the HTTP servers running on them, I just can't do RDP or ICA.
I did some research and thought that it might be an issue with MTU getting large packets dropped, so I did a ping test with the DF bit set and kept increasing the packet size until they dropped (maximum packet size was 1399 bytes). Then, I applied the ip tcp adjust-mtu 1392 commmand to the Vlan1 and Dialer0 interfaces on my 877W as well as the Fa0/1 and Fa0/0 interfaces on the 1841. Still no dice.
Does anyone know why this might be? With the PIX 501 I had no problems with RDP or ICA.
Thanks,
Chris
01-14-2008 09:32 PM
I haven't had much time to troubleshoot this until today. Thinking it might be the problem, I disabled the IOS firewall and reloaded the router.
That did not work. I am still able to ping anything in the remote network from both sides of the tunnel.
Here is the configuration of my local 877. Does anything look wrong? I am completely stumped.
version 12.4
no service pad
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
hostname cnc.chris.877
!
boot-start-marker
boot-end-marker
!
logging buffered 52000
!
no aaa new-model
!
crypto pki trustpoint TP-self-signed-3316305002
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-3316305002
revocation-check none
rsakeypair TP-self-signed-3316305002
!
!
crypto pki certificate chain TP-self-signed-3316305002
certificate self-signed 01
*truncated
quit
!
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key ******** address x.x.x.x
!
!
crypto ipsec transform-set ESP-AES-MD5 esp-aes esp-md5-hmac
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
description Tunnel to Work
set peer x.x.x.x
set transform-set ESP-AES-MD5
match address chris-IPSec
!
no ip source-route
ip cef
!
!
no ip dhcp use vrf connected
ip dhcp excluded-address 172.31.0.2 172.31.0.59
ip dhcp excluded-address 172.31.0.70 172.31.0.254
!
ip dhcp pool 172
network 172.31.0.0 255.255.255.0
default-router 172.31.0.1
dns-server 206.63.224.5 206.63.224.6
!
!
no ip bootp server
ip name-server 206.63.224.5
ip name-server 206.63.224.6
!
multilink bundle-name authenticated
!
!
username admin privilege 15 secret 5 $1$BPv/$eQLZYrg2N8FwqL/g8Z/
archive
log config
hidekeys
!
!
!
!
!
interface ATM0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
no ip redirects
no ip unreachables
no ip proxy-arp
no snmp trap link-status
pvc 0/32
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Dot11Radio0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
shutdown
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0
54.0
station-role root
!
interface Vlan1
ip address 172.31.0.1 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat inside
ip virtual-reassembly
ip tcp adjust-mss 1392
!
interface Dialer0
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip tcp adjust-mss 1392
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username ******** password 7 104101D544E44
crypto map SDM_CMAP_1
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload
!
ip access-list extended chris-IPSec
remark SDM_ACL Category=4
permit ip 172.31.0.0 0.0.0.255 10.0.0.0 0.255.255.255
permit ip 172.31.0.0 0.0.0.255 192.168.100.0 0.0.0.255
!
access-list 23 permit 172.31.0.0 0.0.0.255
access-list 104 remark SDM_ACL Category=2
access-list 104 deny ip 172.31.0.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 104 deny ip 172.31.0.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 104 permit ip 172.31.0.0 0.0.0.255 any
dialer-list 1 protocol ip permit
no cdp run
!
!
!
route-map SDM_RMAP_1 permit 1
match ip address 104
!
!
control-plane
!
!
line con 0
login local
no modem enable
line aux 0
line vty 0 4
privilege level 15
login local
transport input telnet ssh
!
scheduler max-task-time 5000
ntp clock-period 17174993
ntp server 64.25.87.54
!
webvpn cef
end
01-17-2008 12:18 PM
Try IP MTU 1452 on your dialer 0 interface
01-22-2008 09:00 PM
I applied the MTU of 1452 to the Dialer0 interface, but nothing changed.
I did prove that it is a MTU issue, because when I force the MTU for my PC to 1392, everything works perfectly. When I set it back to 1500, the connections stop working.
I did an extended ping from my router's Dialer0 interface and noticed that I can ping the remote gateway with datagram sizes all the up to 1452 with no problem.
From the LAN behind the router, I can ping (with the DF bit set) devices in the LAN behind the remote endpoint with datagram sizes up to 1351. 1352-byte datagrams get dropped.
This is 48 bytes less than I was able to get through before, which is exactly the amount I reduced the MTU on the Dialer0 interface by. So unfortunately, I don't believe that accomplished anything.
Is there another way I can force devices on the inside to reduce their MTU without setting it manually on every device? "ip tcp adjust-mss 1392" didn't seem to change anything.
Thanks,
Chris
01-22-2008 09:15 PM
I set the MTU on Dialer0 back to 1500.
Now, when I do an extended ping from my Dialer0 int with the DF bit set, 1500-byte datagrams come back, but 1501-byte datagrams do not.
When I ping from a device on my LAN, 1399-byte datagrams come back from the remote side of the tunnel, but 1400-byte datagrams do not.
When I ping a device on the Internet that is not through the tunnel, the limit is 1472 bytes.
So, I have determined that the tunnel is taking 100 bytes off the top, but I still can't seem to get things working optimally over the tunnel unless I manually force the MTU of the initiating device.
Any thoughts?
Thanks,
Chris
01-22-2008 10:00 PM
Adjusting the MSS would help only TCP traffic (as it is in the TCP options header) and will not affect IP or ICMP traffic. You are right that you are running into a MTU issue but the only way I can think of making it work is to have the end PC doing a PMTUD before generating IP datagrams.
Or, you can do this
crypto ipsec df-bit clear which may help fragment the IPSec header.
Let me know if it works
01-23-2008 08:30 AM
crypto ipsec df-bit clear worked. I can now do everything through the tunnel.
I realize that by fragmenting IPSec packets I am reducing my throughput dramatically, however this is a good workaround for now.
One question: if I set the MTU on the LAN side of the router, would that force devices on the LAN to reduce their packet sizes, or would it fragment them? Also, if the packets are fragmented before encryption, is the throughput better than when the packets are fragmented after?
01-25-2008 07:16 AM
No MTU is at the IP layer and just as IP is connectionless, MTU is something which is not negotiated and is local to an interface. So if you change the MTU on the local LAN, the devices will not be able to adjust and instead you would have fragmentation.
Also, I would assume that any kind of fragmentation is injurious to throughput - I would rather say that post encryption is much better than pre encryption
01-25-2008 08:03 AM
What versions of IOS are you running on each router? I had the same issue for two 871W's in a site-to-site tunnel that was fixed when I brought them both to the same IOS rev (I think 12.4.11Tx (x=latest and greatest), Advanced Security).
01-25-2008 08:33 AM
IOS version is 12.4-15T1.
So, my best bet for the best throughput is to hard-set the MTU on devices inside the LAN to something under 1400. That way I would avoid fragmentation.
A good workaround is the crypto ipsec df-bit clear option, which is causing the packets to be fragmented and passed instead of dropped. It seems that allowing the packets to be fragmented is decreasing throughput, but it is working at least.
If I have any free time over the weekend, I'll do a test -- one device on my LAN with default MTU, and one device with MTU set to 1392 -- and see if either device feels faster when connected to a terminal server on the remote side of the tunnel.
Thanks for your help, all!
01-25-2008 08:38 AM
Forgot to mention -- remote endpoint is running IOS version 12.4-13-T2 I believe. I will try downgrading 877 to that version and see if anything changes.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: