Nat – Symmetric NAT conflict with port forwarding

Your cleanup rule on your inside interface has nothing to do with your issue.

Modern firwalls are statful so you don't need to explicitly allow traffic to go back to the original source.

What you need to do is to allow traffic from ANY to the NATED IP of your server.

access-list outside_access_in extended permit udp any host W_BASE object-group W_UDP

Then do a simple static NAT.

static (inside,outside) interface W_BASE netmask 255.255.255.255

Since you are not forwarding the ports, you can keep your NAT very simple and simply open the correct ports with your ACL.

You could also simplify your service objects like so:

object-group service W_Ports
 service-object tcp eq 3005
 service-object udp range 3000 3002

Then use W_Ports instead of having W_UDP and W_TCP.

Your ACL would then look like this:

access-list outside_access_in extended permit object-group W_Ports any object-group W_BASE

UPDATED version:

access-list outside_access_in extended permit object-group W_UDP any host W_BASE

From our chat...so others may not get the full conversation, but the basics are here.

So basic NAT = source address:port >> external address:port >> NAT>> new source address:port >> external address port

with symmetric NAT it is a static mapping and the same every time and for both source AND destination.

Example: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"in a client-server application where the client initiates the communication) a server could not communicate back the other way unless it were explicitly permitted by the NAT device."

that part you say is incorrect it should read:

in a client-server application where the client initiates the communication) a server CAN communicate back the other way AFTER the source establishes the session OVER the ports used in the session.

Meaning if 2.2.2.2:43424 goes to 5.5.5.5:80 then 5.5.5.5:80 sends information back to 2.2.2.2:43424 once the session is established. In your sentence...the session would only ever be source communicating to destination with destination never replying with packets/info/graphics/whatever.

"We have an issue in our environment where a well-known remote support tool cannot be used by an equally well-known software vendor to provide support to us. The client is proxy-aware, but for some reson it thinks it might be a good idea not to use it and do something completely different via UDP on port 1153."

That could be because they simply block Logmein/Teamviewer/whatever at a port level since they ask to use a different port...so they think if you'll allow or communicate on 1153 it will circumvent their own IT restrictions...best I can think of without knowing in detail what app or full details. Nothing to do with symmetric NAT or UDP hole punching really...at least as far as the issue they are bringing up itself is concerned.

I would recommend talking to their support team on what remote support tool they do work with OR working with them to determine a way to use the tool you like. If it means certain port NATing/rules then you'll need to work with them and your Networking team to figure that part out.

Hope that all helps.