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
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.
Sorry - I thought you wanted to SSH to the ASA, ignore my previous post!
To use SSH on the 1841 - you need a crypto IOS, do you have a crypto IOS on the router - it will have a "K9" in the IOS file name?
Lets see if we can help out again!
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!
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.
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.
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.