ACL.... after making IPsec through ASDM

[Kyujin Choi]

I always used ASDM wizard to create IPsec to branch office.   

For example, I have one brance office (10.3.3.0/24)  --------- IPsec ---------------- HQ (10.0.0.0/8) 

Whenever I created a IPsec through ASDM wizard, I could see always NAT Exempt  source 10.3.3.0/24  destination 10.0.0.0/8 in NAT rule (like below picture)

I have never seen that ASDM wizard created ACL like  source 10.3.3.0/24 destination 10.0.0.0/8 because I always checked the box. Do I need this step?  Because I never made any ACL when I create a tunnel.

As I understand, this is a tunnel. As long as a NAT is exempted, every traffic should be treated as internal traffic.

[Jouni Forss]

Hi,

I have to say that I never use the ASDM for creating NAT/ACL/VPN configurations so I am more familiar with the CLI of the ASA.

To my understanding the above window would essentially let you enter the local/remote networks of the L2L VPN connection and according to that information the ASDM creates the Crypto ACL for the L2L VPN connection.

When the check box is selected then to my understanding the ASDM would also create the corresponding NAT0 configuration (ACL or ACE rule if a previous NAT0 ACL already exists for the interface) for the "inside" interface

Without the NAT0 configuration the traffic wont flow between the local/remote networks so you would need to have this NAT0 / NAT Exempt configuratin.

I am not sure if you already have it configured on the ASDM but you can set the ASDM Preferences so that it previews all the configurations that its about to send to the ASA when you have finished any configuration or any Wizard. Do you have this enabled? This should show the ACLs that the ASDM creates also.

- Jouni

[Kyujin Choi]

When I create a new IPsec, I will take a look at CLI command. I already enabled this option.

[Kyujin Choi]

This is what I found.

When ASMD created a IPsec through wizard, there is option for "ACL" : Enable inbound IPsec sessions to bypass interface access lists. I always clicked this option. But I never focused on next message "Group policy authorization access lists still apply to the traffic". I will discuss this later.

  This is a summary for new IPsec. "Bypass interface access list"  Yes

 

   These are cli commands.

So I went to group policy and found "filter" section (default was inhereit)

  It showed ACL, but this ACL seems like for crypto map object.

I don't see any ACL for traffic filters, but crypto map for NAT.

Question 1)

   We have one ACL source object groups (all branch office's network)  destination object group (HQ all vlans) ip permit.

   Do we need this ACL? because it is already set bypass for traffics.

Question 2)

    Every IPsec traffic was ok, except VoIP (UDP). I captured all traffics and some UDP traffics was not communicated (gatekeeper, registration packets). When my security engineer put this branch office's subnet into the source object groups (all tranch office's network), phone started working. This part I was not able to understand because before he put this branch office's network into the object, data traffic did not have any problem. 

I

[Jouni Forss]

Hi,

The first setting you show in the picture for the ACL Bypass essentially refers to a global configuration on the ASA. When this setting is enabled all traffic incoming from a VPN connection (Client/L2L VPN) will bypass the interface ACL of the interface from which the VPN is built. This would usually be the "outside" interface of the ASA.

Notice that if you once chose to change this setting it will not only affect the new VPN connection you are configuring but also all the existing configuration. Its strange that this is not very clearly mentioned in the configuration Wizard.

To my understanding the Group Policy in the same section refers to the VPN Filter ACL that you have also mentinoned. If you were to configure a Group Policy for your L2L VPN and attached a VPN Filter ACL to that configuration you would be using that VPN Filter ACL to control traffic and the ACL Bypass would not help with that.

In some cases I don't use the ACL Bypass setting and I will actually configure all the rules for Remote VPN networks (Client or L2L VPN) on the "outside" interface ACL. I find its a lot clearer sometimes than configuring multiple VPN Filter ACLs for different connections.

Looking at the provided CLI configuration that the ASDM shows it seems that you are actually running a newer software level (newer than 8.3 I think atleast) so if you had any NAT0 configurations they would actually NOT use any ACL for the NAT as that is no more supported in the newer softwares.

With regards to your questions,

1.) You will need a Crypto ACL on L2L VPN connections to tell the ASA what are the local and remote networks between which traffic should be  sent through the L2L VPN connection (encapsulated/encrypted). In the picture where the ASDM shows you the CLI configuration you can see this Crypto ACL at the top. You will also see it being applied to the "crypto map" configurations where it tells ASA the networks for that particular L2L VPN connection.

On the CLI you could issue the command

show run crypto map

And this would show you all the ACLs used in the L2L VPN connection (though it shows much more than just that)

In the output you would find configuration lines like

crypto map match address

The ACLs used in those statements are in use with the L2L VPN connection and they cannot/should not be removed.

If you are asking if you can remove the ACL shown with the red arrow in the picture you should check if its used in any of your configurations. On the CLI of the ASA it would be easy to search the configuration for the ACL name. If that name would be referenced anywhere else than the actual ACL configurations then it would be likely that this ACL should not be removed.

So without seeing your configurations I am not sure if I can say with certainty if you can remove that ACL.

2.) I am not sure what exactly he configured so I am not sure what he was doing to correct the situation. Without knowing the network topology and the current ASA configurations its hard for me to say what was the problem with the Voice connections and why actual Data connections were not affected by the problem even before this change.

- Jouni

[Kyujin Choi]

Thanks for your reply.

My question was probably not clear, so I rearrange my statements. Thanks for all explanation.

After creating IPsec through ASDM, ACL (permit ip source xxx   destination yyy) is necessary?  This ACL is different from ACL that used for crypto map to define local and remote traffic for NAT exempt.

My questions came from two scenarios.

First, IPsec for all branch offices. Let me repeat that.

Basically my security engineer knew all branch office's network as remote network (destination) and put all vlans at HQ (source) in ASA. like below

(Object section)

Brach office Group object: 10.0.1.0/24   10.0.2.0/24  10.15.1.0/24

HQ  Group object: all vlans at HQ

(ACL section)

source branch office    destination  HQ  protocol  IP   permit 

Usually, I created a IPsec when branch office's public IP changed. Those branch office's network are already in the object group. However I made a new IPsec which was not in the object group of branch office. After I created a IPsec, data traffic is ok (Ping, internal web server, outlook) except some UDP traffic (VoIP)

So, once we put ACL (permit ip source xxx destination yyy). VoIP started working (Data works fine before he put this ACL) Which means that we put this new branch office network address into the branch office group.

So I made a quick conclusion that this ACL is needed.

Second, I have GRE over IPsec (soource 10.100.254.0/24  destination 10.101.254.0./24) This IPsec was made through ASDM. After I create this IPsec for GRE tunnel, I can see IPsec is established (monitor section)

However, without below ACL,  IP permit source xxx  destination yyy.  GRE doesn't work. IP protocol includes "GRE" protocol.

In other words, in monitor section, I can see IPsec is up after I create IPsec. However GRE is not established (tunnel interface doesn't come up until I put above ACL)

That is why I made a my conclusion that if I use ASDM, I need ACL to define "permit IP source xxx  destianation yyy)"

I hope that I fully understand this ACL and ASDM wizard. If not, please correct me.

[Jouni Forss · Accepted solution]

Hi,

I am afraid that we might be speaking with different terms as you use ASDM and I personally only use the CLI to configure the ASA.

It seems to me that you are talking about interface ACLs perhaps.

The problem with ASDM for me is that to check information about current configurations are split to way too many sections and its hard to form a clear picture what is actually configured on the device. On the CLI I can at best use a single command to view the whole configuration and easily check what is configured.

When I look at your last picture above related to the IPsec/GRE it would seem to me that you are talking about an interface ACL connected to the "inside" interface.

You seem to have allowed some ICMP traffic originally on the interface ACL and I presume you later now added the "permit ip" to allow the GRE traffic through the ASA?

This is expected behaviour. If you attach an interface ACL to the ASA interface then you will have to allow traffic that you need to pass through the ASA from behind that interface. So if you had only the statements which allowed the ICMP traffic then naturally no other traffic was allowed through the ASA.

I am also getting the feeling that you might expect that the ACL Bypass function that we talked about earlier would make it so that you dont need to the add the "permit" statement for the GRE traffic. With the ACL Bypass function there is one crucial thing to notice. It will only apply the Bypass for the traffic that is coming through the interface that forms the VPN connection. So in your case the Bypass would only apply to traffic coming through the external interface of the ASA. The Bypass will therefore in no way affect the traffic that is coming from behind your ASA from behind the "inside" interface to the VPN connection.

You were also talking about the addition of the new Branch network to some "object-group" earlier and you also mention that some traffic was working even without this.

I can only guess as to what the reason was without seeing configurations. I would presume that you are again talking about some "object-group" that is used in an interface ACL or VPN Filter ACL to permit traffic between local/remote networks. Then you might naturally need to add the new network to the "object-group" to allow the traffic. The reason why some traffic might already work without might be because of some other already existing rule on the same interface ACL. Take for example HTTP traffic. You most likely have allowed this traffic from any LAN network towards any destination IP address and therefore this existing rule would also allow this traffic to your Branch network.

But I can only guess as I can't see the CLI configuration.

- Jouni

[Kyujin Choi]

  You are right. Thanks for clearing everyting.

  I tested in my lab, without interface ACL (branch office subnet) ---  (HQ subnet). It did not work. Basically IPsec is terminated to outside, and this interface is inside (Thanks for clearing this). This is nothing with UDP, but interface ACL. Thanks.

So, my conclusion is that whevern I create a new IPsec, I need to make a interface ACL for those traffics.