ASA5505 ASDM NAT with port forwarding question.

Started by KDog, May 20, 2016, 12:42:19 AM

Previous topic - Next topic

KDog

Hello all,
I'm sure this is stupidly simple but for the life of me I can't get this going.

I'm using a ASA5505 v9.2   ASDMv7.5. I have a cloud server which I need to link to an internal server, they talk on different ports.

How do I get the following to work (IP addresses are fictional):

Cloud server IP: 10.10.10.10 port 443
Internal Server IP: 192.168.0.20 port 8443
WAN IP: 172.16.0.30

I have lots of NAT rules running with no issues, I can get the NAT working for  192.168.0.20 to translate to 172.16.0.30 no problems. Traffic from Cloud server hits the Internal server, but on port 443 (internal server want to see port 8443).

What I can't get going is the Port forwarding part. I can't get the Cloud server port of 443 - to translate to the Internal Server port of 8443. How do I do this?

Any help greatly appreciated.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

deanwebb

Can the cloud server point its traffic to the NATted IP address, port 8443? Or must it arrive on 443?
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

KDog

I have no control over the cloud server port, so it always outputs on 443.

As a very last resort I could try changing the internal server port to 443 but its default is 8443 and a lot of config files would need to be changed I suspect.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

deanwebb

There's a way to do it... but I'm coming off of a 23-hour day, so I can't recall right now. :)
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

Dieselboy

Create your objects:


object network CLOUD-SERVER
host 10.10.10.10

object network GROUND-SERVER-INSIDE
host 192.168.0.20

object service HTTPS-SRC-REMAP
service tcp source eq 8443

object service HTTPS-SRC
service tcp source eq 443


Then do the nat rule:


nat (INSIDE,OUTSIDE) source static GROUND-SERVER-INSIDE interface service HTTPS-SRC-REMAP HTTPS-SRC


That will nat the servers inside IP address to the IP address you've given the OUTSIDE interface, and translate the servers source port from 8443 to 443 on the OUTSIDE interface.

Is that what you wanted to do?

If you have a static IP for the server itself and you're not NATting to the outside of the firewall then do the below:

Create the extra object for the WAN IP and then do the nat:

object network GROUND-SERVER-OUTSIDE
host 172.16.0.30

nat (INSIDE,OUTSIDE) source static GROUND-SERVER-INSIDE GROUND-SERVER-OUTSIDE service HTTPS-SRC-REMAP HTTPS-SRC


Just double check I've not got the service groups round the wrong way and the ASA outside IP is listening on the correct port that you need.

When you do the firewall rule, you need to specify the real IP and port not the NAT IP/port because you have a newer software code version. So your outside ACL will look something like


access-list OUTSIDE-INBOUND extended permit tcp object CLOUD-SERVER object GROUND-SERVER-INSIDE eq 8443


Please post back and let us know how you get on.

icecream-guy

thanks for those tips Dieselboy, may help me with my ASA NAT issues.
:professorcat:

My Moral Fibers have been cut.

KDog

#6
Quote from: Dieselboy on May 20, 2016, 05:59:44 AM

If you have a static IP for the server itself and you're not NATting to the outside of the firewall then do the below:

Create the extra object for the WAN IP and then do the nat:

object network GROUND-SERVER-OUTSIDE
host 172.16.0.30

nat (INSIDE,OUTSIDE) source static GROUND-SERVER-INSIDE GROUND-SERVER-OUTSIDE service HTTPS-SRC-REMAP HTTPS-SRC


Just double check I've not got the service groups round the wrong way and the ASA outside IP is listening on the correct port that you need.

When you do the firewall rule, you need to specify the real IP and port not the NAT IP/port because you have a newer software code version. So your outside ACL will look something like


access-list OUTSIDE-INBOUND extended permit tcp object CLOUD-SERVER object GROUND-SERVER-INSIDE eq 8443


Please post back and let us know how you get on.


Thank you Dieselboy I shall give the last one a try.

The Cloud Server actually has a bunch of IP addresses, so I have created an object group for them. I had the plain NAT working fine but couldn't find a combination using the ASDM where the port would also translate (pretty sure my access rules were ok, but I haven't enable both 443, 8443 for the time being).

Will update about success/failure in a couple of hours.

EDIT:
OK, so I impletemented the command, and it creates the NAT rule. In ASDM the NAT rule looks exactly like I had expected. Still doesn't work. Using packet tracer and logging I find that I am getting an Asymetric NAT rule error (similar error for not having a VPN Nat exepmt rule).

I have another NAT rule for the ServerInside to ServerOutside so that the Server can talk to the outside world and so I can ping it from outside etc. This rule is after the more specefic rule for port translation above.  There are also the more general NAT rules for the interfaces involved. I don't think either of these are interfering but I'm not really sure what to test or where to go from here to stop the Asymetric NAT error.

Note: The Asymetric NAT error only occurs when I use packet tracer, it doesn't appear on the logs when I actually try to connect to the internal server from the cloud server.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

Dieselboy

You're not really going to be able to have those two nat rules in place unless you configure one one of them to come into effect when targetting a destination address or subnet (ie make it more specific).

If you have the NAT rule there anyway to give the internal server IP an outside IP, you can copy that rule and then paste it above (more specific above) (in ASDM). When the box opens you can then say within the nat rule to do the port translation only when communicating with the cloud server IP ranges. The group you have created for the source IP's of the cloud servers will be fine. This will do the port transation for that server IP range and if this rule doesn't match then the ASA will go through to the next rule which I gather from your post is a static 1-1 nat.

If you have connections established through the ASA firewall and then you make a nat rule change, you need to clear the connections to get the nat rule to be used. Otherwise the ASA performs a lookup for an existing flow prior to running the nat rules. If an existing flow is matched then it is used as a shortcut and does not go through the nat rules.

KDog

#8
Quote from: Dieselboy on May 22, 2016, 08:29:28 PM
This will do the port transation for that server IP range and if this rule doesn't match then the ASA will go through to the next rule which I gather from your post is a static 1-1 nat.

If you have connections established through the ASA firewall and then you make a nat rule change, you need to clear the connections to get the nat rule to be used. Otherwise the ASA performs a lookup for an existing flow prior to running the nat rules. If an existing flow is matched then it is used as a shortcut and does not go through the nat rules.

The first part is how I have it configured. Port NAT then the next rule down is the general NAT.
I have been doing a clean xlate inbetween each change.

Edit:
I can't see any traffic heading to the internal server IP (from the cloud) in the logging when using the Port specific NAT, the only time I see traffic going to internal server in logging is when I have the 1:1 static NAT rule in place, dest port of 443.
So basically the NAT rule with port translation doesn't work.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

Dieselboy

Can you explain who's initiating the connection and what their source IP is and their destination IP/port is?

The way I understood it was this way:

cloud server 10.10.10.10 -> 172.16.0.30:443

and

ground server 192.168.0.20 -> 10.10.10.10:443

----

So to get the cloud server to communicate with the ground server through the firewall and to translate tcp ports we put the nat rule in place which should allow:
cloud server 10.10.10.10 -> 172.16.0.30:443 [ASA] -> 192.168.0.20:8443


what is not working exactly? How do you determine if it's working?
Have you captured traffic to see which part is not working? eg capture on the outside interface as well as the inside interface.

KDog

Quote from: Dieselboy on May 22, 2016, 11:00:09 PM
So to get the cloud server to communicate with the ground server through the firewall and to translate tcp ports we put the nat rule in place which should allow:
cloud server 10.10.10.10 -> 172.16.0.30:443 [ASA] -> 192.168.0.20:8443

Your understanding is correct. Cloud server 10.10.10.10 initiates the connection, dest port 443.
With a 1:1 static NAT in the logs (flitered for 192.168.0.20) I can see the 10.10.10.10 server trying to connect on 443.
With only a Port NAT rule in place, no static NAT rule underneath, I can't see any traffic going to 192.168.0.20 in the logging.

Cloud server 10.10.10.10 has a page to test connections (can choose destination port). Testing using outgoing 8443 works OK. But this is only for testing, the actual apps on the server have to output to dest port 443.

Thank you very much for you help. As far as I can tell everything you have suggested should work fine.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

Dieselboy

If testing using 8443 works fine then something is wrong.

The other way you can do the nat rule is to state it comes in to effect when the inside server speaks to the cloud server specifically:

nat (INSIDE,OUTSIDE) source static GROUND-SERVER-INSIDE GROUND-SERVER-OUTSIDE destination static CLOUD-SERVER CLOUD-SERVER service HTTPS-SRC-REMAP HTTPS-SRC

To explain, nat inside > outside
ground server real IP > ground server WAN IP
Destination is "cloud server" (this is stated twice as the destination is not modified by the nat rule)
service - present 8443  > 443

With only the above nat rule for that server, testing using port 8443 shouldn't work (unless there's another nat rule such as a static nat rule).

If it still doesn't work, are there possibly other nat rules which are being matched and breaking this?

Nerm

Would it be possible for you to post the results of a packet trace?

KDog

Thanks for all the help everyone.

I gave up  trying to get the ASA to work and used IPtables on the internal server to do a port translation.
Never argue with an idiot.
They will bring you down to their level and beat you with experience.

Dieselboy