This is possible on our ASA/FWSM platform to configure timeout for certain host or subnet for specific traffic but not on the ASR. What can be done on the ASR is shown below:
kusankar-ASR1002(config)#ip nat translation ? dns-timeout Specify timeout for NAT DNS flows finrst-timeout Specify timeout for NAT TCP flows after a FIN or RST icmp-timeout Specify timeout for NAT ICMP flows max-entries Specify maximum number of NAT entries port-timeout Specify timeout for NAT TCP/UDP port specific flows pptp-timeout Specify timeout for NAT PPTP flows routemap-entry-timeout Specify timeout for routemap created half entry syn-timeout Specify timeout for NAT TCP flows after a SYN and no further data tcp-timeout Specify timeout for NAT TCP flows timeout Specify timeout for dynamic NAT translations udp-timeout Specify timeout for NAT UDP flows kusankar-ASR1002(config)#ip nat translation port-timeout tcp 8080 300
Yes, please refer this link: http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/iadnat-match-vrf.html
The ability of Network Address Translation (NAT) to consistently represent a local IP address as a single global IP address is termed paired address pooling. Paired address pooling is supported only on Port Address Translation (PAT).
Device# configure terminal Device(config)# ip nat settings pap Device(config)# ip nat pool net-208 192.168.202.129 192.168.202.158 netmask 255.25 5.255.240 Device(config)# access-list 1 permit 192.168.34.0 0.0.0.255 Device(config)# ip nat inside source list 1 pool net-208 overload Device(config)# interface gigabitethernet 0/0/1 Device(config-if)# ip address 10.114.11.39 255.255.255.0 Device(config-if)# ip nat inside Device(config-if)# exit Device(config)# interface gigabitethernet 0/1/2 Device(config-if)# ip address 172.16.232.182 255.255.255.240 Device(config-if)# ip nat outside Device(config-if)# end
Cisco is working with partners like Lancope and ActionPacked. You can see a list of free NetFlow collectors that are supported by Cisco here:
No, not at the time of this writing (Jan 2014). This is not supported in XE3.1x or earlier. Check with product marketing about roadmap status
Neither vrf aware nat64 nor vrf aware nat46 are supported at the time of this writing (Jan 2014).
Currently we only provision enabling/disabling of ALGs globally.
Not at this time. However, there is an enhancement request filed CSCdr25202. Please reach out to the account team and have them drive this.
Use Network Address Translation (NAT) to translate IP addresses if the IP addresses that you use are neither legal nor officially assigned. Overlapping networks result when you assign an IP address to a device on your network that is already legally owned and assigned to a different device on the Internet or outside the network.
Please refer this link: CHAPTER 1 Address Translation of Overlapping Networks Page 8
The Match-in-VRF Support for NAT feature supports Network Address Translation (NAT) of packets that communicate between two hosts within the same VPN routing and forwarding (VRF) instance. In intra-VPN
NAT, both the local and global address spaces for end hosts are isolated to their respective VPNs, and as a result, the translated addresses for the hosts overlap each other. The Match-in-VRF Support for NAT feature helps separate the address space for translated addresses among VPNs.
Please refer this link: CHAPTER 22 Match-in-VRF Support for NAT 311
ACL in on the interface >> ZBF >> NAT >>ACL out on the interface
ACL in on the interface >> NAT >> ZBF >> ACL out on the interface.
There is no reason to configure interface based ACL in addition to ZBF. Be very careful when using interface ACLs with ZBF since ZBF cannot modify the interface ACLs to add pin-holes.
There is no virtual context concept on the ASRs/ISRs like we do on the PIX/ASA/FWSM platform but what we can do is is apply separate zone-pair policy for different pairs of VRFs. Check this link: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/asr1000/vrf-aware-fw.html
Starting XE 3.15 (March 2015) and above XE will support transparent firewall.
Yes, ACLs tied to ZBF and QoS will show hit count starting XE 3.13 and above.
Support for this was added in XE 3.12 (March 2014).
This feature is called SYN cookie protection. This only helps TCP traffic. More details here: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/asr1000/conf-fw-tcp-syn-cookie.html
Refer this link regarding various attacks: https://supportforums.cisco.com/docs/DOC-38900
|ARP Flood||ZBF does not inspect ARP packets|
ZBF has no mechanism for supporting evasive udp session establishment detection
ZBF doesn’t detect it, but enabling RPF should catch it.
|Ping Of Death||
System should simply handle it no ZBF needed
|Random Unreachable Host||
We do verify that a session exists before allowing icmp error messages through.
First we ensure that the TCP packet is within the window. Then we mark the flow as closed, so additional RSTs don’t get through, but the firewall session may stick around (TBD) since we continue to get packets for the flow (even though we drop them.)
Anything with a bogus source address should be caught by RPF
|SYN Flood||SYN Cookie Protection|
|TCP Port Scan||
VFR (which ZBF enables by default)
We support QOS, but it is not flow aware, or ZBF will only allow so many packets to be processed at one time for a given flow.
|UDP Port Scan||
IPS/IDS All ZBF does is look up the session to see if it is valid.
No support. We just verify that options are valid. No way to strip or deny options. (although interface ACLs might be able to be used to deny)
We clear out the idle half open sessions. This is for both udp and tcp. The idea is if we have a bunch of half open sessions and we start doing aggressive aging, the oldest 1/2 open (the one idle the longest) will likely be freed up first. When we run out, we drop packets. When aggressive aging is enabled (or disabled) we spit out a syslog alert message.
Anytime we drop the packet, we report a syslog message which is rate limited to one dropped message every 30 seconds. These messages are severely rate limited.
Watch for the syslog messages.
FTP, H323, RTSP, SCCP, SIP, TFTP, RCMD, LDAP(NAT only), DNS (NAT, no deep packet inspection), SMTP/ESMTP, POP3, IMAP, SUNRPC, GTPv1, GTPV2, PPTP(NAT only) are supported.
Please refer this external link: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/asr1000/sec-data-fw-hsl.html (search for ALG)
Prime Infrasturcture can be used to manage ASRs. You can read more about it here:
Please refer to this link regarding ordering router feature licenses: http://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/product_bulletin_c07-448862.html#wp9002740
Stateful Inter-chassis redundancy does not support router config sync.
No. They could be different hardware; one ASR1001 and one ISR 4431 running the same XE image should be good for inter-chassis failover. Please check the prerequisite here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/conf-fw-stateful-inter-chassis.html#GUID-8F98E1DB-91D5-4AC3-84A9-3451CA8631EF
Same software on both units is mandatory.
The way active-active inter-box firewall redundancy works is that,
The active/active is, in fact, referring 2 different flows.
Please read here for additional information:http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/iadnat-stateful-int-chass.html#GUID-799993C7-4264-4B31-B787-FE809DC80DAE
When the standby unit receives packets on its WAN interface, it does a route lookup and that fails due to the LAN interface being down. There is no reason for it to do route lookup it should send the packets over to the active unit and have it do the route look up. This is to be expected because Route lookup happens before AR. AR is a feature in FW, FW is an egress feature.
No, it is not. The only topology that is supported is B2B on the LAN side and Asymmetry on the WAN side. We do not support AR (asymmetry routing) on both WAN and LAN sides.
No, If the connection was built between LAN-WAN zone-pair and if some packets belonging the same flow ends up between WAN to WAN zones it will be dropped. Traffic arriving on a different interface than the pair of interfaces that built the connection is not supported and will be considered malicious and dropped. When traffic comes into ZBFW, the packet is checked against the existing session table. If this session matches what is in the table, we will try to forward the traffic through that existing session. This session matching overwrites the PASS policy that is configured on the interface.
No, this is not supported. Coexistence of interbox high availability (HA) and intrabox HA is not supported. Please refer this link for additional information: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/conf-fw-stateful-inter-chassis.html#GUID-A82FC656-1E00-4A5B-AB41-68C64D4DC1D3
Please refer this link for additional information: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/conf-fw-stateful-inter-chassis.html#GUID-A82FC656-1E00-4A5B-AB41-68C64D4DC1D3
By default, Network Address Translation (NAT) high availability (inter and intrabox) does not replicate HTTP sessions to the standby device. To replicate HTTP sessions on the standby device during a switchover, you must configure the ip nat switchover replication http command.
By default, when asymmetric routing is configured, Network Address Translation (NAT) processes non-ALG packets on the standby RG, instead of forwarding them to the active. The NAT-only configuration (that is when the firewall is not configured) can use both the active and standby RGs for processing packets.
You can configure the asymmetric-routing always-divert enable command to divert packets received on the standby RG to the active RG.
Please refer this link for more information: http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/sec-data-asym-route.html#GUID-6399763F-7B18-4F8C-8C89-16CB86A3E6BB
No, this is presently not supported. Only one RG per interface.
An asymmetric routing interface can receive traffic from and send traffic to multiple RGs. For non asymmetric interface (normal LAN interface) - 1:1 mapping exists between the interface and an RG.
No, control and data interface should not be part of any zone. This will cause COLD-BULK situation when zone-members are part of connections for which there is no rii group.
This is expected behavior. Even if the LAN interfaces are fine, when control interface breaks both units will go active. The workaround for this situation is to configure both control and data interfaces off of a port channel. They can use backup Ethernet connections if one of them fail. In this case both FE0/2/0 and FE0/2/3 both have to go down for the units to both go active.
redundancy mode none application redundancy group 1 name chand1 preempt priority 250 failover threshold 155 control Port-channel1.4011 protocol 1 data Port-channel1.4012 interface Port-channel1 no ip address interface Port-channel1.4011 encapsulation dot1Q 4011 primary FastEthernet0/2/0 secondary FastEthernet0/2/3 ip address 10.7.7.1 255.255.255.0 interface Port-channel1.4012 encapsulation dot1Q 4012 primary FastEthernet0/2/3 secondary FastEthernet0/2/0 ip address 10.4.4.1 255.255.255.0 interface FastEthernet0/2/0 no ip address negotiation auto channel-group 1 interface FastEthernet0/2/3 no ip address negotiation auto channel-group 1
No. RG and asymmetry should not be combined under one interface. RG interfaces will be used to replicate connections but asymmetric interface will not.
Yes. The pairs of redundant interfaces are configured with the same unique ID number known as the redundant interface identifier (RII). Please refer to this link for additional information: http://www.cisco.com/en/US/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/asr1000/iadnat-stateful-int-chass.html#GUID-799993C7-4264-4B31-B787-FE809DC80DAE
description control link
description data link
description control link
description data link