VPN Tunnel

davidjkent · ‎10-05-2005

Hi , this is probably a dumb question but...

Assuming an IPSEC tunnel is in place and working.

The crypto access-list on PIX1

allows 1 host access to a large network

access-list crypto permit ip host 10.10.10.1 10.11.0.0 255.255.0.0

and PIX2 has the crypto access-list

permit ip 10.11.0.0 255.255.0.0 host 10.10.10.1

so all systems on 10.11/16 can access the single host 10.10.10.1.

This is not ideal as only a few 10.11 systems need access to the single host but the crypto access-list is configured like this for expediency. Not all systems which do need access to 10.10.10.1 are in place yet or their IP's are not currently known.

Without changing the crypto access-list how can I restrict access to 10.10.10.1 to only a handful of systems on the 10.11 subnet using an access-list on PIX1

Thanks

jackko · ‎10-05-2005

since you don't want to modify the existing no-nat and crypto acls, one way is to disable "sysopt connection permit-ipsec" on the pix1.

the command is enabled by default, pix will ignore any acls when examining encrypted traffic.

so if you diable this command, you can restrict the vpn tunnel with inbound acl.

e.g. on pix1:

no sysopt connection permit-ipsec

access-list 101 permit ip host 10.11.0.100 host 10.10.10.1

access-list 101 permit ip host 10.11.0.101 host 10.10.10.1

access-list 101 permit ip host 10.11.0.102 host 10.10.10.1

access-group 101 in interface outside

with the sample above, you don't need to modify the no-nat and crypto acl yet you can restrict the access. further you can even restrict the access down the the protocol and port level.

the catch is that by diabling "no sysopt connection permit-ipsec", it affects all vpn traffic. that means you need to create an inbound acl for remote vpn access as well, if there is any.

e.g. combine the previous acl 101, add this:

access-list 101 permit ip

jackko · ‎10-15-2005

just wondering how you go.

arunsing · ‎10-15-2005

The outside will see the ipsec traffic comming from the outside of the other pix. So the solution provided by jackko should not work as this is not a remote access tunnel but a lan to lan tunnel. I think the better and easier way would be to put the access list on the inside to permit all access-list on the inside interface. then deny the rest of the traffic to 10.10.10.1 and permit rest of the internet traffic. And enable sysopt connection permit-ipsec, other wise your tunnel will not get established.

access-list 101 permit ip host 10.11.0.100 host 10.10.10.1

access-list 101 permit ip host 10.11.0.101 host 10.10.10.1

access-list 101 permit ip host 10.11.0.102 host 10.10.10.1

access-list 101 deny ip any host 10.10.10.1

access-list 101 permit ip any any

access-list 101 in interface inside

As and when you have new hosts on the 10.11.0.0 network keep on adding the permit statements before the deny statement.

Thanks,

Arun

jackko · ‎10-15-2005

i agree that the way you suggested would work, but it's not going to satisfy the requirement.

have a second look at the original post, "Without changing the crypto access-list how can I restrict access to 10.10.10.1 to only a handful of systems on the 10.11 subnet using an access-list on PIX1". the requirement is to resolve the issue by applying an acl on pix1, not pix2. (i guess pix2 is being managed by another company)

further, just wondering if you are familiar with the command "sysopt connection permit-ipsec", may it's time to study the command reference guide.

arunsing · ‎10-15-2005

Jack on the outside of the pix the ip addresses 10.10.10.x and 10.11.x.x will be encapsulated. The ip addresses that the outside will see will be the outside of the pix1 and pix2. So there is no meaning for access-list as the outside will not even see 10.x.x.x ip addresses. And more over these ip addresses are non routable ip addresses.

Let me see if I can send you some sample config

jackko · ‎10-15-2005

very happy to discuss with you.

i guess the order is:

pix2 encrypts the packet

pix1 receives the packet

pix1 decrypts the packet

pix1 verifies the inbound acl

arunsing · ‎10-15-2005

Jack,

To make sure I'm understand this correctly...

PIX terminates a VPN on it's outside interface, or any interface with an

Internet addressable address With the sysopt command, traffic that

passes through that VPN tunnel from the remote site is not able to be

ACL'ed appropriately?

But would it not be ACL'able through it's source/destination components?

Source being the remote site's LAN address, destination being someplace

else behind the PIX.

Just a bit confused on what this command truly limits/enables.

The alternate for sysopt connection permit-ipsec will be to allow traffic for esp, AH and isakmp. So if you donot have sysopt connection permit-ipsec you will not be able to etablish the tunnel. So how can you pass the traffic

jackko · ‎10-15-2005

please excuse me for not being able to understand your interpretation.

as far as my knowledge goes, with sysopt connection permit-ipsec enabled, pix will ignore all acls for ipsec traffic. alternatively, with the command disabled, pix will then rely on the inbound acl to determine whether the ipsec traffic is legitimate or not.

also, just realised you works for cisco. maybe you can give it a go and test it at the lab.

davidjkent · ‎10-17-2005

Thanks for your replys guys,

sysopt connection permit-ipsec is enabled on the firewall PIX1 which is under my control Jackko is correct in assuming that i don't have access to PIX2. I don't want to modify any VPN parameters on PIX1 as its a production box with a large number of IPSEC tunnels running on it. I'm looking for a solution which would avoid removing the sysopt connection permit-ipsec line from the config.

My understanding is that any inbound VPN traffic hitting the outside interface of PIX1 will bypass any ACL's applied to that interface.

You can't apply an outbound access-list to a PIX interface can you? so applying an ACL to the inside interface wouldn't work.

So I guess I need a device behind my PIX which will filter the traffic once it's passed through the firewall - I can't see any other option working.

What do you think?

jackko · ‎10-17-2005

to sum up, so far we come up with 3 ways:

1. disable the command "sysopt connection permit-ipsec", configure and apply an inbound acl on pix1

2. apply an outbound acl on pix2

3. deploy another firewall behind pix1

#1 is not feasible since you don't prefer to disable this command

#2 is not feasible since pix2 is not under your management.

i guess not much choice left but to deploy a firewall behind the pix1. just wondering for curiosity, what makes you hold back from the idea of disabling "sysopt connection permit-ipsec".

pwicks · ‎10-17-2005

You can replace the "sysopt connection permit-ipsec" with the following two lines at the beginning of the Outside interface's access list:

access-list aaaaaaaa line 1 permit esp any host xxx.xxx.xxx.xxx

access-list aaaaaaaa line 2 permit udp any host xxx.xxx.xxx.xxx eq isakmp

aaaaaaaa = Name of existing Outside interface access list

xxx.xxx.xxx.xxx = IP of Outside interface

This serves the same purpose as the "sysopt connection permit-ipsec" but you then have the ability to filter IPSEC traffic.

I know that you do not want to remove the "sysopt connection permit-ipsec" command, but if you don't you will go through a lot of unnecessary configuration and hardware changes. Test the above solution in the lab and then apply it to the production system during the next regular maintenance period. We have done this numerous times and we have never have an issue, even when communicating with multiple Pix's that we did not have administrative control over. I assure you that you will have no issues.

jackko · ‎10-18-2005

access-list aaaaaaaa line 1 permit esp any host xxx.xxx.xxx.xxx

access-list aaaaaaaa line 2 permit udp any host xxx.xxx.xxx.xxx eq isakmp

it's interesting to learn that the above acl is not required when disabling the command "sysopt connection permit-ipsec".

i was looking through the pix i've been playing with, even with the commmand "sysopt connection permit-ipsec" disabled, and without acl permitting esp/isakmp, both lan-lan vpn and remote vpn access are working fine.

i guess the command "sysopt connection permit-ipsec" hasn't got anything to do with the pix outside interface. in other words, regardless the command "sysopt connection permit-ipsec" enabled or disabled, pix is still going to process incoming vpn request. so the only acl required then is the actually traffic you would like to permit between the 2 sites.

e.g. 10.10.10.0/16 <--> pix1 <--> www/vpn <--> pix2 <--> 10.11.0.0/16

the acl on pix1 outside interface would look like:

access-list 101 permit ip host 10.11.0.100 host 10.10.10.1

access-list 101 permit tcp host 10.11.0.101 host 10.10.10.1 eq 3389

access-list 101 permit tcp host 10.11.0.102 host 10.10.10.1 eq 1494

access-group 101 in interface outside

assuming there are other lan-lan vpn configured on pix1,

e.g. 10.10.10.0/16 <--> pix1 <--> www/vpn <--> pix3 <--> 10.12.0.0/16

then the entire inbound acl would look like:

access-list 101 permit ip host 10.11.0.100 host 10.10.10.1

access-list 101 permit tcp host 10.11.0.101 host 10.10.10.1 eq 3389

access-list 101 permit tcp host 10.11.0.102 host 10.10.10.1 eq 1494

access-list 101 permit ip host 10.12.0.100 host 10.10.10.1

access-list 101 permit tcp host 10.12.0.100 host 10.10.10.1 eq 3389

access-group 101 in interface outside

jackko · ‎10-19-2005

hi arun, just wondering how you go with the sample you were going to post.