icmp deny any outside

alias bond0 bonding mode=1 miimon=100 primary=eth0

Bonding Mode: load balancing (round-robin)

In the end it seems to have been an issue with the entry in /etc/modules.conf. We changed it to:

alias bond0 bonding
options bond0 mode=1 miimon=100 primary=eth0

then restarted and that seems to have fixed the problem:

$ grep "Bonding Mode:" bond0
Bonding Mode: fault-tolerance (active-backup)

I’m not sure why it used to work fine before.

I also came across this http://www.experts-exchange.com/Networking/Linux_Networking/Q_24599062.html (hint to read this link, search for the URL in Google). It seems that the guy posting here had similar syntax and the same problem. If someone has access to Experts Exchange perhaps they can earn themselves some points by answering the question.

A comparison of packet captures was interesting. The graphic below shows two uploads.

Comparison of two TCP flows

The one on the left is of a slow upload between host “Client” and the SharePoint server “Server”. The one on the right is of a fast upload between host “Client2″ and the SharePoint server “Server”. Both are actually Flow Graphs from Wireshark. Notice that the one on the left pauses after 60ms (0.060 seconds) and waits for an ACK from Server. However, the one on the right continues on. Yet the TCP Window sizes are identical in both flows.

In the end we discovered another parameter in Windows. AFD.SYS is used to support Windows sockets applications. Registry parameters for ADF.SYS are found in HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters. The one that’s relevant is DefaultSendWindow. On the slow machines this parameter was not set and so used the default (decimal 8192 it seems). On the fast PC this was set to decimal 64512 (hex fc00).

Changing this value on the PCs with slow upload speed and then rebooting seems to have fixed the problem.

For more information on this parameter see Network: The relationship between TCPWindowSize and DefaultReceiveWindow.

So, why was this value different between PCs. It seems that when you install the Citrix MetaFrame Client the installer automatically increases this value. The fast PCs all had the MetaFrame Client installed.

For example:

flow exporter NFSVR
 destination 10.1.1.1
 source Vlan1
 output-features
 transport udp 9996
!
!
flow monitor flow-monitor
 record netflow-original
 exporter NFSVR
 cache timeout active 1

However, although the output-features command appears to be available on earlier versions of IOS, it doesn’t seem to have been implemented. You can type the command without error, but it never makes it into the config. So, if you’re trying to get this working, and it’s not, I suggest checking your IOS version.

Aug  5 07:51:08.643: ISDN BR0/1/0 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x84
        Cause i = 0x82E404 - Invalid information element contents
Aug  5 07:51:08.643: //21/8043BD33BC09/CCAPI/cc_api_call_disconnected:
   Cause Value=100, Interface=0x4900DFC0, Call Id=21
Aug  5 07:51:08.643: //21/8043BD33BC09/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=100, Retry Count=0)
Aug  5 07:51:08.643: //20/xxxxxxxxxxxx/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/ccCallSetAAA_Accounting:
   Accounting=0, Call Id=21
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/ccCallDisconnect:
   Cause Value=100, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=100)
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/ccCallDisconnect:
   Cause Value=100, Call Entry(Responsed=TRUE, Cause Value=100)
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x4900DFC0, Tag=0x0, Call Id=21,
   Call Entry(Disconnect Cause=100, Voice Class Cause Code=0, Retry Count=0)
Aug  5 07:51:08.647: //21/8043BD33BC09/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Aug  5 07:51:08.647: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

In the end it turns out I was missing the configuration command compand-type a-law

voice-port 0/1/0
 translation-profile incoming pstn-incoming
 translation-profile outgoing pstn-outgoing
 compand-type a-law
 cptone AU

Note this is for a router in Australia – other countries might be different.

Download Speed (kbps): 23410
Upload Speed (kbps): 1017

The ADSL router was configured with pretty typical MTU and MSS settings (probably copied off the Internet):

interface Vlan1
ip mtu 1452
ip flow ingress
ip tcp adjust-mss 1452

interface Dialer0
ip mtu 1452

The remote site has a VMware ESXi server. I couldn’t remotely connect to the ESXi server using the vSphere client. I could connect using ssh. However, if I tried running any command with a reasonable size output (e.g. ps) the session would hang and then time out. I could connect to a remote server using RDP, but it was very slow to connect (once connected the RDP session was fine).

I had no problems connecting to the ESXi server from the VMware session.

I tried running an FTP on the remote server and copying a file to my location with the following result:
ftp: 149504 bytes sent in 28.89Seconds 5.17Kbytes/sec.

That’s pretty slow for a connection with almost 1Mbps upload speed.

So, I started playing around with MTU and MSS (in the following tests MSS was either set to the same value as MTU or 40 bytes less):
mtu 1200
ftp: 149504 bytes sent in 1.58Seconds 94.74Kbytes/sec.

mtu 1300
ftp: 149504 bytes sent in 2.84Seconds 52.62Kbytes/sec.

I finally settled on the following:

interface Vlan1
ip mtu 1242
ip flow ingress
ip tcp adjust-mss 1200

interface Dialer0
ip mtu 1452

94Kbytes/sec is pretty reasonable for a 1Mb link with round trip latency of around 83ms.

Then I started wondering if my ACL was blocking Path MTU Discovery. So, I added the following to the inbound ACL on the 877 (as per http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml) and changed the MTU values back to original:

permit icmp any any unreachable
permit icmp any any time-exceeded

However, there were no hits and it didn’t seem to help at all:
ftp: 149504 bytes sent in 28.73Seconds 5.20Kbytes/sec.

Then after reading a bit more I wondered what would happen if I took all the MTU and MSS settings off:
ftp: 149504 bytes sent in 3.05Seconds 49.08Kbytes/sec.

Hmm. Much better than the original settings, although not as good as MTU 1200. Perhaps the link might be under a bit of load, let’s try again:
ftp: 149504 bytes sent in 1.52Seconds 98.68Kbytes/sec.

And a third time:
ftp: 149504 bytes sent in 1.52Seconds 98.68Kbytes/sec.

So I tried a fourth and fifth time (both had the same result):
ftp: 149504 bytes sent in 1.50Seconds 99.67Kbytes/sec.

So, I thought, maybe the router or computer is remembering the session and MTU (if it’s doing MTU discovery). So I disconnected the FTP sessions and reconnected:
ftp: 149504 bytes sent in 1.50Seconds 99.74Kbytes/sec.

Amazing. So the tip? Perhaps the best way to handle MTU is to not worry about it.

The second issue I had was with the router not registering with DynDns. Specifying debug ip ddns update showed the following:

Dec  6 10:03:00.988: HTTPDNSUPD: Sending request
Dec  6 10:03:20.996: HTTPDNSUPD: Call returned Connection time out, update of yourhost.dyndns.net <=> 123.123.123.123 failed

It turns out the second issue was with CBAC. I had to add an inspect entry to my router configuration:
ip inspect name CBAC-OUT tcp router-traffic

The relevant parts of my configuration are below:

ip inspect name CBAC-OUT tcp router-traffic
ip ddns update method DYNDNS
 HTTP
  add http://username:password@members.dyndns.org/nic/update?system=dyndns&hostname=<h>&myip=<a>
 interval maximum 28 0 0 0
 interval minimum 28 0 0 0

interface Dialer0
 ip ddns update hostname putyourdnsnamehere
 ip ddns update DYNDNS host members.dyndns.org
 ip address negotiated
 ip access-group DIALER0_IN-3 in
 ip inspect CBAC-OUT out

ip access-list extended DIALER0_IN-3
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any time-exceeded
 permit icmp any any packet-too-big
 deny   ip any any

Thanks to this thread at Whirlpool for helping me resolve this problem. For more on the ip inspect tcp router-traffic see Inspect router-generated traffic and it’s update Update: Inspect router-generated traffic. For information on CBAC try the following links:
http://www.ciscopress.com/articles/article.asp?p=26533
http://www.dslreports.com/faq/13435
http://www.cisco-tips.com/how-to-configure-cisco-router-with-ios-firewall-functionality-%E2%80%93-cbac/
http://articles.techrepublic.com.com/5100-10878_11-1057051.html

Below is an example of a working configuration on a Cisco 2801 router with IOS Version 12.4(13b), RELEASE SOFTWARE (fc3). Note that authentication uses PAP, in most cases you probably want to use a more secure form of authentication. The router this config snippet came from uses RADIUS to authenticate the user. This configuration works with certificates. The change needed to allow pre-shared keys is quite small. I might add it later when I can get access to a non production router.

I’m using Fastethernet 0/1 as the external interface with IP address 123.123.123.123. The DHCP pool is in the 192.168.100.0 subnet. The DNS server is 192.168.200.1. I’ve called the crypto map VPNMAP.

vpdn enable
!
vpdn-group 1
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
ip mtu adjust

crypto isakmp policy 20
encr 3des
hash sha
authentication pre-share
group 2

crypto isakmp policy 30
encr 3des
hash md5
group 2
!

crypto ipsec transform-set TRANSESP3DESMD5 esp-3des esp-md5-hmac
mode transport
!
!
!
crypto dynamic-map DYNMAP 1
set nat demux
set transform-set TRANSESP3DESMD5
match address 130
!
!
crypto map VPNMAP 65000 ipsec-isakmp dynamic DYNMAP
!
!
!
interface Virtual-Template1
ip unnumbered FastEthernet0/1
ip mroute-cache
peer default ip address pool VPN_CLIENT_POOL
ppp authentication pap
ppp ipcp dns 192.168.200.1
!
!
ip local pool VPN_CLIENT_POOL 192.168.100.1 192.168.100.99
!
access-list 130 remark Allow L2TP access
access-list 130 permit udp host 123.123.123.123 eq 1701 any
!
interface FastEthernet0/1
crypto map VPNMAP

I don’t think the “authentication pre-shared” is needed. I might remove it later when I have a chance to test it. The ISR seems to allow certificate authentication by default. Note that in my testing I found that the ISR would support both shared key and certificate authentication at the same time.

The router concerned also has a L2L (LAN to LAN) IPSec VPN tunnel configured. I might post the entire config at some later stage.