Can't ssh from inside the ASA to remote vpn endpoint

Unanswered Question
Mar 23rd, 2009
User Badges:
  • Bronze, 100 points or more

Hey,


I have a l2l tunnel between an ASA and 1841. The tunnel works well, however I'm unable to ssh to the 1841 through the vpn tunnel, from inside. I can ssh to the 1841 via MPLS.


Oh, I can VNC to remote workstations through the tunnel.



ACL on ASA...

access-list insideGoingOut extended deny tcp any any eq smtp

access-list insideGoingOut extended deny tcp any any eq pop3

access-list insideGoingOut extended deny tcp any any eq 995

access-list insideGoingOut extended deny tcp any any eq 465

access-list insideGoingOut extended deny tcp any any eq 587

access-list insideGoingOut extended permit ip any any


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
Loading.
DialerString_2 Tue, 03/24/2009 - 06:52
User Badges:
  • Bronze, 100 points or more

Andrew,


I'm trying to ssh to the 1841. So - are you saying I would still need to configure ssh on the ASA to access the 1841 and if so why?


I have SSH configured on my ASA to allow access from the inside network.


Thanks Andrew and I recognize your profile and you've helped me out before.

DialerString_2 Tue, 03/24/2009 - 07:51
User Badges:
  • Bronze, 100 points or more

Thank for the reply Andrew and yes, I have a crypto ios on the 1841. I can ssh to the 1841 all day long, but only if it's not through the vpn tunnel. I have MPLS sitting on the s0/0/0 interface and I can ssh the 1841 through MPLS.


It's the rotten tunnel that's giving me trouble. I'm starting to think it may be fragmentation of some sort, but I don't know enough about this, so I'm guessing.


I really don't feel bad (yet) b/c TAC is bewildered and they say the configs are good!!!!! You know what's weird? If I run debug ip ssh (on the 1841) and try to ssh through the vpn tunnel, I get no output BUT if I debug ip tcp transaction and try ssh I get output that states:


Mar 23 17:39:24.534: TCP0: Connection to 10.1.21.143:1734, advertising MSS 536 CHICAGO(config-if)# Mar 23 17:39:24.574: TCP0: bad seg from 10.1.21.143 -- bad sequence number: port 22 seq 3397382467 ack 1284783142 rcvnxt 1516030757 rcvwnd 4128 len 0 CHICAGO(config-if)#

Mar 23 17:39:26.537: 10.1.72.1:22 <---> 10.1.21.143:1734 congestion window changes

Mar 23 17:39:26.537: cwnd from 536 to 536, ssthresh from 65535 to 1072 Mar 23 17:39:26.537: TCP0: timeout #1 - timeout is 4000 ms, seq 201990093 Mar 23 17:39:27.530: TCP0: bad seg from 10.1.21.143 -- bad sequence number: port 22 seq 1186711579 ack 0 rcvnxt 1516030757 rcvwnd 4128 len 0 CHICAGO(config-if)# Mar 23 17:39:27.570: TCP0: bad seg from 10.1.21.143 -- bad sequence number: port 22 seq 3068063290 ack 1493517563 rcvnxt 1516030757 rcvwnd 4128 len 0 CHICAGO(config-if)# Mar 23 17:39:30.543: TCP0: timeout #2 - timeout is 8000 ms, seq 201990093


10.1.21.143 is my workstation and I'm thinking I should try adjusting the mss to 536 but I don't know what problem that will cause with other traffic.

Mmmmm have you tried creating a loopback address in the same IP subnet and SSH to that?


The "advertising MSS 536" indicates this will not be an fragementation issue - as the packets will only be 536 + TCP/IP header + IKPSEC Header = max 632 bytes


The fact the debuig is indicating bad sequence numbers, could mean packet drops or congestion somewhere along the line!

DialerString_2 Tue, 03/24/2009 - 09:21
User Badges:
  • Bronze, 100 points or more

Thx for the reply, Andrew. I really didn't consider the packet drops b/c everything else is fine and I can RDP and VNC to workstations on the local land. -Either way, I'll try the loop back and look into the packet drops and when I figure this out, I'll let you know what the solution is.

DialerString_2 Wed, 03/25/2009 - 16:52
User Badges:
  • Bronze, 100 points or more

Andrew, I figured it out -finally- the ssh packets were traversing the vpn but on the way back, they were traversing the MPLS. So it was a routing loop.

Ushankar_78 Thu, 03/26/2009 - 02:20
User Badges:

Hi,


Is ASA ip allowed in 1841 for SSH access? If not then allow the ASA IP through which your traffic is going to access the 1841.


Check from the remote ends inside network whether you are able to take the SSh or not.


If you have syslog then you can findout the problem easily.


Udar

DialerString_2 Thu, 03/26/2009 - 07:11
User Badges:
  • Bronze, 100 points or more

U,


I figured it out -look back a couple of post. It was a routing loop and thx for the post

Actions

This Discussion