Hi,
Glad if it was of help
I edited the reply earlier and just now realized I might have make the reply partially a bit missleading.
I added the"LAN network range" in the list later and didnt even think that the original top line mentioned that he listing would contain only VPN networks. So to clarify that I meant that the network 172.16.0.0/16 is meant to illustrate the customers whole existing LAN address space.
I also talked about not adding the new VPN network to the "object-group" and I didnt give an example of a possible new VPN network range so that was a bit missleading. I could have given that range in the reply as an example and used it in the ACL to allow some traffic.
Also,
Now that I think of it I guess there would also be another a bit similiar approach keeping the access rules or their behaviour identical even after changing to the "no sysopt connection permit-vpn" setting. The option would be to create "access-list" configuration similiar to the above but simply allowing traffic from all the 3 different private IP address ranges to your customer network.
The idea behind that is that all of your VPN Pools and Remote Site networks are presumably from the private IP address ranges? If so this kind of approach would make sure that traffic from all of those networks would be allowed even if you didnt specifically know all the address ranges.
You could then add the rules related to your new VPN network also and still control that networks traffic.
An example ACL for this could be
- 192.168.100.0/24 New Branch VPN network
- 172.16.100.100 Internal Web Server
- 172.16.0.0/16 LAN Network range
object-group network REMOTE-PRIVATE-RANGES
description Private Network Ranges
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.0.0
access-list OUTSIDE-IN line 1 remark Allow VPN users to access internal server
access-list OUTSIDE-IN line 2 permit tcp 192.168.100.0 255.255.255.0 host 172.16.100.100 eq www
access-list OUTSIDE-IN line 3 permit tcp 192.168.100.0 255.255.255.0 host 172.16.100.100 eq https
access-list OUTSIDE-IN line 4 remark Block all other traffic from New Branch Network
access-list OUTSIDE-IN line 5 deny ip 192.168.100.0 255.255.255.0 any
access-list OUTSIDE-IN line 6 remark Allow all traffic from all Private Network Ranges
access-list OUTSIDE-IN line 7 permit ip object-group REMOTE-PRIVATE-RANGES 172.16.0.0 255.255.0.0
The above ACL should essentially first allow traffic to one internal server and then block all other traffic from that VPN network. This essentially is meant to illustrate the rules for the new VPN network you are adding and need rules for.
Next we allow traffic from all Private IP address ranges to your internal network to keep the access rules identical to the previous situation when "sysopt connection permit-vpn" setting was used.
Though I have to say that I am still somewhat hesitant having such an ACL though we shouldnt really be seeing any such traffic from an external network anyway.
Naturally the better choice in the long run is to do as you say. Map out the current network and document it and only allow that which is truly needed. I would imagine you might have to use Syslog and possibly traffic captures to your advantage. I am sure there are other options too that I have never used that would be better suited for getting you the information needed to build the correct ACL rules.
One thing that I have never used but would imagine that would suit the use atleast in some way might be the use of Netflow perhaps?
- Jouni
