Good suggestion! - I tested this and found that setting this value to anything other 1 second (and that includes '0' and 'never') results in complete packet loss from the 'straight through; nat , ie .149.250 -> .149.250
If this is just a ICMP and NAT interaction oddity, then thats OK - my main...
This is the only bit of the configuration I can see as being relevant:
The other router from the HSRP group has not been deployed yet - gateway for the server is xx.xxx.149.1, and this setup *APPEARS* to work fine for web traffic, but of course its easier to see pings going astray.
interface...
No, it is "ip nat inside source static xx.xxx.149.250 xx.xxx.149.250 extendable" - I put this line in because without it there was no response at all from xx.xxx.149.250. I've just removed the line to verify that behaviour.
There's also been a change in the behaviour with the original...
I'm not sure what you mean - do you see a typo that I don't? This line is cut from the configuration. Without it, the NAT address is reachable, but the 'un-natted' one isn't.
thanks.
Aidan.
I'm using IP, not URL, and I'm pinging from an IP address which is outside the 'ip nat outside' address.
Pings work fine when either nat rule is in place on its own, but not with both together.
Thanks,
Aidan.
I have a single web server which I need to access by two IPs while moving from one subnet to another. Can anyone explain why it is not possible to ping both outside global addresses with the rules in place, but it is possible to access them via a browser? The 'debug ip nat' command shows both...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.