Troubleshoot IOS Zone Based Policy Firewall Inspection Issues When NAT NVI Is Configured

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:

• Cisco ZBF configuration in IOS routers.

• Cisco NAT NVI configuration in IOS routers.

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

• NAT Virtual Interface

• Security Configuration Guide: Zone-Based Policy Firewall, Cisco IOS Release 15M&T

• Cisco IOS Firewall Classic and Zone-Based Virtual Firewall Application Configuration Example