PIX - to - PIX : crypto-map pushing all traffic to tunnel

[jpittman]

Good morning:

This is my first time attempting to build a PIX to PIX VPN and I'm having the following issue when i paste my config into the host (a 525, 6.2.1).

The issue:

After pasting the config below into the Host PIX, i'm unable to reach any network through the outisde interface (networks not covered by the crypto acl). It seems that all traffic, trying to browse www.cisco.com for example, is being pushed into the IPSec tunnel.

My question is, why? What am I missing? I thought that the crypto acl only pushed traffic that matches its permit statement(s) into the tunnel, correct?

Removing the crypto map configurations immediately restores "normal" traffic patterns.

The new VPN config section:

access-list 101 permit ip a.a.a.a 255.255.255.0 b.b.b.b 255.255.255.0

access-list 102 permit ip a.a.a.a 255.255.255.0 b.b.b.b 255.255.255.0

nat (inside) 0 access-list 102

sysopt connection permit-ipsec

crypto ipsec transform-set PIX01 esp-3des

crypto map VPN 10 ipsec-isakmp

crypto map VPN 10 match address <acl 101>

crypto map VPN 10 set transform-set PIX01

crypto map VPN 10 set peer <peer IP address>

crytpo map VPN interface outside

isakmp enable outside

isakmp key <key string> address <outside int of peer> netmask <mask>

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash sha

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

Obvisouly, the Host is a pre-existing firewall and has had extensive configuration already. If anyone wants to see, i can post that after modifications.

I'm interested in reading any/all thoughts and comments.

Thanks,

Jason

[mnaveen]

Hi Jason,

Just a thought passing in the mind. How did you verify that traffic to www.cisco.com is going through the IPSec tunnel. I don't think this can happen unless covered in the crypto access-list. Also because you are not creating an IPSec tunnel b/n ur network and www.cisco.com, it is unlikely that traffic does goes through the tunnel.

To check whether the access-list is creating any problem, check the following.

1. Check if the IPSec SAs are up (use "show crypto eli"). SAs will come up only when interesting traffic specified in the crypto acl is sent thorough the pix.

2. Modify the crypto acl to include only the hosts (pix-to-pix). That is, access-list 101 permit ip host host . Now the only traffic that should be encrypted will be traffic generated from these two hosts. Do a ping after the configuration on both pixes and this should bring up the SA. Now send traffic from network a.a.a.a to b.b.b.b this should go unencrypted. Check for "show crypto engine connection active" command on both sides to see how many packets are getting encrypted and decrypted.

If this is behaving as expected then the next thing is to check for the NAT configs. Hope you know that NAT-T should be used when IPSec is being used.

Keep us posted. If something comes up, i'll let you know.

Thanks,

Naveen.

[jpittman]

Naveen,

Thanks for the comments. A few more questoins/comments...

After re-reading my original post, i think my problem might not be too clear.

Here are steps that i hope clarify (apologies):

1. i apply the configuration noted in my oringinal post to my host PIX.

2. i try to browse a site (again, just for example www.cisco.com).

3. the browser returns a "page cannot be displayed" error

4. i remove the config (specificaly, just the crypto map)

5. browsing to the same site a second time is successful.

i assume(d) that the traffic is somehow identified as interesting by the crypto access list (which, should be LAN network address A to network address LAN B, correct?). I've not yet setup the remote PIX, as it will do me no good without being able to configure the VPN on the host PIX first.

Curious question: In theory, what could cause an acl such as < access-list 100 pemit ip 10.1.1.1 255.255.255.255 192.168.169.0 255.255.255.255 > to idenitfy traffic that is for a network other than < 192.168.169.0/24 > as interesting?

I'll try you troubleshooting hint soon...thanks!

Also, unfortuntately b/c the unit is a production host device, i wasn't able to run extensive debug diagnostics. I did however run debugging long enough (ipsec, isakmp, and engine) to see that trying to browse to the example website w/ the config in place initiated IPSec SAs.

Lastly, you mention NAT-T...correct me if i'm mistaken, but doesn't the NAT 0 statement cover that?

Again, i look forward to reading your comments and thoughts.

Thanks,

Jason

[jpittman]

*bump*

[mnaveen]

Hi Jason,

My apologies for overlooking the NAT-0 statement. The ACL access-list 100 pemit ip 10.1.1.1 255.255.255.255 192.168.169.0 255.255.255.255 theoritically says that "All IP traffic originating from 10.1.1.1 (host) and going to 192.168.169.0/24 (network) are interesting and hence should be IPSec protected. All other traffic should go as clear-text traffic". It's just an access-list. Whatever traffic matches the access-list will be considered interesting.

Unless you check on the PIX that packets to www.cisco.com are getting encrypted, we can't be sure of the working of access-list. Please verify and keep us posted.

Naveen

mnaveen@cisco.com

[jpittman]

Naveen,

Because this unit is a production firewall, I am compelled to wait until this evening to perform further diagnostic. I will run debugging and pass along the results.

In the mean time, can you (or anyone) provide supported theory(ies) as to what the possible cause could be?

HYPOTHETICALS

If we concede that all traffic is being encrypted (not just the traffic outlined in the crypto acl), then what? What could be the possible causes and subsequent resolutions?

If non-interesting traffic (meaning, traffic that doesn't fit the crypto acl rule) is not being encrypted, then why would outbound traffic to non-interesting networks cease to be passed when i paste in my "VPN" config?

Are there any holes in my configuration?

I'm just curious as to what "possibles" may exist...that way, at least i'm not wasting time until i can actually run more diagnostics. :)

thanks,

jason