Problem with Cisco 871 SSH Configuration

[rwatkinson]

I have been tasked with setting up remote offices with a VPN connection with the Cisco 871 router. I have configured the 871 as follows:

- Connect to VPN - Successful

- Allow connections via wireless (disabled for now) - Successful

- Allow the 871 to act as a DHCP server to limit addresses given - Successful

- Each remote 871 is given a different address to avoid conflicts - Successful

- Enable SSH for remote access - This is where I run into my problem.

We use DHCP here in our Corp. office as well in remote offices. Our Corp. office uses 192.9.1.x subnet for all servers, switches, etc., and 192.168.101.x and 192.168.102.x for computers, printers.

My problem is I can SSH to any of my remote 871s while on the 192.9.1.x subnet at anytime, but in order for me to SSH into these same devices while on the 101 or 102 subents, I have to do the following:

SSH to the remote 871 while on the 192.9.1.x subnet, perform an extended ping to the default gateway of one of those 2 subnets (101.1 and 102.1) from the BVI1 interface.

Once that ping is successful, I can than close the SSH connection from the 192.9.1.x subnet and connect to it from one of the other subnets (101.x and 102.x).

Also, until the ping from the BVI1 interface is successful to the default gateway of 101.1 and/or 102.1, I am unable to ping the remote 871 from either of those subnets. Only the 192.9.1.x subnet seems to have 24/7 access to ping and SSH.

I have attached my configuration.

ANY help would be greatly appreciated!!

Thanks!

[Pravin Phadte]

Hi,

have you tried without the radius config and acl 104 ?

Regards,

Pravin

[michael.leblanc]

Are we to assume that you are connecting to the 871's BVI1 interface with SSH?

Your crypto, NAT, and external interface ACLs all seem adequate to facilitate an SSH session (initiated from HQ) within the crypto tunnel.

Perhaps you are diagnosing the wrong end of the connection.

I'd also look at the WAN interface with a sniffer to confirm the presence of SSH connection initiation (from 101.1 and 102.1) when expected, and the responses from the 871.

Are you using the same SSH client and moving it from one subnet to another, or are you using different SSH clients (hosts) on the different subnets?

[rwatkinson]

I can not get any SSH or ping connections on the WAN interface until I perform an extended ping from the BVI1 interface.

I use PuTTY on a server on the main subnet (192.9) and PuTTY on my computer (which is on the 102.x network). I have checked and the settings for the PuTTY clients are exactly the same for each 871 we have.

My thought has always been an internal issue on our LAN (routing, firewall rule, etc), but the WAN Administrator has checked that and said everything is fine. My thought now is that the 192.9 network can connect because of the VPN tunnel it is keeping open (our VPN concentrator is on the 192.9 network). So therefore, a ping from BVI1 to the 192.9 default gateway is not necessary as the tunnel is performing the same function. I hope I am making sense of this. So, I am wondering if there is a way to perform a keepalive for certain subnets, i.e. can I have the 871 send a keepalive request (or ping) to the default gateway of the 101 and 102 subnets to avoid a timeout? Cause as I said before, once the ping has been performed from the BVI1 interface to the default gateway of the subnet, I can access the 871 via SSH until the timeout. If I keep a ping going from my PC (102.x) to the 871, the interface stays open and I can SSH, but if I stop and allow the connection to timeout, I have to perform the extended ping again.

Any ideas?

[michael.leblanc]

Including that info in the initial post would have been beneficial.

edit: It sounds like your WAN Administrator has configured ACLs, Inspection, or both (at HQ) to prohibit tunnel initiation from the 101 & 102 subnets (deliberately or erroneously).

Unless there is a specific (unstated) requirement for this, it should be provisioned such that the tunnel can be initiated from either end, and from any of the networks defined within the crypto protection suite.

If you want to initiate and sustain IPsec SAs from the remote side, you might consider using NTP to synchronize the 871's clocks with a clock at HQ, or implement IPSec + GRE tunnels and run dynamic routing updates through the tunnel.

[rwatkinson]

Sorry about not posting that at the beginning. I am more of a Desktop Support guy myself, so I wasn't sure what information would be helpful.

I am confused by the statement that my Admin has prohibited tunnel initiation from 101 and 102. If that were the case, I would not be able to get any SSH capabilities to the 871's from 101 and 102, correct? In other words, even though I can SSH to the 871 from the 101/102 subnets after I run the extended ping from the 871 BVI1 interface, he could still be prohibiting access?

According to my Admin, the 871 firewall/vpn rules are created as though they are just another extension of our DHCP LAN. He has looked over the firewall/routing aspect of our LAN a few times and insists that it has to be an issue with the 871 configuration.

Let me add a note that I just realized. From a laptop hooked up to an 871 (with a 871 DHCP given address of 192.168.100.100), I can ping all 3 subnets, but cannot ping the other 871 networks. However, even though I can ping my computer on the 102.x subnet from a laptop within the 871 network, I cannot ping the laptop within the 871 network from my PC.

Thanks for your assistance so far. I do appreciate it.

[michael.leblanc]

My interpretation of your post was that you felt that you needed to bring up the IPSec tunnel by triggering it with a ping from the remote side. My view is that you should be able to trigger it with traffic initiated from either end, and that if you can't, you should determine why that is.

I would clear the IPSec SAs (inbound and outbound) for the 102.x - 100.x protected flow from the SA database, then initiate an SSH connection from your 102.x host to the 871 (presumably BVI1, but you haven't confirmed that).

Then examine the SA database to confirm that new IPSec SAs are successfully created for the 102.x - 100.x protected flow, regardless of whether the SSH connection is successfully established or not. Determining whether the IPSec SAs are established will help you determine your next step.

If IPSec SAs are not successfully negotiated for this protected flow, your SSH connection initiation will fail due to the private destination IP address which requires the encapsulation to be provided by IPSec (ESP most likely). You would then need to identify why IPSec SAs could not be successfully negotiated.

If IPSec SAs are successfully negotiated, but SSH connection establishment fails, you will need to pursue that avenue of exploration.

It is important to note that it takes time to establish IPSec SAs, particularly when using a lower-end router like an 871. I would not necessarily expect the first SSH attempt to work.

The first packet that matches the crypto ACL entry for that protected flow will trigger the negotiation of IPSec SAs (assuming an ISAKMP SA already exists). If an ISAKMP SA does not exist, it will have to be negotiated first.

The time that is required to negotiate the required SAs may exceed the timeout for SSH connection setup.

Once the SAs exist, a subsequent SSH connection would be expected to succeed given no other configuration issues.

I would place a Sniffer on the WAN port and watch for any indication of asymmetrical operation (e.g.: SSH not being encapsulated within the IPSec tunnel). This could indicate an issue with non-mirrored crypto ACLs, or perhaps a NAT issue.

With regard to not being able to ping the laptop within the 871 network from your PC, you should determine whether that is within your security policy or not (i.e.: is it supposed to work, or is it denied by security policy).