Michael,

Thank you for your response. I will try to explain why they overlap...

Our client has given us the range 192.168.100.0 255.255.255.248 to participate on their network, 192.168.100.0 255.255.255.0. Therefore if the overlapping ACLs is the problem (in which I suspect you are correct) how do I get around this?

Again, thanks in advance for your help!

Steve

First, make sure you correct the mask in the crypto ACL, per my other post.

You should check with the other admin and make sure your crypto ACLs are exact mirrors of each other. It wouldn't be a bad idea to put a sniffer on the WAN side to see if you can detect asymmetrical operation (packets that should be encapsulated, but are not).

It looks like the pool (192.168.100.0 255.255.255.248) is not part of a policy push from the other crypto endpoint.

Are they actually using a /24 mask on their side, or is that an assumption on your part?

Could it be that they are actually using a mask greater than /24 so as to not have an overlap?

My concern was how a host on the far side with a /24 mask would initiate/respond to a host on your side. The host on their side would ARP your host believing it was directly reachable, due to the mask.

Perhaps this might be resolved with "ip proxy-arp" configured on the internal interface of their router.

Is their 192.168.100.0 /? network the connected network on the inside of their router, or buried deeper in their topology?

Michael,

Thanks for your help, I will be in contact with the remote admin tomorrow, I will find out that the ACLs definately mirror / subnet masks etc. Also the wildcasd mask mistake in the original post was my typo, not from the 'live' config.

I'll keep you and the board posted on my progress.

Steve

Michael,

Just to let you know that Phase 2 of the VPN negotiation was failing, as there was a mis-match in the transform set. Once this was recified traffic flow started as expected!...Thanks for you help.

Steve

Steve:

An earlier post indicated:

"I can see that the VPN establishes but no traffic seems to go down the tunnel, when I run a 'sho cry ips sa' I see various a number of send errors."

You might want to revise the criteria that you were you using, that lead you to erroneously conclude that the VPN was being established.

I suspect the "sh crypto ipsec sa" output for that protected flow, would not have had SPIs listed under the the "inbound esp sas:" and "outbound esp sas:" sections, if Phase 2 had not completed successfully. However, that is an "opinion".

Glad you were able to bring the situation to a successful conclusion.