Shulou(Shulou.com)06/01 Report--

one。 Overview:

Some netizens in the QQ group discuss the execution order of global and interface of policy-map of ASA firewall. From the literal meaning, we can see that the scope of these two applications is different. One is a global call, and the other is only called in the interface. Therefore, we feel that detailed interface is called first. In order to confirm our idea, we decided to build an environment to verify it.

two。 Basic ideas:

a. The policy-map that does not conflict is estimated to be called and executed by the global and interface service-policy successively, and no effect can be seen.

b. You can only use conflicting policy-map, which can be called simultaneously in the global and interface service-policy, to see which one takes effect.

c. The policy-map execution scope of the global and the interface is different. It is estimated that the policy-map of the interface will be called first, and the order may be as follows:

1. First execute the service-policy of the interface, and call the corresponding policy-map. If it is matched, the global service-policy is not executed.

two。 If it is not matched by the policy-map of the interface, the global service-policy is then executed and the corresponding policy-map is called

-after testing, it is found that it is different from what you expected: if it is approved by the policy-map of the interface, it will be sent to the global policy-map, unless it is discarded by the ACL of the class-map of the interface, or is discarded after review.

three。 Test the topology:

10.1.1.0 to 24 (Inside) 200.100.1.0 to 24 (Outside)

PC1 (.8)-- (.1) ASA842 (.1)-- (.8) PC2

The web server port is: 2000

four。 Basic configuration:

A.PC1:

IP:10.1.1.8/24, GW:10.1.1.1

B.ASA842 Firewall:

① interface configuration:

Interface GigabitEthernet0

Nameif Inside

Security-level 100

Ip address 10.1.1.1 255.255.255.0

No shut

Interface GigabitEthernet1

Nameif Outside

Security-level 0

Ip address 202.100.1.1 255.255.255.0

No shut

② dynamic PAT configuration:

Object network Inside.net

Subnet 10.1.1.0 255.255.255.0

Object network Inside.net

Nat (Inside,Outside) dynamic interface

③ static PAT configuration:

Object network Inside.pc1

Host 10.1.1.8

Object network Inside.pc1

Nat (Inside,Outside) static interface service tcp 2000 2000

④ policy settings:

Access-list outside extended permit tcp any object Inside.pc1 eq 2000

Access-group outside in interface Outside

five。 Test steps:

a. Verify that the public network can access the internal web server properly at this time:

-cannot be accessed because skinny review is enabled by default global policy

b. Configure the policy-map of the outside interface and call:

Access-list web2000 extended permit tcp any object Inside_pc1 eq 2000

Class-map web2000

Match access-list web2000

Policy-map web2000

Class web2000

Inspect http

Service-policy web2000 interface Outside

c. Verify that the public network can access the internal web server properly at this time:

-still unable to access

Ciscoasa# show service-policy

Global policy:

Service-policy: global_policy

Class-map: inspection_default

. Omit the part.

Inspect: ip-options _ default_ip_options_map, packet 0, drop 0, reset-drop 0

Inspect: skinny, packet 4, drop 1, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

Interface Outside:

Service-policy: web2000

Class-map: web2000

Inspect: http, packet 4, drop 0, reset-drop 0

-you can see that although the packet is approved by the class-map under the interface and released, it is discarded by the global class-map.

d. Adjust the policy-map of the outside interface and call:

Access-list outside_skinny extended deny tcp any object Inside_pc1 eq 2000

Access-list outside_skinny extended permit tcp any any eq 2000

Class-map outside_skinny

Match access-list outside_skinny

Policy-map outside_skinny

Class outside_skinny

Inspect skinny

No service-policy web2000 interface outside

Service-policy outside_skinny interface Outside

e. Verify that the public network can access the internal web server properly at this time:

-can be accessed normally

Before visiting, clear service-policy, and then check it after the visit is completed:

Ciscoasa# show service-policy

Global policy:

Service-policy: global_policy

Class-map: inspection_default

. Omit the part.

Inspect: ip-options _ default_ip_options_map, packet 0, drop 0, reset-drop 0

Inspect: skinny, packet 0, drop 0, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

Interface Outside:

Service-policy: outside_skinny

Class-map: outside_skinny

Inspect: skinny, packet 0, drop 0, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

-it can be found that the global and interface class-map are not matched before and after access.

f. Adjust the global and interface policy-map:

① interface:

Access-list outside_skinny extended permit tcp any any eq 2000

Class-map outside_skinny

Match access-list outside_skinny

Policy-map outside_skinny

Class outside_skinny

Inspect skinny

Service-policy outside_skinny interface Outside

② Global:

Access-list global_skinny extended deny tcp any object Inside_pc1 eq 2000

Access-list global_skinny extended permit tcp any any eq 2000

Class-map global_skinny

Match access-list global_skinny

Policy-map global_policy

Class inspection_default

No inspect skinny

Class global_skinny

Service-policy global_policy global

③ Test:

-unable to access, rejected by policy-map of outside interface

Ciscoasa# show service-policy

Global policy:

Service-policy: global_policy

Class-map: inspection_default

. Omit the part.

Inspect: ip-options _ default_ip_options_map, packet 0, drop 0, reset-drop 0

Class-map: global_skinny

Inspect: skinny, packet 0, drop 0, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

Interface Outside:

Service-policy: outside_skinny

Class-map: outside_skinny

Inspect: skinny, packet 4, drop 1, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

-as you can see, because outside's ACL does not explicitly deny traffic, it is matched and detected that it is not skinny traffic and is discarded.

g. Adjust the global and interface policy-map again:

① interface:

Access-list outside_skinny extended deny tcp any object Inside_pc1 eq 2000

Access-list outside_skinny extended permit tcp any any eq 2000

Class-map outside_skinny

Match access-list outside_skinny

Policy-map outside_skinny

Class outside_skinny

Inspect skinny

Service-policy outside_skinny interface Outside

② Global:

Access-list global_skinny extended permit tcp any any eq 2000

Class-map global_skinny

Match access-list global_skinny

Policy-map global_policy

Class global_skinny

Inspect skinny

Service-policy global_policy global

③ Test:

-can be accessed normally

Ciscoasa# show service-policy

Global policy:

Service-policy: global_policy

Class-map: inspection_default

. Omit the part.

Inspect: ip-options _ default_ip_options_map, packet 0, drop 0, reset-drop 0

Class-map: global_skinny

Inspect: skinny, packet 0, drop 0, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

Interface Outside:

Service-policy: outside_skinny

Class-map: outside_skinny

Inspect: skinny, packet 0, drop 0, reset-drop 0

Tcp-proxy: bytes in buffer 0, bytes dropped 0

-you can find that when the ACL of the outside API is configured with reject, it will not match the global policy-map.

six。 Summary:

a. Processing order: interface first and then global

b. Whether it will be sent to the global: if it is not matched by the interface policy-map, or approved by the interface policy-map, it will be sent to the global.

-discarded by ACL or discarded after review will not match the global policy-map

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.