Cisco FMC NAT

[shaikh.zaid22]

Hi,

I am facing some NAT config issues; the scenario is as follows:

I have a vm server(3.20) in AZurDC wants to access to URLs with another entity via ISP tunnel. I have a single NAT ip address(60.43) which is being natted on the FMC with NAT policy 1 and 2 for two different destination urls ip addresses.

Now when i try telnetting the first url ip address telnet x.x.60.43 443 it is working fine and NAT policy 1 is hitting correctly.

Now as soon as i do the same for the second url same NAT policy 1 is hitting and the second url destination is unreachable, since the NAT policy 2 is not hitting.

So is there a way in cisco firepower, i can use same virtual ip add to nat two different url ip addresses??

or i have to have a second virtual ip address configure to NAT the second url access?

Need guidance pls  

[MHM Cisco World]

you need to use different Port to make FPR using Policy1 or Policy2

[shaikh.zaid22]

since both url needed to be accessed on port 443 and from isp only port 443 is allowed, in that case how i differentiate the port for policy 1 and policy 2? 

Any configuration scenario document if available pls share.

[Marius Gunnerud]

The only way around this is to use different ports on the two NAT statements.  So in this case you would, for example, need to use tcp/443 for NAT 1 and then tcp/4433 for NAT 2.  The server side can remain as tcp/443.

The reason for this is that the FTD needs to know which internal IP to associate the traffic with.  If both servers use tcp/443 on the ingress interface using the same public IP, the FTD will always use the first match.  So if your ISP is only allowing tcp/443 towards your network, then you need to work with your ISP to allow other ports to get this working.

[MHM Cisco World]

Yes, I am totally agree with @Marius Gunnerud 
there is no workaround for this case.

[shaikh.zaid22]

Thanks @Marius Gunnerud for the response.

Today i advised our peerr about the same, either we can use different ports to differentiate the traffic for each destination OR else we can use a separate ip address to NAT the second url.

However, since i have Manual static NAT configured, just to confirm, for the port translation, i just have say for example configure Original port : 8443 and Translated Port :443. In this way if i configure the NAT policy for the second NAT policy do i still have to ask my ISP for any change? Because i think this port translation will happen in my firewall itself right?

And the first NAT policy i will keep as is with port translation i mean.

[MHM Cisco World]

No the original port will keep 443 and translate is 4443 or 8443 or any other.

The ISP must allow translate port you use.

Thanks 

MHM

[shaikh.zaid22]

Thank @MHM Cisco World 

How come ? Because my internal PC will be going to access the service https://xyz.com outside.

So the origination dest port :8443 and Translated dest port :443 right?

I have attached  a snapshot pls review

[Marius Gunnerud]

How the translated and original ports are defined really depend on how you confingure your NAT direction / zones.  If you are configuring NAT with source zone Outside then the original port would be 8443 and translated port 443.

Remember that static NAT is bi-directional so it doesn't really matter if you configure NAT from Outside to Inside or Inside to Outside.  what is important is that you remain consistant in how you configure NAT.  Meaning if you configure NAT from Outside to Inside, all other NAT rules should follow this same principle as it will make the configuration easier to read and understand in the future.

[shaikh.zaid22 · Accepted solution]

Thanks @Marius Gunnerud and @MHM Cisco World for the responses which made me think in correct direction.

today the connectivity established successfully by using Auto-NAT policy, wherein the original address : 172.x.x.x(og server ip) and translated source address: 10.x.x.x(Nat ip) for both the destination URLs.

Additionally, we did not have to configure any port translation with this approach. This way when the server admin telnets to any destination URLs on port 443, based on the destination requests getting pass until the ISP(wherein the ISP router is configured according to lookup the destination address to route appropriately).

Hence, this way we tested and traffic was leaving our perimeter successfully.

Tough two days ended with a smile

Thank you guys once again for the responses really appreciated.

[MHM Cisco World]

finally happy ending 
great Job friend 
and have a nice day 
MHM