04-07-2017 03:34 AM - edited 03-05-2019 08:19 AM
Hi Guys,
I am having some VPN issues which are starting to creep above my skill level.
I have set up a GRE tunnel between a head office router and a branch office router. When browsing the internet from the branch office through the tunnel I am getting very poor speeds and unusual behaviour. For example I can browse some of youtube (poorly) but I cant even open www.netflix.com
From the research I have done, I am starting to wonder if the issue is related to MTU or TCP MSS .
Let me paste the configs below, along with the router details and hopefully you have a better idea than me?
Head Office Router;
Model - CISCO 2901/K9
IOS - 15.0(1r)M16
=====================================
HO-WAN-RTR-VPN01#sh ip int tunn 4
Tunnel4 is up, line protocol is up
Internet address is 169.254.40.1/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1300 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP Null turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is enabled, interface in domain inside
BGP Policy Mapping is disabled
Input features: Common Flow Table, Stateful Inspection, Virtual Fragment Reassembly, Virtual Fragment Reassembly After IPSec Decryption, MCI Check, TCP Adjust MSS
Output features: NAT Inside, Common Flow Table, Stateful Inspection, TCP Adjust MSS, NAT ALG proxy
Post encapsulation features: IPSEC Post-encap output classification
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled
===============================================
interface Tunnel4
ip address 169.254.40.1 255.255.255.252
ip mtu 1300
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1379
tunnel source xxx.xxx.136.210
tunnel destination xxx.xxx.211.3
tunnel protection ipsec profile test_profile
end
====================================================
Branch Office Router;
Head Office Router;
Model - Cisco 871 (MPC8272)
IOS - Version 12.3(8)YI2
============================================
Crabmeat#sh int tunn 4
Tunnel4 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.40.2/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source xxx.xxx.211.3 (Dialer0), destination xxx.xxx.136.210
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Path MTU Discovery, ager 10 mins, min MTU 92, MTU 0, expires never
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec_glink_profile")
Last input 00:32:33, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/310092/0 (size/max/drops/flushes); Total output drops: 233
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
43379375 packets input, 1453292908 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
38438968 packets output, 3877235423 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
========================================
interface Tunnel4
ip address 169.254.40.2 255.255.255.252
ip mtu 1300
ip virtual-reassembly
ip tcp adjust-mss 1460
tunnel source Dialer0
tunnel destination xxx.xxx.136.210
tunnel path-mtu-discovery
tunnel protection ipsec profile ipsec_test_profile
end
Solved! Go to Solution.
04-07-2017 10:42 AM
For your tunnels, try IP MTU 1400 and IP TCP adjust-mss 1360.
04-07-2017 05:10 AM
your ip tcp adjust-mss on tunnel different, fisrt side have 1379, second side have 1460, it have to be the same
04-07-2017 10:42 AM
For your tunnels, try IP MTU 1400 and IP TCP adjust-mss 1360.
04-07-2017 11:35 AM
In addition to the other posts, 'tunnel path-mtu-discovery' on the tunnel interfaces might help as well...
04-07-2017 05:54 PM
Thanks. These settings made a big difference and fixed most performance issues I was having. Connecting to Netflix still does not work although this may be a seperate issue as the windows box connects fine.
04-09-2017 04:16 PM
I would like to elaborate a little further for anyone else experiencing this issue. At this point Netflix is back up and running and I am achieving 6Mbps out of a potential 13Mbps. Not the best but still a massive improvement on what I had. I now have an ip mtu of 1398 and an ip tcp adjust-mss of 1358 on both ends. To arrive at these values I basically I did the ping to the remore router 192.168.212.1 -f -l xxxx, where x was the mtu value that eventually stopped fragmenting. In the end 1370 was just right with 1371 being too high. I then added 28 to get 1398 as is the recommended practice. I then subtracted 40 from that value to get 1358 as is also the recommended practice. I would love to get a 13Mbps download to match the adsl connection but they may not be possible with GRE. I will continue to tweak.
04-10-2017 05:22 AM
Ah, just caught your mention of aDSL and also just noticed you're using a dialer interface. I'll presume your aDSL is using PPPoE, usually decreases MTU by 8 bytes. (That would be on the physical aDSL interface.)
04-10-2017 03:48 PM
Thanks Joseph,
I did actually change the dialer interface to 1492 as it was sitting at 1500. Do you think I should also change Fa4 to 1492 (physical ISP facing)?
04-11-2017 02:39 AM
I'm unsure - it's been so, so long since I worked with a dialer interface.
Having the dialer interface set to 1492 might be fine, although setting the ISP facing F4 to 1492 should be suitable too.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide