Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Site to Site VPN will only come up from one end.


We have a pix at our main site that is a central point for all site to site vpn's. there are currently about 25 site to stie VPN's working ok from this pix to cisco routers.

we have added another cisco router to a new remote site and altered the pix to accept the new site to site vpn.

the problem is that the vpn tunnel will only come up if it is initialized by the new office/site. once it is up, it works correctly. if you try and bring the tunnel up from the main site (pix), you get no response.

i have set up debugging on the remote cisco router and the out put is as attached. please can someone assist me, as i dont understand what the debug is trying to tell me, thanks.


Re: Site to Site VPN will only come up from one end.

on the remote site router, is there an inbound acl? if so, are these being permitted:

udp 500

udp 4500


New Member

Re: Site to Site VPN will only come up from one end.

Hi Jackko,

Thanks for replying so quickly.

The inbound access list for the site router is as follows:

access-list 100 remark ----- Inbound ACL -----

access-list 100 permit tcp any any eq 22

access-list 100 permit udp any any eq isakmp

access-list 100 permit icmp any any unreachable

access-list 100 permit icmp any any time-exceeded

access-list 100 permit icmp any any echo

access-list 100 permit esp any any

access-list 100 permit ip

access-list 100 deny ip any any log-input

Dialer interface config is as follows:

interface Dialer1

ip address negotiated

ip access-group 100 in

ip inspect firewall out

ip nat outside

ip virtual-reassembly

encapsulation ppp

no ip route-cache cef

no ip route-cache

no ip mroute-cache

dialer pool 1

dialer-group 1

ppp authentication chap callin

ppp chap hostname XXXXXX@XXXXXXX.XXX

ppp chap password 0 XXXXXXXX

ppp ipcp dns request

ppp ipcp mask request

crypto map vpn


ip classless

ip route Dialer1


Re: Site to Site VPN will only come up from one end.

i guess the best way to verify whether the issue is related to the inbound acl or not, is to permit ip any from the pix public ip.


access-list 100 permit ip any

CreatePlease to create content