[c-nsp] "extendable, incomplete" NAT entries
Hi all, We are observing strange problem regarding NAT. Two of our boxes (Cisco 7201) with NAT enabled create "extendable, incomplete" NAT entries, like this: --- 172.16.100.10 192.168.20.20--- --- create 18:00:36, use 00:00:29 timeout:8640, left 23:59:30, Map-Id(In): 32, flags: extendable, incomplete, use_count: 7, entry-id: 2949, lc_entries: 0 Main problem is that with such entries present in the NAT table, inside host is reachable from the outside by global address, and this is obvious security flaw. We had 15.1(4)M4 on this boxes, then changed it to 15.2(4)M8, but without success, entries are still appearing from time to time. NAT configuration is really simple: dynamic translations with pools, route-maps and access-lists. Thanks in advance -- Regards, Sergey ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] "extendable, incomplete" NAT entries
On 10/13/2015 05:51 PM, Gert Doering wrote: Hi, On Tue, Oct 13, 2015 at 05:40:08PM +0300, oldnick wrote: Main problem is that with such entries present in the NAT table, inside host is reachable from the outside by global address, and this is obvious security flaw. Your *problem* is a funny security architecture, relying on NAT... ;-) Valid point. But nevertheless, I find it quite interesting why such entries could be created. My google-foo didn't give any possible explanation and 7201 box is EOL, so no TAC support. NAT configuration of this boxes looks like this: ip nat pool test-nat 172.16.100.10 172.16.100.10 prefix-length 24 ip nat inside source route-map test-nat-map pool test-nat overload route-map test-nat-map permit 10 match ip address test-nat-acl ip access-list extended test-nat-acl deny ip 192.168.20.0 0.0.0.255 10.0.0.0 0.0.0.255 permit ip 192.168.20.0 0.0.0.255 any May be someone had an experience regarding under what conditions could "extendable, incomplete" entries be created? Thanks But without seeing the actual configuration of the routers, it is just a bit hard to comment where the "extensible" part is coming from - it could just be configured that way. gert -- Regards, Sergey ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] "extendable, incomplete" NAT entries
Thank you, Nick. Problem is, there is no static entries on this boxes: Router#show running-config all | i static|extendable Router# And if I am not wrong, this entries are dynamic: have "use", "timeout" and "left" fields. On 10/13/2015 09:31 PM, Nick Cutting wrote: And in new versions of IOS - it adds it to the config, whether you added the keyword it or not: On a CSR 15.5 (INE LAB): R5#sh run | s nat ip nat outside ip nat inside ip nat inside source static tcp 155.1.8.8 80 202.221.217.114 80 extendable ip nat inside source static 155.1.10.10 202.221.217.114 -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Cutting Sent: 13 October 2015 19:28 To: oldnick; cisco-nsp@puck.nether.net Cc: Gert Doering Subject: Re: [c-nsp] "extendable, incomplete" NAT entries Extendable usually means that there is a static 1-to1 nat AND a port nat on the same entry, not sure about incomplete though - you must be confusing the router "The extendable keyword allows the user to configure several ambiguous static translations, where an ambiguous translations are translations with the same local or global address." -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of oldnick Sent: 13 October 2015 19:22 To: cisco-nsp@puck.nether.net Cc: Gert Doering Subject: Re: [c-nsp] "extendable, incomplete" NAT entries On 10/13/2015 05:51 PM, Gert Doering wrote: Hi, On Tue, Oct 13, 2015 at 05:40:08PM +0300, oldnick wrote: Main problem is that with such entries present in the NAT table, inside host is reachable from the outside by global address, and this is obvious security flaw. Your *problem* is a funny security architecture, relying on NAT... ;-) Valid point. But nevertheless, I find it quite interesting why such entries could be created. My google-foo didn't give any possible explanation and 7201 box is EOL, so no TAC support. NAT configuration of this boxes looks like this: ip nat pool test-nat 172.16.100.10 172.16.100.10 prefix-length 24 ip nat inside source route-map test-nat-map pool test-nat overload route-map test-nat-map permit 10 match ip address test-nat-acl ip access-list extended test-nat-acl deny ip 192.168.20.0 0.0.0.255 10.0.0.0 0.0.0.255 permit ip 192.168.20.0 0.0.0.255 any May be someone had an experience regarding under what conditions could "extendable, incomplete" entries be created? Thanks But without seeing the actual configuration of the routers, it is just a bit hard to comment where the "extensible" part is coming from - it could just be configured that way. gert -- Regards, Sergey ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] WARNING: Netflow Hardware assisted NAT not supported on 65xx on the same interface even with Sup2T
Hi all, I leave it here JFTR, to prevent someone else to make the same error as I did with NAT, Netflow and Sup2T (just as Matthew Huff did before me with Sup720). According to Cisco because of CSCud36118, enabling NAT (ip nat outside) and Flexible NetFlow (ip flow monitor MonitorFlow input) on the same interface force NAT traffic to be software switched even with Sup2T. Although TAC states that this is software limitation, I've been told that there it no plan to support this feature combination in hardware. HTH -Original Message- From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Matthew Huff Sent: Friday, August 26, 2011 10:26 AM To: 'cisco-nsp at puck.nether.net' Subject: [c-nsp] WARNING: Netflow Data Export Hardware assisted NAT not supported on 76xx/65xx on the same interface Last winter we purchased a pair of 7606 routers to use out at the NYSE colo facility. We connect via a 1gb fiber to the SFTI LCN for market data and FIX traffic. We fully expected to be able to use hardware assisted NAT and NDE to monitor the traffic. The netflow output we get is random, sporadic and very incomplete. After dealing with our Sales team and TAC, we have finally got them to admit that it doesn't work when NAT and NDE are configured on the same interface. Nowhere in the Cisco marketing literature, Cisco Documentation, or even Cisco bug lists does it mention this. There are some caveats listed regarding NDE and NAT (flow mask conflicts, and fragments), but even given that, the caveats imply that it will work if the caveats don't apply or the flowmask conflicts are resolved. Also, there are no warnings when configuring it. The feature manager shows no errors or conflicts, etc... At every step, in my opinion, cisco has been reluctant to admit that it doesn't work. Only when confronted with the evidence, they did finally admit it. Had we known of this limitation, we would have purchased different hardware including possibly another vendor's solution. I'm looking at using SPAN to replicate the data and send it to a linux box to then create netflow data exports, however, given the nature of the data (high bandwidth and microburst), I'm not sure that the Linux box will work accurately. I assumed the PFC would be doing the exports in hardware giving us the most accurate realtime look at the market data. Evidently I was wrong. I'm sending this so that no one else will make the same mistake we did as well as being in the nsp archives. Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff| Fax: 914-460-4139 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
