ASA 5510 UDP NAT problem

Hello all,

Just received new ASA 5510 and am doing initial testing and config in my lab. I have set up three interfaces

e0/0 as inside security=100 e0/1 as dmz security=50 e0/2 as outside security=0

I used the following statement to set up dynamic nat

nat (inside) 1 0.0.0.0 0.0.0.0 global (outside) 1 interface

I have two simple access lists configured for testing.

access-list inside_in extended permit icmp any any echo access-list inside_in deny ip any any

access-list outside_in permit icmp any any echo-reply

So here's what I'm seeing:

When I ping an address on the outside, it works fine. The address is properly NAT'd and I get the reply. If I try to telnet out to a device, it blocks it as expected as per the access-list.

Now the strange part. My 6509 in my lab is running the the config from my production switch and is configured to hit a NTP server on our internal network. This VLAN is not up in the lab. So it is sending NTP UDP packets looking for the server. Since that NTP server is not there and the VLAN is not up, the 6509 is sending these requests out the default route which sends them to the ASA 5510.

I am seeing these UDP packets coming out of the outside interface of the ASA. They also are not being NAT'd Which is quite disturbing.

We are moving to this from another firewall and this is my first go around with a Cisco firewall, so I'm sure I'm just missing something.

Thanks for your help,

Will

Reply to
will74103
Loading thread data ...

Update:

I just applied the nat-control command. This did not have any effect. The UDP packets are still being routed thru the ASA and are not NAT'd.

Reply to
will74103

OK. I removed the NAT commands, reloaded the ASA, re-entered the same NAT commands. This seemed to relieve the problem. No more of the NTP packets showing up outbound on the ASA outside interface. The ACL that is denying all IP on the inside interface is incrementing. So it looks like it is working as expected now.

But this should not have had to be reloaded to resolve this. Is it possible that a clear local-host would have cleared this up?

Your thoughts on this appreciated.

Thanks,

Will

Reply to
will74103

After making any translation changes it is best practice to issue the clear xlate command, this will clear the translations in the firewall already, what you did by reloading the firewall basically did this as well but you should not have to reload the firewall

Reply to
Smokey

Thanks for the input. I had seen this, but had not thought of trying it.

Any thoughts on why this was initially not meeting any of that nat rules and being routed without being translated?

Reply to
will74103

nat (inside) 1 0.0.0.0 0.0.0.0

Instead of using 0.0.0.0 0.0.0.0 I would suggest limiting the statement to your internal subnet.

net (inside) 1 192.168.0.0 255.255.255.0

Reply to
Smokey

I need to allow access from multiple subnets. Would this require multiple NAT statements or can an access list be used to classify traffic. I haven't seen a good example of doing this in any of the materials that I have. Using the 0.0.0.0 mask was the suggestion in the command reference.

But I will be playing with it over the next couple of weeks.

Reply to
will74103

You can use multiple nat (inside) 1 statements each naming a different subnet, or (with PIX 6.3) you can use nat with an access-list .

If you do use nat with an access-list, be sure to look up the priority order for the various forms of the 'nat' command.

Reply to
Walter Roberson

Very cool. access-list in place and working well.

Reply to
will74103

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.