Site to Site VPN troubleshooting and debugging help

[marioderosa2008]

Hi guys,

i have an IPSec VPN between a Cisco PIX501 and a ASA5505.

Clients behind the PIX501 can communicate with CLients behind the ASA5505 fine, but they do not seem to be able to access a web server in the DMZ.

Looking at my config, I can see the ACL used in the crypto map and it does state both networks as interesting traffic.

Are there any debug commands i can use that can help me find out where the packet is being dropped?

I have used the ASDM on the ASA to mintor realtime traffic flow and I cannot see any deny tcp statements appear when I attempt to connect to the webserver. So I am thinking that there is an issue with my IPSec tunnel config.

I dont think they have ever needed to do this before so I am thinking that it is a new requirement. Failing that, I could use a packet sniffer on the web server to see if the webserver ever receive the packets. But i'd still like to know if my IPSec tunnel is not dropping anything.

Any advice appreciated!!

Mario

[stuart]

Hi,

Can you post some sanitised configs for review?

Where is the DMZ in relation to the VPN and the devices?

I also take it that the vpn is establishing successfully?

Stu

[busterswt]

If you do a 'show ipsec sa detail' on the ASA or PIX do you see an SA created for both networks (inside and dmz)? Are both networks defined in the crypto ACL on both firewalls? Are they both defined in the NAT exemption ACL on both firewalls (if you have one)? Do you have port restrictions in place on either firewall?

[marioderosa2008]

thanks for your response guys...

right, I have noticed that after issuing the sh ipsec sa detail command on the ASA at HQ, i can see an SA created for the Local LAN range but not the DMZ.

I have compared this to the other Site to Site vpn link we have to another ASA and this indeed does include the DMZ. So i think that is the problem.

Now, I am not sure how I would go about resolving this using the CLI.

To give you guys more of an idea of the setup...

we have our corporate HQ LAN on 192.168.10.x and the DMZ on 192.168.20.x

a remote branch office has a LAN ip range of 192.168.11.x (No SA entry for DMZ)

another remote branch office has a LAN ip range of 192.168.60.x (Which does have a SA entry for the DMZ).

Is there any more information that you guys might require before assisting me with the changes that i need to make?

Mario

[marioderosa2008]

Hi,

i have been doing more digging in to this and i'm confused.

the crypto acl's configured permit traffic from an object list called DM_INLINE_NETWORK_1 to the relevant remote branch LAN i.e. 192.168.11.0/24

When looking at what the DM_INLINE_NETWORK_1 includes, it includes the Local LAN & DMZ.

So it appears that the crypto map does specify a crypto acl that includes the local lan and DMZ to the remote branch offices.

Even though the output of the shipsec sa detail command does not show an entry for the DMZ network.

Now i'm lost.

I am going to use a packet sniffer on the web server in the DMZ to see if packets from the remote branches are being recieved by the webserver. Unless there is any debugging commands that you know of which can show me that packets are being dropped due to the firewall not recognising the traffic as being interesting?

Thanks for your help so far!

Mario

[busterswt]

Hi Mario,

Check to make sure that the remote branches contain the DMZ network in *their* crypto ACLs as well. If you are using a NAT exemption ACL be sure that the DMZ network is listed there on the HQ firewall and remote branch firewalls. You must generate some interesting traffic to/from the DMZ for that SA to be built. Do you have any port restrictions in place? Please verify sysopt is enabled/disabled by running the command 'sh run all sysopt' and look for 'sysopt connection permit-vpn or permit-ipsec'. If you're able to post a sanitized config of the HQ fw and a branch fw that would be great.

James