PIX match address in VPN

[andrey.v.tyurin]

Hollo all,

I can do two configuration of vpn channel on PIX 535,

the first is:

crypto ipsec transform-set P2Pset esp-des esp-md5-hmac

isakmp identity address

isakmp policy 9 authentication pre-share

isakmp policy 9 encryption des

isakmp policy 9 hash md5

isakmp policy 9 group 5

isakmp policy 9 lifetime 86400

isakmp enable VPN

crypto map P2Pmap 10 ipsec-isakmp

crypto map P2Pmap 10 match address P2P2

crypto map P2Pmap 10 set pfs group2

crypto map P2Pmap 10 set peer 212.212.212.212

crypto map P2Pmap 10 set transform-set P2Pset

isakmp key ******** address 212.212.212.212 netmask 255.255.255.255

access-list P2P2 permit ip 172.16.0.0 255.255.255.0 10.1.1.0 255.255.255.0

#but I want to pass only 172.16.0.0/26 and 172.16.0.128/27 and dont want to pass other networks in 172.16.32.0/24 and that's why i do access list on the VPN interface like this:

access-list VPN permit tcp 10.1.1.0 255.255.255.0 172.16.0.0 255.255.255.192

access-list VPN permit tcp 10.1.1.0 255.255.255.0 172.16.0.128 255.255.255.224

access-list VPN deny ip any any

and the second is :

crypto ipsec transform-set P2Pset esp-des esp-md5-hmac

isakmp identity address

isakmp policy 9 authentication pre-share

isakmp policy 9 encryption des

isakmp policy 9 hash md5

isakmp policy 9 group 5

isakmp policy 9 lifetime 86400

isakmp enable VPN

crypto map P2Pmap 10 ipsec-isakmp

crypto map P2Pmap 10 match address P2P2

crypto map P2Pmap 10 set pfs group2

crypto map P2Pmap 10 set peer 212.212.212.212

crypto map P2Pmap 10 set transform-set P2Pset

isakmp key ******** address 212.212.212.212 netmask 255.255.255.255

access-list P2P2 permit ip 172.16.0.0 255.255.255.192 10.1.1.0 255.255.255.0

access-list P2P2 permit ip 172.16.0.128 255.255.255.224 10.1.1.0 255.255.255.0

access-list VPN permit tcp 10.1.1.0 255.255.255.0 172.16.0.0 255.255.255.192

access-list VPN permit tcp 10.1.1.0 255.255.255.0 172.16.0.128 255.255.255.224

access-list VPN deny ip any any

and the question is: It is same or not

[Jon Marshall]

Hi

To all intents and purposes it will have the same result yes but it is not the same.

Your first one will allow a VPN tunnel to be setup for any traffic coming from 172.16.0.0/24 to 10.1.1.0/24.

However your access-list will then filter the traffic that is not part of the 172.16.0.0/26 and 172.16.0.128/27 networks.

Note - it will filter it providing you haven't got "sysopt connection permit-ipsec" in your config.

the second one won't even allow a VPN tunnel to be formed unless it is coming from 172.16.0.0/26 or 172.16.0.128/27.

For efficiency i would use the second one.

HTH

Jon

[andrey.v.tyurin]

Ok Jon, thank you!

[jerrytozhang]

I don't think access-list VPN gonna work properly.

Because the vpn traffic is already get encrypted before hit access-list VPN, the ip address on the IPSec packets head is the outside interfce public ip address.

[Jon Marshall]

Hi Jerry

The VPN access-list is the access-list applied to the outside interface in an inbound direction. It is not the crypto access-list.

So it will work because the traffic is received by the outside interface, decrypted (optionally natted) and then compared to the access-list.

HTH

Jon

[jerrytozhang]

Yeah, Jon:

If you enable sysopt connection permit-ipsec or sysopt connection permit-vpn on your PIX box,the IPSec traffic from internet will bypass interface ACLs. But after decryption, I'm not sure it will hit those ACLs again or not, can you kindly provide us a URL for this ?

[Jon Marshall · Accepted solution]

Hi Jerry

If you enable sysopt connection permit-ipsec then you are right the traffic after being decrypted is not checked against the acl on the interface that the IPSEC traffic was received on.

If you disable sysopt conneciton permit-ipsec then the traffic is decrypted and then checked against the acl that is on the interface the IPSEC traffic was received on. The command reference for pix v6.x says as much

http://www.cisco.com/en/US/docs/security/pix/pix62/command/reference/s.html#wp1026942

I think we may be saying the same thing here :)

Jon