«

running 6.3(3)

after adding a second tunnel on a crytpo map applied to outside I can no
longer ssh from the internet. I can however ssh to it via another box
on the outside int net.

any ideas?

On Wed, 10 Dec 2003 16:54:17 -0600, Bill F wrote:

> running 6.3(3)
>
> after adding a second tunnel on a crytpo map applied to outside I can no
> longer ssh from the internet. I can however ssh to it via another box
> on the outside int net.
>
> any ideas?

Answer most likely lies in the match address for new crypto map policy.

the new crypto map entry sets up a tunnel between the pix outside and an
fe port on the gateway router (this was necessary to allow the vpnclient
users to pass traffic across the other tunnel on the pix to a remote
pix. the acl just covers the vpnclient addresses and the pix inside
lan. So I still don't understand how this would affect ssh access to
the pix outside int address.

Rik Bain wrote:
> On Wed, 10 Dec 2003 16:54:17 -0600, Bill F wrote:
>
>
>>running 6.3(3)
>>
>>after adding a second tunnel on a crytpo map applied to outside I can no
>>longer ssh from the internet. I can however ssh to it via another box
>>on the outside int net.
>>
>>any ideas?
>
>
> Answer most likely lies in the match address for new crypto map policy.

In article <>,
Bill F <__> wrote:
:the new crypto map entry sets up a tunnel between the pix outside and an
:fe port on the gateway router (this was necessary to allow the vpnclient
:users to pass traffic across the other tunnel on the pix to a remote
ix. the acl just covers the vpnclient addresses and the pix inside
:lan. So I still don't understand how this would affect ssh access to
:the pix outside int address.

We don't understand either, but you aren't giving us hard configuration
information to work with.

I would suggest that if you have a CCO account that you run your
configuration through the Cisco Output Interpreter at
http://www.cisco.com/go/tools . And if that doesn't show anything
useful, open a TAC case about it.

If you don't have a CCO account or SmartNet then you should probably
either give up or post a lightly-sanitized copy of your configuration.
--
"WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG"
WHEN QUINED, YIELDS A TORTOISE'S LOVE-SONG. (GEB)

name x.x.136.226 colopix
name x.x.132.73 gwrouter
object-group network officelan
network-object x.x.4.0 255.255.255.0
object-group network cololan
network-object x.x.14.0 255.255.255.0
object-group network vpnclients
network-object x.x.30.0 255.255.255.0
access-list vpntocolo permit ip object-group officelan object-group cololan
access-list nonat permit ip object-group officelan object-group cololan
access-list nonat permit ip object-group officelan object-group vpnclients
access-list outside_in permit icmp any any echo-reply
access-list vpnclients permit ip object-group officelan object-group
vpnclients
ip address outside x.x.132.74 255.255.255.252
ip address inside x.x.4.2 255.255.255.0
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 x.x.4.0 255.255.255.0 0 0
access-group outside_in in interface outside
route outside 0.0.0.0 0.0.0.0 gwrouter 1
sysopt connection permit-ipsec
crypto ipsec transform-set e3ds esp-3des esp-sha-hmac
crypto map psprint1 1 ipsec-isakmp
crypto map psprint1 1 match address vpntocolo
crypto map psprint1 1 set peer colopix
crypto map psprint1 1 set transform-set e3ds
crypto map psprint1 2 ipsec-isakmp
crypto map psprint1 2 match address vpnclients
crypto map psprint1 2 set peer gwrouter
crypto map psprint1 2 set transform-set e3ds
crypto map psprint1 interface outside
isakmp enable outside
isakmp key ******** address colopix netmask 255.255.255.255
isakmp key ******** address gwrouter netmask 255.255.255.255
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh 0.0.0.0 0.0.0.0 inside

In article <>,
Bill F <__> wrote:
:name x.x.136.226 colopix

That configuration looks okay from here.

What do you see if you turn ssh debugging on? And are you getting
log messages about traffic having been discarded because it needed
to be protected by IPSec?
--
Sub-millibarn resolution bio-hyperdimensional plasmatic space
polyimaging is just around the corner. -- Corry Lee Smith

Walter Roberson wrote:
> In article <>,
> Bill F <__> wrote:
> :name x.x.136.226 colopix
>
> That configuration looks okay from here.
>
> What do you see if you turn ssh debugging on?

nothing.


BTW, I've tried accessing both the outside interface in the clear and
the inside interface while vpnclient'd in to the gwrouter.

it was an ip inspect rule on the same interface as the tunnel. once i
removed that it worked. incidentally that was also dropping return
traffic to vpnclient hosts that were terminating on an outside int of
the router and then getting encrypted again on an inside int. of the
same router. still not sure exactly why the traffic was getting dropped
as I thought cbac and ipsec could co-mingle to a certain degree.

Bill F wrote:
>
>
> Walter Roberson wrote:
>
>> In article <>,
>> Bill F <__> wrote:
>> :name x.x.136.226 colopix
>>
>> That configuration looks okay from here.
>>
>> What do you see if you turn ssh debugging on?
>
>
> nothing.
>
>
> BTW, I've tried accessing both the outside interface in the clear and
> the inside interface while vpnclient'd in to the gwrouter.
>
>