Re: VPN between Pix501 and 1761,can ping but nothing else???

jasonhumes · ‎05-02-2005

Hi

We've got 4 sites, two are using cisco 1761 routers with three interfaces (LAN, WAN, VOICE) and two sites with pix 501 (LAN, WAN). I've got vpn tunnels configured between all sites to fully mesh all subnets. The problem is, I can access any resources at any site through the vpn tunnels, except for a PBX (or any other device for that matter) which is sitting on the VOICE subnet of our main office. We can ping the PBX and the other devices on that VOICE subnet, but cannot browse the web configuration page, or ssh to the box either...I've tried to portscan this pbx through the tunnel and no ports show as open, yet if I portscan it from the same subnet or through the same router (ie, from the LAN side) it shows port 80, 1720, etc. all open. I've attached the configs from one pix site and the main office router config. ANy ideas as to what is happening here...I've configured many vpn tunnels between all sorts of boxes and never seen anything like this. Thanks.

jason

rmihalcin · ‎05-02-2005

Jason,

I believe your problem is access-list related. My experience is that the peers must have mirrored images of the access-lists. I looked at the 2 devices an I don't see mirrored images:

router acl's

ip access-list extended VPN-QMMI

permit ip 192.168.60.0 0.0.0.255 192.168.62.0 0.0.0.255

permit ip 192.168.160.0 0.0.0.255 192.168.62.0 0.0.0.255

ip access-list extended VPN-QMOC

permit ip 192.168.60.0 0.0.0.255 192.168.63.0 0.0.0.255

permit ip 192.168.160.0 0.0.0.255 192.168.63.0 0.0.0.255

permit ip 192.168.69.0 0.0.0.255 192.168.63.0 0.0.0.255

ip access-list extended VPN-QMSC

permit ip 192.168.60.0 0.0.0.255 192.168.61.0 0.0.0.255

permit ip host 216.8.137.207 192.168.61.0 0.0.0.255 ?? odd

permit ip 192.168.160.0 0.0.0.255 192.168.161.0 0.0.0.255

permit ip 192.168.60.0 0.0.0.255 192.168.161.0 0.0.0.255

permit ip 192.168.160.0 0.0.0.255 192.168.61.0 0.0.0.255

permit ip 192.168.69.0 0.0.0.255 192.168.61.0 0.0.0.255

permit ip 192.168.69.0 0.0.0.255 192.168.161.0 0.0.0.255

pix acl's

access-list ipsec permit ip 192.168.63.0 255.255.255.0 192.168.60.0 255.255.255.0

access-list ipsec permit ip 192.168.63.0 255.255.255.0 192.168.160.0 255.255.255.0

access-list ipsec permit ip 192.168.63.0 255.255.255.0 192.168.69.0 255.255.255.0

access-list ipsec2 permit ip 192.168.63.0 255.255.255.0 192.168.62.0 255.255.255.0

access-list ipsec3 permit ip 192.168.63.0 255.255.255.0 192.168.61.0 255.255.255.0

access-list ipsec3 permit ip 192.168.63.0 255.255.255.0 192.168.161.0 255.255.255.0

Look here first. It's a start.

Bob

jasonhumes · ‎05-02-2005

Hi

Well, the crypto access-list which is applicable to the connection in question is, on the router VPN-QMOC, and on the pix its IPSEC. Those two lists ARE a mirror of each other. I just find it odd that ICMP traffic would match the crypto and no-nat access lists, at both sites (meaning I can ping in both directions with NO problems at all), yet I cant establish any TCP or UDP based connections. (update, I can connect to a web server at the PIX site, from the VOICE subnet with the troubles, yet I cant establish a connection with the web server on the VOICE subnet from the PIX site)...any other ideas. The PIX is a 10 user, des/3des, 10 IKE endpoint license....just in case...THanks very much...I'm sooo stumped.

rmihalcin · ‎05-03-2005

Jason,

The only other item that comes to mind is that the

pix will not forward a packet recieved on its inside

interface to another device on the inside interface.

ie a redirect. A router will. Any windows route add statements on the remote pix devices ? Dhcp giving

out the correct gateway on the voice vlan ? overlapping address space, subnet masks correct?

This stuff works, so it's got to be something simple.

On the remote pix issue the commands

logging on

logging buffered debug

attempt a session

and see if the logs show something

Bob

jasonhumes · ‎05-03-2005

Hi

So this is very strange...How is TCP/UDP any different, in the eyes of IPSec, from ICMP? I am able to ping all sites, yet from the pix site to the VOICE subnet at the main office, still cant communicate via TCP/UDP. If I do a "show crypto ipsec sa" on the pix it shows packets being encrypted, encapsulated, and digested...and on the VOICE subnet if I do the same command I see those packets being decrypted, decapsulated and verified...yet no return encap, encrypt, digest for the communication. Its odd that the pix site can communicate, with no problems, to the LAN off of the same router via the IPSec tunnel, but not the VOICE subnet off the same router, and the only thing I've done is added a line to the crypto access list and nonat access list. One thing, I dont want the voice subnet going out to the internet, so should I have to put an "ip nat inside" and "ip inspect" statement on the VOICE interface, and if NO, should I have to include this VOICE subnet in the nonat access-list? Thanks.

jasonhumes · ‎05-03-2005

OK

I opened a TAC case and found that I had to allow the private addresses through the outside access-list. Strange eh?!? Has anyone else ever had to do that to make an ipsec tunnel work with a router? I've never seen that, and I feel that it violates security best practices by allowing private addresses inbound on an internet facing interface. But I got it working none the less. Thanks.

jasonhumes · ‎05-03-2005

The reason I could ping but nothing else is that I allow all icmp on the internet facing access-list. Thanks.

rmihalcin · ‎05-03-2005

Jason,

Glad to hear you got it working. There must be something software related to the Dialer interface.

I wonder if you put the crypto map mymap on the physical interface E0, in addition to the dialer interface if it would work without the access-list changes. I know in older versions of code one used to have to put the crypto maps on the physical and the virtual (ie tunnel) interfaces to get it to work.

Bob