Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

VPN terminating on outside with bypass acl ticked in ASDM

Hi,

I am looking into locking down access across a VPN that terminates on an ASA on the outside interface.  WIth the bypass interface ACLs box ticked in ASDM it ignores the rules on the outside interface where I was going to lockdown the access. Now I wanted to untick the box with the rules added so we have the access we need. The issue I have is we have a number of other VPNs that termiante there and probably work due to the fact they bypass the ACLs so is there any easy way to see the traffic that would use the outside rules if it were turned on so I can also add those rules too without breaking anything? I thought of using captures but time is against us on this one. Would they be captured anywhere else? Or use syslog?

Regards,

Z           

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

VPN terminating on outside with bypass acl ticked in ASDM

Hi,

The setting you are referring to is in the CLI format the command "sysopt connection permit-vpn". This is the default setting and doesnt therefore show up in the CLI configuration.

The form to prevent interface ACL bypass would be "no sysopt connection permit-vpn"

I think there would be one obvious choice to consider if you want to keep the other VPN connections operation identical to this moment.

This solution would be to go through all the VPN Client and L2L VPN configurations and determine all the remote networks you have. This would NOT include the VPN network that you want to control traffic for.

So lets say you have the following VPN remote networks

  • 10.10.10.0/24 Branch Network 1
  • 10.10.20.0/24 Branch Network 2
  • 10.10.30.0/24 Branch Network 3
  • 192.168.10.0/24 VPN User Pool
  • 172.16.0.0/16 LAN Network range

And lets say all the above mentioned networks are the VPN networks for which you want to keep the situation identical even if you change the bypass setting.

You could simply configure the following in your external interface ACL

object-group network VPN-REMOTE-NETWORKS

description VPN Remote networks

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 10.10.30.0 255.255.255.0

network-object 192.168.10.0 255.255.255.0

access-list OUTSIDE-IN line 1 remark Allow traffic from Remote VPN networks

access-list OUTSIDE-IN line 2 permit ip object-group VPN-REMOTE-NETWORKS 172.16.0.0 255.255.0.0

With the above configuration you would allow all traffic from the existing VPN remote networks and therefore the existing VPNs would not be affected. Since we didnt include the VPN remote network which connections we want to control in the above configuration we could simply start adding the rules for the new VPN and allow only the things we want.

Hope this helps

- Jouni

7 REPLIES
Super Bronze

VPN terminating on outside with bypass acl ticked in ASDM

Hi,

The setting you are referring to is in the CLI format the command "sysopt connection permit-vpn". This is the default setting and doesnt therefore show up in the CLI configuration.

The form to prevent interface ACL bypass would be "no sysopt connection permit-vpn"

I think there would be one obvious choice to consider if you want to keep the other VPN connections operation identical to this moment.

This solution would be to go through all the VPN Client and L2L VPN configurations and determine all the remote networks you have. This would NOT include the VPN network that you want to control traffic for.

So lets say you have the following VPN remote networks

  • 10.10.10.0/24 Branch Network 1
  • 10.10.20.0/24 Branch Network 2
  • 10.10.30.0/24 Branch Network 3
  • 192.168.10.0/24 VPN User Pool
  • 172.16.0.0/16 LAN Network range

And lets say all the above mentioned networks are the VPN networks for which you want to keep the situation identical even if you change the bypass setting.

You could simply configure the following in your external interface ACL

object-group network VPN-REMOTE-NETWORKS

description VPN Remote networks

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 10.10.30.0 255.255.255.0

network-object 192.168.10.0 255.255.255.0

access-list OUTSIDE-IN line 1 remark Allow traffic from Remote VPN networks

access-list OUTSIDE-IN line 2 permit ip object-group VPN-REMOTE-NETWORKS 172.16.0.0 255.255.0.0

With the above configuration you would allow all traffic from the existing VPN remote networks and therefore the existing VPNs would not be affected. Since we didnt include the VPN remote network which connections we want to control in the above configuration we could simply start adding the rules for the new VPN and allow only the things we want.

Hope this helps

- Jouni

New Member

VPN terminating on outside with bypass acl ticked in ASDM

Jouni,

thanks again for yet another quick response - I spoke with the client I have and explained we would have to go through all the VPNs we have and work out the traffic as like a lot of places it has been put in with no documentation of what does what or even a diagram to give us some hope so trawling through all the VPNs is our only option. Many thanks again for your help. I will make sure it is all fully documented for them when we have it all working.

Regards,

Z

Super Bronze

VPN terminating on outside with bypass acl ticked in ASDM

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

New Member

VPN terminating on outside with bypass acl ticked in ASDM

Jouni,

I would do all of those things if I could - I am on this project just to keep a PCI-DSS QSA happy so won't be paid to do any of the other stuff (it needs it but they can't afford it - I think it's shortsighted). Many thanks again for your help. I have used Netflow, syslog and captures in the past to find out traffic flows especially where the customer has no idea.

Regards,

Z

New Member

VPN terminating on outside with bypass acl ticked in ASDM

Jouni,

Hi, sorry me again - just wanted to check that if the VPN is terminating on the outside interface does it decrypt it before checking the ACL otherwise it wouldn't see what the real traffic is. I am sure it does otherwise this wouldn't work I have looked at the NAT order from outside to inside: The check input acl is after the decrypt.

  • If IPSec then check input access list
  • decryption - for CET or IPSec
  • check input access list
  • check input rate limits
  • input accounting
  • redirect to web cache
  • NAT outside to inside (global to local translation)
  • policy routing
  • routing
  • crypto (check map and mark for encryption)
  • check output access list
  • inspect CBAC
  • TCP intercept
  • encryption
  • Queueing
Super Bronze

VPN terminating on outside with bypass acl ticked in ASDM

Hi,

Seems that list is for a router rather than the ASA firewall.

Though the same should apply regarding this situation. Encrypted/Encapsulated packet is decrypted/decapsulated and the inner packet is matched against the interface ACL if we have "no sysopt connection permit-vpn" in use.

- Jouni

New Member

VPN terminating on outside with bypass acl ticked in ASDM

Yeah I am sure I had a link somewhere with the ASA version but couldn't find it and my searches on cisco.com just came up with the IOS version

534
Views
0
Helpful
7
Replies
CreatePlease to create content