Introduction
This document describes an inspection problem that happens when the IOS Zone-Based Firewall (ZBF) is configured together with Network Address Translation Virtual Interface (NAT NVI) in a Cisco IOS router.
The main intention of this document is to explain why this issue happens and provide you with the solution required to allow the required traffic to pass through the router in this kind of implementation.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
Components Used
The information in this document is based on these software and hardware versions:
- Integrated Services Routers (ISR G1)
- IOS 15M&T
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Background Information
Here further details about what NAT NVI is and how to configure it on the Cisco routers:
The Network Address Translation Virtual Interface (NAT NVI) feature removes the requirement to configure an interface as either NAT inside or NAT outside. An interface can be configured to use NAT or not use NAT. NVI allows traffic between overlapped VPN Routing/Forwarding (VRFs) in the same Provider Edge (PE) router, and traffic from inside to inside between overlapping networks.
NAT Virtual Interface
Problem: IOS Zone-Based Policy Firewall Inspection Issues When NAT NVI Is Configured
The ZBF has problems to inspect ICMP and TCP traffic when NAT NVI is configured, here an example of this problem. It is confirmed the TCP and ICMP traffic is not inspected from the inside to the outside zones when the ZBF is configured together with NAT NVI in the router ROUTER as shown in the image.
Checked the actual ZBF configuration applied to the router ROUTER and confirmed the following:
ROUTER#show ip int br
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 64.100.0.1 YES NVRAM up up
GigabitEthernet0/1 10.1.1.254 YES NVRAM up up
GigabitEthernet0/2 unassigned YES NVRAM administratively down down
NVI0 10.0.0.1 YES unset up up
Tunnel1 10.0.0.1 YES NVRAM up up
ROUTER#show zone security
zone self
Description: System Defined Zone
zone INSIDE
Member Interfaces:
Tunnel1
GigabitEthernet0/1
zone OUTSIDE
Member Interfaces:
GigabitEthernet0/0
Extended IP access list ACL_LAN_INSIDE_TO_OUTSIDE
10 permit ip 10.0.0.0 0.255.255.255 any (70 matches)
ROUTER#show run | b class-map
class-map type inspect match-any CMAP_FW_PASS_OUTSIDE_TO_SELF
match access-group name ACL_DHCP_IN
match access-group name ACL_ESP_IN
match access-group name ACL_GRE_IN
class-map type inspect match-any CMAP_FW_PASS_SELF_TO_OUTSIDE
match access-group name ACL_ESP_OUT
match access-group name ACL_DHCP_OUT
class-map type inspect match-any CMAP_FW_INSPECT_INSIDE_TO_OUTSIDE
match access-group name ACL_LAN_INSIDE_TO_OUTSIDE
class-map type inspect match-any CMAP_FW_INSPECT_OUTSIDE_TO_SELF
match access-group name ACL_SSH_IN
match access-group name ACL_ICMP_IN
match access-group name ACL_ISAKMP_IN
class-map type inspect match-any CMAP_FW_INSPECT_SELF_TO_OUTSIDE
match access-group name ACL_ISAKMP_OUT
match access-group name ACL_NTP_OUT
match access-group name ACL_ICMP_OUT
match access-group name ACL_HTTP_OUT
match access-group name ACL_DNS_OUT
policy-map type inspect PMAP_FW_INSIDE_TO_OUTSIDE
class type inspect CMAP_FW_INSPECT_INSIDE_TO_OUTSIDE
inspect
class class-default
drop log
policy-map type inspect PMAP_FW_SELF_TO_OUTSIDE
class type inspect CMAP_FW_INSPECT_SELF_TO_OUTSIDE
inspect
class type inspect CMAP_FW_PASS_SELF_TO_OUTSIDE
pass
class class-default
drop log
policy-map type inspect PMAP_FW_OUTSIDE_TO_SELF
class type inspect CMAP_FW_INSPECT_OUTSIDE_TO_SELF
inspect
class type inspect CMAP_FW_PASS_OUTSIDE_TO_SELF
pass
class class-default
drop log
zone security INSIDE
zone security OUTSIDE
zone-pair security ZPAIR_FW_INSIDE_TO_OUTSIDE source INSIDE destination OUTSIDE
service-policy type inspect PMAP_FW_INSIDE_TO_OUTSIDE
zone-pair security ZPAIR_FW_SELF_TO_OUTSIDE source self destination OUTSIDE
service-policy type inspect PMAP_FW_SELF_TO_OUTSIDE
zone-pair security ZPAIR_FW_OUTSIDE_TO_SELF source OUTSIDE destination self
service-policy type inspect PMAP_FW_OUTSIDE_TO_SELF
interface GigabitEthernet0/1
description LAN
ip address 10.1.1.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
zone-member security INSIDE
duplex auto
speed auto
end
interface GigabitEthernet0/0
description INTERNET
ip vrf forwarding PUBLIC
ip address 64.100.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly in
zone-member security OUTSIDE
duplex auto
speed auto
end
ip nat inside source route-map RMAP_NAT_POLICY interface GigabitEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0 64.100.0.2 name DEFAULT
ip route vrf INET_PUBLIC 0.0.0.0 0.0.0.0 GigabitEthernet0/0 64.100.0.2 name DEFAULT
route-map RMAP_NAT_POLICY permit 10
description ROUTE-MAP FOR NAT
match ip address ACL_NAT
ROUTER#show access-list ACL_NAT
Extended IP access list ACL_NAT
10 permit ip 10.0.0.0 0.255.255.255 any (72 matches)
When traffic is sent through the router ROUTER, confirmed the next results:
When the NAT configuration was applied with the ipnat inside and ipnat outside assigned to the router interfaces, together with the ipnat inside nat statement for the dynamic NAT, the pings didn't pass from the LAN-SW 10.1.1.253 IP address to the 64.100.1.1 on the WAN-SW switch.
Even after the ZBF zones were removed from the router interfaces, the traffic didn't pass through the router, it started to pass through after the NAT rule was changed as follows:
ip nat source route-map RMAP_NAT_POLICY interface GigabitEthernet0/0 overload
interface GigabitEthernet0/1
description LAN
ip address 10.1.1.254 255.255.255.0
ip nat enable
ip virtual-reassembly in
duplex auto
speed auto
end
interface GigabitEthernet0/0
description INTERNET
ip vrf forwarding PUBLIC
ip address 64.100.0.1 255.255.255.0
ip nat enable
ip virtual-reassembly in
duplex auto
speed auto
After this, re-applied the ZBF zones in the router interfaces.
ip nat source route-map RMAP_NAT_POLICY interface GigabitEthernet0/0 overload
interface GigabitEthernet0/1
description LAN
ip address 10.1.1.254 255.255.255.0
ip nat enable
ip virtual-reassembly in
zone-member security INSIDE
duplex auto
speed auto
end
interface GigabitEthernet0/0
description INTERNET
ip vrf forwarding PUBLIC
ip address 64.100.0.1 255.255.255.0
ip nat enable
ip virtual-reassembly in
zone-member security OUTSIDE
duplex auto
speed auto
As soon as the ZBF zones were re-applied in the router interfaces, confirmed the ZBF started to display the drop syslog messages for the replies from the OUTSIDE zone to the self-zone:
Jun 28 18:32:13.843: %FW-6-SESS_AUDIT_TRAIL_START: (target:class)-(ZPAIR_FW_INSIDE_TO_OUTSIDE:CMAP_FW_INSPECT_INSIDE_TO_OUTSIDE):Start tcp session: initiator (10.1.1.253:59393) -- responder (64.100.1.1:23)
Jun 28 18:32:13.843: %FW-6-DROP_PKT: Dropping tcp session 64.100.1.1:23 64.100.0.1:59393 on zone-pair ZPAIR_FW_OUTSIDE_TO_SELF class class-default due to DROP action found in policy-map with ip ident 62332
Note: From the log messages, you can confirm in the first AUDIT_TRAIL log when the TCP telnet session is first initiated from the INSIDE to the OUTSIDE zone, but then the return traffic wrongly came back to the ZBF from the OUTSIDE to the self-zone due to the NAT NVI and the way it processes the traffic when the ZBF is in place.
It is confirmed, the only way to force the return traffic to pass through the ZBF is to apply a pass action rule to allow the return traffic from the OUTSIDE zone to self-zone, this rule was applied for the icmp and TCP traffic as test purposes and for both it was confirmed it worked fine and allowed the return traffic as required.
Note: To apply a pass action rule in the zone pair between the OUTSIDE zone and the self-zone, is not a recommended solution for this problem, this is because it is highly required for the return traffic to get inspected and automatically allowed by the ZBF.
Solution
The ZBF does not support NAT NVI, the only solution for this problem is to apply any of the workarounds mentioned in the CSCsh12490 Zone Firewall and NVI NAT do not interoperate bug, here the details:
1. Remove the ZBF and apply the classic firewall (CBAC) instead, which is of course not the best option and this is because the CBAC is an already end of life firewall solution for the IOS routers and it is not supported on the IOS-XE routers.
OR
2. Remove the NAT NVI configuration from the IOS router and apply the normal inside/outside NAT configuration instead.
Tip: Another possible workaround would be to keep the NAT NVI configured in the router and remove the ZBF configuration, then apply the required security policies in any other security device with security capabilities.
Related Bugs
CSCsh12490 Zone Firewall and NVI NAT do not interoperate
CSCek35625 NVI and FW interoperability enhancements
CSCvf17266 DOC: ZBF configuration guide missing restrictions related to NAT NVI
Related Information