cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
832
Views
0
Helpful
5
Replies
Beginner

NAT won't work on a single IP in the middle of a block

Hi,

I've got a Cisco 887VA-W router that is handling a /29 block of IPs.  I have several VLANs that are used for tenants, guests, etc.  For the most part this all works correctly, however one of the IPs in the range will not NAT for reasons unknown.  There is no reference to it anywhere else in the config, and to the best of my knowledge the upstream router (which ours is physically connected to, but I do not have config access to) is not doing anything with it.

Here is a sample of the config:

interface FastEthernet0
 description LAN router to WAN router
 no ip address
!
interface FastEthernet1
 description LAN router to LAN switch
 switchport trunk allowed vlan 1,2,100,250,500,501,600,1002-1005
 switchport mode trunk
 no ip address
!

interface Vlan1
 description LAN router to WAN router
 ip address 1.1.1.185 255.255.255.248
 ip access-group INBOUND-ACL in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nbar protocol-discovery
 ip nat outside
 ip inspect ACL-CBAC-INSPECT out
 ip virtual-reassembly in
!         
….
interface Vlan500
 description TENANT 1 VLAN
 ip address 10.100.0.1 255.255.255.0
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
!   
….     
interface Vlan600
 description TENANT 2 VLAN
 ip address 10.200.0.1 255.255.255.0
 ip flow ingress
 ip flow egress
 ip nat inside
 ip virtual-reassembly in
!
….
ip nat pool TENANT-1-WAN 1.1.1.189 1.1.1.189 prefix-length 30
ip nat pool TENANT-2-WAN 1.1.1.188 1.1.1.188 prefix-length 30
ip nat inside source list TENANT-1-NAT pool TENANT-1-WAN overload
ip nat inside source list TENANT-2-NAT pool TENANT-2-WAN overload
ip nat inside source list OTHERS-NAT interface Vlan1 overload
….
ip access-list extended TENANT-2-NAT
 remark -- Block NAT traffic to RFC1918 addresses explicitly
 deny   ip any 10.0.0.0 0.255.255.255
 deny   ip any 172.16.0.0 0.15.255.255
 deny   ip any 192.168.0.0 0.0.255.255
 deny   ip any 224.0.0.0 15.255.255.255
 deny   ip any 127.0.0.0 0.255.255.255
 permit ip 10.200.0.0 0.0.0.255 any
ip access-list extended TENANT-1-NAT
 remark -- Block NAT traffic to RFC1918 addresses explicitly
 deny   ip any 10.0.0.0 0.255.255.255
 deny   ip any 172.16.0.0 0.15.255.255
 deny   ip any 192.168.0.0 0.0.255.255
 deny   ip any 224.0.0.0 15.255.255.255
 deny   ip any 127.0.0.0 0.255.255.255
 permit ip 10.100.0.0 0.0.0.255 any
 permit ip 10.101.0.0 0.0.0.255 any


And the output from "sh ip nat stat" is as follows:

Total active translations: 2195 (9 static, 2186 dynamic; 2194 extended)
Peak translations: 3790, occurred 00:02:17 ago
Outside interfaces:
  Vlan1
Inside interfaces:
  Vlan100, Vlan250, Vlan500, Vlan501, Vlan600
Hits: 8088307  Misses: 0
CEF Translated packets: 7998159, CEF Punted packets: 83220
Expired translations: 112977
Dynamic mappings:
-- Inside Source
[Id: 12] access-list TENANT-2-NAT pool TENANT-2-WAN refcount 0
 pool TENANT-2-WAN: netmask 255.255.255.252
    start 1.1.1.188 end 1.1.1.188
    type generic, total addresses 1, allocated 0 (0%), misses 802
[Id: 9] access-list TENANT-1-NAT pool TENANT-1-WAN refcount 108
 pool TENANT-1-WAN: netmask 255.255.255.252
    start 1.1.1.189 end 1.1.1.189
    type generic, total addresses 1, allocated 1 (100%), misses 0
[Id: 3] access-list OTHERS-NAT interface Vlan1 refcount 2071

Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

As you can see there are a lot of misses on the TENANT-2-NAT statistics, and no allocated address.

Clients on VLAN 500 can get to the internet, and their WAN IP is 1.1.1.189 as expected.
Clients on VLAN 600 can't get to the internet, they just get Destination Net Unreachable from 10.200.0.1

Anyone have any thoughts about what is going wrong here?  The upstream provider is adamant that this is "customer error".

Thanks in advance,

Darren

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Thanks Darren, 

Thanks Darren, 

This clarifies things for me. My understanding is that the prefix length command in NAT pool configuration should accurately reflect your /29 block. The translation list will still match the source addresses of your respective companies and translate accordingly. 

I recreated your issue  and I have the same results. I receive a syslog message that reads the following for the .188 pool: 

%IPNAT-4-ADDR_ALLOC_FAILURE: Address allocation failed for 10.200.0.1, pool TENANT-2-WAN might be exhausted.....

By changing my configuration to: 

ip nat pool TENANT-1-WAN 1.1.1.189 1.1.1.189 prefix-length 29
ip nat pool TENANT-2-WAN 1.1.1.188 1.1.1.188 prefix-length 29

ip nat inside source list TENANT-1-NAT pool TENANT-1-WAN overload
ip nat inside source list TENANT-2-NAT pool TENANT-2-WAN overload

The issue was corrected and translations from VLAN 500 and 600 (sources of either 10.200.0.x or 10.100.0.x) always reflected the desired global source IP addresses when packets were debugged on the distant end post-translation.  

I'm trying to find certain confirmation of the exact impact the "prefix-length" portion of the command provides, but the pool size for any given source-list is defined with the IP address range configured with the NAT pool, which you have correctly configured to only reflect the specific IP you want each companies' traffic to be translated to. 

My best guess for now is that the "prefix-length" portion of the source pool configuration is there as a safeguard to prevent you from allocating IPs outside of your actual pool subnet range but I don't have any official documentation to support that theory yet, nor do I know why you don't get a warning when you attempt to put in an address that would be considered a network address based on the prefix-length parameters you provide. 

If you attempt to allocated an IP address pool that is larger than the prefix-list value given you'll see the following output: 

TENANT-2-WAN prefix length <x> too large; should be no more than <x>

But you won't get an error when an IP address in your pool would be considered a network address (Even though NAT was not working for me when I did).

I hope this is useful for you. Let me know if I'm still not understanding your concerns. 

Thank you!

5 REPLIES 5
Cisco Employee

Hi Darren,

Hi Darren,

I might be missing something but 1.1.1.188/30 would be the network address and not a usable host address. That might be your issue. Are you attempting to NAT to usable addresses in two different subnets?

Beginner

The ip nat pool command lets

The ip nat pool command lets you use prefix-length 32, but complains about it.

Essentially I have the 1.1.1.185/29 block (.185-.189 useable, .190 is gateway IP),   and I want to be able to have different VLANs route out on different IPs within this block.  This is because there is a legal separation between at least two entities that are sharing the same internet connection, so in simple terms I don't want Company B to be seen on the internet coming from the same IP as Company A.

The TENANT-1-WAN line works as expected, NATs and presents on the internet as 1.1.1.189.  I naively assumed the same lines with a different ACL and external IP would work the same, but they don't.

If I add a line like:
ip nat inside source static 10.200.0.5 1.1.1.188 extendable

..then the computer on VLAN 600 with IP 10.200.0.5 can get to the internet, and presents as 1.1.1.188 correctly.  This makes me think there isn't anything specifically wrong with the upstream router, but that I'm hitting some kind of internal limitation, or ARP/NAT issue.

I've tried rebooting the router incidentally and it has made no difference.

Highlighted
Cisco Employee

Thanks Darren, 

Thanks Darren, 

This clarifies things for me. My understanding is that the prefix length command in NAT pool configuration should accurately reflect your /29 block. The translation list will still match the source addresses of your respective companies and translate accordingly. 

I recreated your issue  and I have the same results. I receive a syslog message that reads the following for the .188 pool: 

%IPNAT-4-ADDR_ALLOC_FAILURE: Address allocation failed for 10.200.0.1, pool TENANT-2-WAN might be exhausted.....

By changing my configuration to: 

ip nat pool TENANT-1-WAN 1.1.1.189 1.1.1.189 prefix-length 29
ip nat pool TENANT-2-WAN 1.1.1.188 1.1.1.188 prefix-length 29

ip nat inside source list TENANT-1-NAT pool TENANT-1-WAN overload
ip nat inside source list TENANT-2-NAT pool TENANT-2-WAN overload

The issue was corrected and translations from VLAN 500 and 600 (sources of either 10.200.0.x or 10.100.0.x) always reflected the desired global source IP addresses when packets were debugged on the distant end post-translation.  

I'm trying to find certain confirmation of the exact impact the "prefix-length" portion of the command provides, but the pool size for any given source-list is defined with the IP address range configured with the NAT pool, which you have correctly configured to only reflect the specific IP you want each companies' traffic to be translated to. 

My best guess for now is that the "prefix-length" portion of the source pool configuration is there as a safeguard to prevent you from allocating IPs outside of your actual pool subnet range but I don't have any official documentation to support that theory yet, nor do I know why you don't get a warning when you attempt to put in an address that would be considered a network address based on the prefix-length parameters you provide. 

If you attempt to allocated an IP address pool that is larger than the prefix-list value given you'll see the following output: 

TENANT-2-WAN prefix length <x> too large; should be no more than <x>

But you won't get an error when an IP address in your pool would be considered a network address (Even though NAT was not working for me when I did).

I hope this is useful for you. Let me know if I'm still not understanding your concerns. 

Thank you!

Beginner

You're a star. Thanks for

You're a star. Thanks for such a comprehensive answer.

Now that you've pointed it out I don't honestly know why I hadn't thought of trying prefix-length 29 to match the block. I think I was thinking it in terms of limiting the pool (though even prefix-length 30 doesn't make sense in that context)

The fact it worked for the other one also fooled me into thinking it was correct, as you say there are no warnings. 

Could you tell me how you got that syslog output? What debugging commands you used etc. Would be useful for next time :)

Again many thanks. Haven't had time to verify that it works for my configuration but satisfied that it will.

Cisco Employee

It's a pleasure Darren, I'm

It's a pleasure Darren, I'm glad this information was useful for you! 

That's the interesting thing, that output popped up all on its own. No debugs needed. I was running IOS 15.2. Perhaps you have logging severity set to a different value? 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards