I'm having some difficulty connecting to a Cisco 871 via a remote access IPSec connection. I'm using the Shrew VPN client, and when I connect from in front of my home firewall coming from a public IP, all works just fine. I can connect to the 871, and get access to devices on the local lag behind the 871. When I try to place my PC behind my home firewall, I "seem" to connect, but cannot pass traffic. And by "seem" to connect, Shrew says it's connected and tunnel is up, and I have an IP address assigned to the tunnel, and the appropriate route statements have shown up in my routing table, but if I do a show crypto ipsec sa on the 871, there is nothing there. I can do a show crypto session, and it does show my session, but nothing as the ipsec sa.
I have allowed udp 4500 in my configuration via acls and the policy/class maps, but I'm wondering if there is a command on the Cisco 871 that I should be using to enable NAT-T. Everywhere that I've looked is says "make sure NAT-T is supported on both sides of the connection". I know on the ASA you add the command "isakmp nat-transversal 20", but I can't find an analogous command on the 871 using Zone Based Firewall. I will gladly post my config, but I was hoping that this might be an easy fix, or a command that I can't seem to locate to enable NAT-T. When I turn debug on the 871, I see no reference to port 4500, it all talks about connections from port 500 to 500, which makes me think that I'm missing something on the NAT-T front.
Does anyone have any ideas? As mentioned I can post my config, but wanted to check for the easy answer first.
NAT-T is not for VPN traffic initiated from the router but for NAT devices on the path between the 2 VPN endpoints.
And it is enabled by default on Cisco routers.I f you do a show crypto isakmp sa and the state is QM_Idle then the IKE phase 1 was ok and the tunnel came up but if then show crypto ipsec sa shows you no packets then it is most surely a crypto ACL problem. Can you run a debug crypto isa and debug crypto ipsec and post result and also in your zbf config in global config enter this command: ip inspect log drop-pkt and post the log message if any.
Thank you so much for your reply. When I said that there was nothing in the show crypto ipsec sa, I meant literally nothing - no output at all, not just that there was no packet activity. And in addition to that, absolutely no output from debug crypto ipsec - debug crypto isakmp looked normal and indicated QM_Idle. After struggling with this for another hour behind my NAT device, I went back to putting my computer directly behind my cable modem with no home FW (not the 871 - that's at a remote site) such that it got a public IP address - I knew this was working before so wanted to see what a successful debug looked like. Lo' and behold, I got the exact same thing! IKE negotiated fine, got an IP address, client said tunnel was up, but could not pass traffic, and absolutely nothing in the show crypto ipsec sa. I struggled for another hour comparing the 871 config to one that I know was working earlier, and I couldn't find anything that would have screwed up the IPSec portion.
Then, I thought to myself - free client, Windows 7, also have my ASA AnyConnect on there (and I know multiple VPN clients sometimes don't play nice with each other - Shrew was one of the few that was actually stable with Any Connect on there). So, I rebooted my PC. And Viola! Everything worked with directly connected to the cable modem. I inserted my home FW back in the mix such that I was behind a NAT device, and all worked with that too!! So, I think I must have burned about 2-3 hours on this, thinking that it was a ZFW config problem, when really it was PC.
I do know that at first it was working directly with a public IP, and not working behind a NAT device. Early on, behind a NAT device the tunnel wouldn't even come up, so that's why I thought it was a NAT-T issue. I had made lots of changes to the config at that point (before sending this post) and did get the tunnel to come up, but no IPSec information - it must of been at this point that my client was the problem and not the config.
So this problem is resolved! Thank you for the ip inspect log drop-pkt - I'll need that here for another problem!
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...