IPSEC tunnel initialisation problem on PIX

[pit999]

HI!

I have pix525 in the center and cisco router (26xx) on the other side with ipsec-isakmp crypto map between. PIX crypto map is on the outside interface.

Then we send packet from far side to center (PIX inside interface) we get IPSEC tunnel after some negotiation procedure between router and PIX. Then we have IPSEC tunnel and can send packet from inside PIX interface to far side behind the router.

But if we have no IPSEC tunnel (it's expired for example) we CAN'T build it from PIX inside interface. We can see increasing of access-list counter in crypto map. We can debug crypto isakmp and crypto ipsec on PIX and see following strings:

pix1# IPSEC(sa_initiate): ACL = deny; no sa created

IPSEC(sa_initiate): ACL = deny; no sa created

IPSEC(sa_initiate): ACL = deny; no sa created

IPSEC(sa_initiate): ACL = deny; no sa created

So I should to send one packet from far side to center to build tunnel and try never to loose it :)

Could anyone help me?

[srittenberg]

you are using: isakmp enable outside correct? The tunnel supose be established on the outside interface. why do you want to establish the tunnel inside anyway?

[pit999]

I have packet that goes from some network before PIX - through PIX from inside to outside interface - through some IP cloud to remote Cisco26xx with crypto map. Is it reason to build IPSEC tunnel? I suppose yes. Am I wrong?

[srittenberg]

Yes, you need to build site-to-site ipsec tunnel (I assume the IP cloud is public). The tunnel is between PIX's outside interface and the router's interface (outside). When the packet reaches the inside interface of the PIX, it's already been encrypted (access-list permit) and it's considered internal or the packets are established from the inside.

[pit999]

Unfortunately, my English is not perfect. That's why I didn't understand you :(

So, what should I do to solve my problem?

May be I should to place crypto map on PIX inside interface and do it isakmp enable?

[maik.behley]

I think this entry do not match your access-list. You must add a NAT 0 entry, because the IPSEC tunnel can not establish with NAT.

In the configuration you must have an access-list entry for your vpn connection.

See this example for the pix:

access-list 100 permit ip 192.168.168.0 255.255.255.0 192.168.170.0 255.255.255.0

nat (inside) 0 access-list 100

[pit999]

I have such a string in configuration:

nat (inside) 0 0.0.0.0 0.0.0.0 0 0

[rdennis]

You need to take out the "nat (inside) 0.0.0.0 0.0.0.0 0 0 entry in your config

[pit999]

But why?

As I remember it was initial configurator that asked me if I will use NAT, I replied NO and that string in config appeared.

From the other side - I still have to use NAT but in the same address.

Do you think I should remove that string?

[saluko]

Could you 'cut and paste' all your nat and acl config so that we can analyze them.

[pit999]

nat (inside) 0 0.0.0.0 0.0.0.0 0 0

That's all about NAT.

My troubles are from interface Videoconf-10 with security30 to outside interface CIN-5 with security0.

On interface Videoconf-10 I have acl:

access-list Videoconf-10_in permit ip any any

access-list Videoconf-10_in permit ip 10.4.78.0 255.255.255.0 host ViaVideo

And a couple of "static" sentences:

static (Videoconf-10,CIN-5) VideoStation VideoStation netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) SOmeVideo SOmeVideo netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) Polyspan2 Polyspan2 netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) Polyspan1 Polyspan1 netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) MCU1 MCU1 netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) Accord1 Accord1 netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) Accord2 Accord2 netmask 255.255.255.255 0 0

static (Videoconf-10,CIN-5) Accord3 Accord3 netmask 255.255.255.255 0 0