01-12-2016 08:21 AM - edited 03-05-2019 03:06 AM
We have a new Cisco ASA 5512 that I installed over the weekend. After all of the tests I ran came back good, I left the building. I came in on monday and while most things were running fine, we began to run into issues where people connected via VPN to the ASA were intermittently unable to connect via SSL to exchange OWA. Packet captures showed that the packets from the client were reaching the exchange server and the exchange server was ACKing them and replying, but the clients weren't receiving the responses to setup the SSL connection.
Using pings of various sizes with the Don't Fragment bit set and changes to the ASA's MTU on the internet facing port I discovered the following:
I can ping both internet and VPN connected computers just fine with small packets.
When the router's internet-facing port is set to an MTU of 1500 I can ping computers on the internet with packets up to 1472, above which my computer (which is also set to an MTU of 1500) tells me that the packet must be fragmented. This is exactly as I would expect so far.
When the router's internet-facing port is set to an MTU of 1500 I can only ping computers connected to VPN with packets up to 1356, after which the packets time out. This is not what I would expect. Even if the packet size was to large, I should be getting a ICMP response back stating that the packet was dropped because it needed to be fragmented and the DF bit was set.
Once I drop the router's internet-facing port down to an MTU of 1400, I can ping computers on the internet with packets on to 1372, after which the packets time out. Once again, we've got a problem. I would expect to only be able to send packets up to 1372, but at 1373 (where we're below my computer's MTU but above the router's MTU with the 28 byte headers) the router should be sending me back a response saying the packet needs to be fragmented but the DF bit is set.
There's also a corresponding drop to 1256 when attempting to ping computer's connected via VPN, with no response for pings with more bytes.
Shouldn't the ASA be replying with ICMP packets when it can't forward a packet? During the process of setting up the router is there a setting somewhere that I accidentally activated that disabled this functionality? Right now PMTUD looks like it's broken because the ASA isn't sending back information to inform computers to reduce the transmission size.
01-12-2016 08:53 AM
Hello,
Did you permit ICMP from ASA to the client ? Try to ping clients from ASA. ASA does send ICMP type 3 code 4 error if it drops the packets. ICMP may not be permitted on ASA or somewhere in your network.
Masoud
01-12-2016 09:34 AM
Pings from the ASA work just fine. Come back with <1ms consistently.
01-12-2016 09:43 AM
How about VPN IP address on client? Can you ping that from ASA?
01-12-2016 10:12 AM
Pinging the client address from the ASA does not work. I can ping VPN IP addresses from inside the network. I can ping network addresses from VPN clients. I cannot ping from one VPN client to another.
01-12-2016 10:21 AM
What is your vpn client? Is it a software on clients ? Check the software side to see whether there is any firewall on VPN connection.
01-12-2016 11:06 AM
The client is a windows built-in L2TP/IPSec client. I've disabled the firewall on the system to no effect. Even if a firewall were present, I can't think of any reason that it could prevent the ASA from sending the ICMP packets to alert a client that it's packet are to large. I've sent pings from our private network to google's public DNS servers (never hitting the VPN) and haven't gotten back the ICMP packets when I went over the MTU of the ASA.
01-12-2016 11:12 AM
Also of note is that I've tried sending pings from a computer that has no firewall outside of the windows firewall installed and the windows firewall is disabled. Sending a 1400 byte (+28 for headers is 1428) ping to 8.8.8.8 times out if I drop the ASA firewall MTU on the internet facing port to 1400. At a minimum, the ASA should be sending back the ICMP type 3 code 4 packets and those pings should all come back saying that the ASA told them no, not timing out.
01-12-2016 02:23 PM
Install wireshark on client to monitor ICMP packets. ASA may send ICMP, but client does not adjust the MTU.
Masoud
01-13-2016 07:02 AM
Okay! So, information dump: The ASA is currently inconsistent about what it does and doesn't send ICMP type 3 code 4 packets for. What it does appear to send packets for: TCP connections running that are not on the VPN. If I drop the MTU on the line down while running wireshark on the server and attempt a connection to something that is not connected via VPN then it works beautifully. I see the ICMP packets come back and the server gracefully reduces it's transmission rate and everything is good.
What it does not appear to send ICMP packets for: ICMP echo requests. Any connections running over the VPN. If I attempt to ping any locations on the internet with a packet that is over the MTU, the ASA does not reply with a with an ICMP unreachable packet. This makes diagnosing an MTU issue extremely difficult, as pings are a very common tool for this purpose. Even more problematic, the ASA doesn't generate ICMP echo requests (at least for TCP connections) when the TCP connection is running over a VPN connection. If I request the same website twice, once via the VPN and the other via NAT I will see ICMP unreachable packets come back to the server from the NAT but not from the VPN connection.
I'm happy to send the saved pcap files if you want to confirm.
01-20-2016 02:04 PM
The issue was with Cisco ASA image 9.1(3) which apparently had a bug. Finally got everything squared away with my contract on monday and got the update finished a minute ago. ASA now properly responds to packets which are too large with DF bit set.
01-13-2016 04:01 AM
01-13-2016 05:12 AM
Add login under the line vty and console.
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: