05-12-2012 06:08 AM
I have a 2951 router with switch and sec pac. I have multiple servers connected to the router. To access the servers via ssh and sftp I VPN into the router and then I can shell in using private ip's. Up until a couple of days ago this has worked. I am not clear on how but a possible cause... I have been in the process of moving our DNS name servers from our local network to a distributed external network. After verifying a successful transition I came to one of the final stages = shutting down the named service on our local servers. It was a day after this action that I couldn't gain ssh or sftp access to my servers via the VPN connection. I have VPN access. I am able to access web services on the servers but no ssh access when connected to router.
I did some exploring on possible issues/solutions and noticed that a router global config had old ip name-server data. So I added the IP address of our new name server and added the use of tcp and udp eq domain to our access list. This did not fix the problem. This is a bit confusing on why this change would cause this type of issue since I use private IP's (not domains) when accessing the servers but this is the only change I can think of that was made and coinsides with this issue.
here is my config... (i marked with bold text the additions I made to access list and ip name-server)
IP ending in .226 is router IP. Old named servers IP ending in .227 + .228
thanks for any assistance / knowledge
I am removing configuration due to it not being needed to resolve this issue.
Solved! Go to Solution.
05-12-2012 06:01 PM
Interesting problem.
One possible relation to the dns change is that it is not possible for the external dns to (correctly) resolve the pool addresses. If your ssh requires reverse dns resolution as a security measure, connections will be refused.
A static entry in the hosts file may do the trick already.
You can also check the event log on the server(s) to see if there are messages related to the failing sessions.
These may point you to a possible cause and from there to a solution.
regards,
Leo
05-12-2012 06:01 PM
Interesting problem.
One possible relation to the dns change is that it is not possible for the external dns to (correctly) resolve the pool addresses. If your ssh requires reverse dns resolution as a security measure, connections will be refused.
A static entry in the hosts file may do the trick already.
You can also check the event log on the server(s) to see if there are messages related to the failing sessions.
These may point you to a possible cause and from there to a solution.
regards,
Leo
05-14-2012 05:59 AM
Good Insight Leo,
It is an issue with ssh authenticating the server to allow the connection. If I am thinking about this correctly, shouldn't have adding tcp/udp eq domain action to the list for the router have resolved this issue (+ adding ip for new name server)?
05-14-2012 10:25 AM
It is an issue with ssh authenticating the server to allow the connection. If I am thinking about this correctly, shouldn't have adding tcp/udp eq domain action to the list for the router have resolved this issue (+ adding ip for new name server)?
Don't think so. Allowing dns lookups is a requirement but I do not think that is the problem here.
Your ip pool and router inside are private addresses. These cannot be validated via an Internet dns while it probably does not have a reverse entry for the host, just an A-record.
That's why you need to resolve them in a different manner, via a hosts file for example.
regards,
Leo
06-13-2012 08:39 AM
It turns out the dns being shut down was not the issue. The issue: I was away using a friends wi-fi that had the same IP pool (plus netmask) for internal net as I was using for my internal network behind the router . a change of the wi-fi network to use different ip pool did the trick.
Preston
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