Not hitting match-address ACL therefore routing out default

[m.surtees]

Hi,

Building a tunnel between a PIX (6.3) and a Nortel 1750 which is admin'd by a 3rd party. There are other issues with this but at the moment I'm trying to find out why traffic defined in the ACL used for the match address statement is seemingly not hitting - (hitcnt=0) - and therefore not buildind an SA ... it's just routing the traffic out the default interface (or trying to but can't find a translation group).

Here's what I got:

access-list acl.SEC-80 permit ip host 10.33.10.107 object-group 192.168.100.0 255.255.255.240

access-list NoNAT permit ip host 10.33.10.107 192.168.100.0 255.255.255.240

nat (SEC-80) 0 access-list NoNAT

!--- IPSec parameters.

crypto ipsec transform-set xSET esp-des esp-sha-hmac

crypto map xMAP 20 set pfs

crypto map xMAP 20 ipsec-isakmp

crypto map xMAP 20 match address NoNAT

crypto map xMAP 20 set peer 192.168.254.36

crypto map xMAP 20 set transform-set ODXSET

crypto map xMAP 20 set pfs

crypto map xMAP interface SEC-20

!--- IKE parameters.

isakmp enable SEC-20

isakmp key xxxx address 192.x.x.36 netmask 255.x.x.x

isakmp identity address

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption des

isakmp policy 20 hash sha

isakmp policy 20 group 1

isakmp policy 20 lifetime 3600

sysopt connection permit-ipsec

When I try to connect to a host e.g. 192.168.100.10 (which exists the other side of the Nortel) from my host 10.33.10.107 i get the following in syslog:

%PIX-3-305005: No translation group found for tcp src SEC-80:10.33.10.107/41440 dst inside:192.168.100.10/23

... however I'm not trying to get "inside", I'm trying to create an SA between 10.33.10.107 and 192.168.100.10 and have it tunneled out SEC-20 interface (without NATing).

Why is it ignoring the crypto cmds and perfoming default actions?

Any help much appeciated,

Mike

[mheusinger]

Can you change the access-list to

access-list acl.SEC-80 permit ip host 10.33.10.107 192.168.100.0 0.0.0.15

and try again?

Second thought: why does it refer to 192.168.100.10/23 in the log message? Is there anywhere else in the config a reference to 192.168.100.0 255.255.252.0?

Where do you route the packet to?

Hope this helps! Please rate all posts

Martin

[m.surtees]

Hi Martin,

Can't change the ACL as PIX OS does not use wildcard masks, only subnet masks. Nothing like good ol' cisco consistancy :)

It refers to 192.168.100.10/23 in the log msg as that is the address I tested a telnet session to from my 10.33.10.107 host.

As far as I know routing should not come into it; all previous experience with IOS VPN (not Pix though) works this way: If there is a match with the ACL used in the tunnel definition then the packet is encrypted and sent down the tunnel ... routing is bypassed.

If I do need to route what is my next hop? The VPN peer is not adjacent and if I used an ajacent device then the packet would not see it as it would be encapsulated.

I still think the issue lies with why the packet is not making a match with ACL ...?

Thanks anyways,

Mike

[mheusinger]

Hello,

somehow I got lost in my last post...

What I wanted to say is: where is 192.168.100.0/23 which equals 192.168.100.0 255.255.252.0 in your network or configurations?

In your ACL there is a different mask, which would be 192.168.100.0/28 ...

I assume the two VPN boxes should have the same networks allowed across the tunnel - not sure about the Netgear box, though, never worked with one.

So which network mask is right?

Hope this helps!

Regards, Martin

[m.surtees]

hi Martin,

After checking and re-checking all my details, and performing countless debugs i put to the Nortel admin party that "this was what I had ... It was right ... could they sort their side out by doublechecking and spending a little time on it"

Surprise, Surprise. It started working the next day but they said "We didn't change a thing, honest"

Anyways - issue solved and case closed. Thanks for your help

Mike

[mheusinger]

I guess they had gotten the mask configured wrong ...

Anyhow, Don´t worry, be happy! ;-)

Regards, Martin