Static Translations Disappearing

My guess is that you are telling them to timeout.

ip nat translation tcp-timeout 900

Maybe a bug or maybe that's the way it is supposed to be?

router(config)#ip nat tra ?

tcp-timeout Specify timeout for NAT TCP flows timeout Specify timeout for dynamic NAT translations

Maybe since "timeout" is for "dynamic" translations tcp-timeout encompasses all translations.

I don't know -

I did look at information about 'tcp-timeout' on cisco.com before and it states that the command tcp-timeout "Specifies that the timeout value applies to the TCP port. Default is 86,400 seconds (24 hours)." which seemingly indicates the usual tcp-timeout limit for translations (dynamic I assume) is 24 hours. Surely if this value is running in the background by default then it should never affect static translations ?

I'll try replacing that 'tcp-timeout' for 'timeout' though as suggested.

Many thanks for the reply.

Hi,

It does seem odd. I will try that out here. I don't use static translations but will configure one just for fun so there will be no harm in setting a timeout on it.

Could be a bug.

I have never changes the default timeouts on NAT but then I haven't used it in a big installation really.

It would be interesting to know if you see the same thing there. I'm running IOS c837-k9o3sy6-mz.123-4.t at the moment.

I made the change and reloaded though I think it could take at least a few days before I'll know if things are looking better. :-|

Thanks for the help.

Just to update; I replaced the 'tcp-timeout' command with 'timeout' though after some time I still logged a static translation being removed:

%IPNAT-6-NAT_DELETED: Deleted tcp 192.168.1.2:54211 11.22.33.44:54211

Puzzled about what could be causing this I'm looking into a theory now. Though the 54211 port was forwarded the service that utilises this port wasn't running on the system at 192.168.1.2 at the time the entry was deleted. I looked at the source ports the system was using for outbound TCP communications shortly after this deletion event and it looks like the operating system had probably recently used ports in the region of the 54211 port (it was using source ports around 55000 and climbing when I looked) when establishing outbound connections.

I'm wondering if it might be possible that if the 192.168.1.2 system uses an unused, but forwarded (in the router) port, that the router creates an outbound dynamic NAT entry, then after the '900' seconds timeout period clears that entry which also causes the static translation to be cleared (?). Seems ridiculous that it would do that if that turns out to be the case!

For now I've removed the 900 second 'timeout' line completely to see if static translations will still get timed-out. I'll try to check what ports the 192.168.1.2 system uses close to a translation timeout too if I'm around to catch it to see if it looks related.

Still, any insight into this problem would be much appreciated if anyone has any ideas.

Cheers.

--------------------------------------------------------------------------

Well I'm at a loss. Here's how it goes;

A:1234 ---> c837 ---> Internet

The c837 router runs dynamic NAT for the local area network machines ('A' and others) to translate packets to and from the Internet. Simple enough.

Machine 'A' hosts services (on port 1234 for example) that are only active periodically. The c837 router has these service ports defined as static NAT 'forwarding' rules (see startup-config above). Access to the services works fine so long as the service is actively running on machine 'A'. If the 'port 1234' service is not running on machine 'A', the operating system will, when the need arises, utilise port '1234' for creation of outbound connections to the Internet, eg: A:1234 ---> c837 ---> google.com:80.

When it does this the Cisco 837 router creates a dynamic NAT entry like;

Created tcp A:1234 C837_WAN_IP:1234 google.com:80 google.com:80

Given the dynamic nature of that NAT entry it times out after a period of non-use (or FIN/RST is seen). When it does time out the dynamic entry is cleared, BUT, it also clears the router's static '1234' forwarding rule, e.g.;

Deleted tcp A:1234 C837_WAN_IP:1234 0.0.0.0:0 0.0.0.0:0

Instead of spending 180 hours trying to troubleshoot what you know should be working I would download three or four different versions of IOS for this router and see if they have the same behavior. It sounds to me like you are running into a NAT bug. I have found over the years of working with cisco (and working on TAC for 5 years) that if its configured correctly, but it doesn't work, its usually a ..ere undocumented feature or caveat as Cisco likes to call them. It wouldn't hurt to change IOS and see if you have the same behavior. I would try to change trains as well as versions, no telling if the bug is even fixed. Also you could check your version of IOS against the bug find tool, just do a cco search. Based on the testing you have done it kind of smells like a rat ..ere a bug.

-------- Original Message --------

--------------------------------------------------------------------------

Hey thanks for the reply.

Indeed I've spent a while trying to figure out the problem and can only assume so far that it's either a bug, or that I'm not knowledgable enough to know where I'm going wrong with the configuration (I'm new to IOS).

I have been thinking about trying other IOS versions, though, I could do with installing another 16MB of DRAM as the 12.3.(4)T IOS I'm running at present happily consumes most of the available DRAM (32MB) when the router gets busy (when the number of dynamic NAT translations hit the roof (2500+)). I do have some alternative IOS versions already though pretty much anything larger than 12.3.(4)T when decompressed won't fit in RAM without running into trouble. I could come down on versions (probably more sensible) though have been a bit reluctant to do so; a fault of my own really as I tend to believe higher versions should be the most evolved, stable, secure, etc software to use.

I looked into some alternative configuration methods to 'forward' the ports after posting here and, though not really understanding too much of what I was doing, did manage to find a workable solution, though to me it seems to be a bit of an awkward workaround. If I used the following to open a port;

ip nat inside source static udp 192.168.1.2 220 interface Dialer0 220

...then the problem would occur. If I do a 'show ip nat statistics' I get something akin to the following output;

Total active translations: 66 (0 static, 66 dynamic; ?? extended)

...where it just shows all translations being dynamic (0 static, not sure about the 'extended', I can't remember).

However, after playing around with things I found the following to work correctly;

ip nat inside source static tcp 192.168.1.2 220 123.123.123.123 220

...with "123.123.123.123" being my outside static IP address. If I do a 'show ip nat statistics' now I get something like the following;

Total active translations: 66 (16 static, 50 dynamic; 66 extended)

...where it now shows the static translations as actually being static. I think this is a bit daft really as the only reason I can do this is because I've a static IP address with the ISP. If I had a dynamic address then I don't see how folks could work around this problem so easily without frequent reconfiguration of the external address as and when it changes. :-s

I will try to get some more DRAM in the router sometime and run through some alternative IOS versions as you say.

Thanks again.

--------------------------------------------------------------------------