Link to home
Start Free TrialLog in
Avatar of Claudio Pisciottano
Claudio PisciottanoFlag for Italy

asked on

NAT locally a remote IP address

Hi all,
I need your help!
A new company supplier needs a VPN LAN to LAN with our Office. Remote router it's maybe a Cisco router (I don't know), and on my site, we use a Cisco ASA firewall. The requirement is that a public IP address is used as the encryption domain instead of our private subnet. That's ok, I did it, and it's working with a static NAT between a single server private IP address and a free Public IP address. But now I have to do the same with a private IP server address that is not on my local network, but I access remotely via a static route (it's a server in a branch office). I tried to do the same configuration with a static NAT, but it's not working, obviously.

I appreciate your suggestion.
Later I'll try to draw a schema.

Thanks you all
Avatar of hypercube
hypercube
Flag of United States of America image

I'm not sure where to begin:
So, I'll just start with the basics.
The two private subnets (one at each site) are *different*.  e.g. 192.168.1.0/24 and 192.168.33.0/24.  
When you set up the VPN, the remote subnet address is included in the local setup.  That way it's known.
That way, when you address one of those remote addresses, the router knows:
1) it is to be accessed via the VPN.
2) there is no NAT because the destination address is already correct.
Now, within the VPN there is NAT in the sense that it has to communicate over the public internet.  BUT, this is transparent except that the remote PUBLIC address also has to be entered into the local VPN setup.
The same is true for the remote VPN setup.

In this way, the VPN acts like a simple subnet-to-subnet router or bridge - sending packets between the two private subnets.

Caveats:
If the VPN device is NOT also the local gateway then the local gateway needs a route:
remote subnet address?  Send to local VPN IP Address.
Otherwise, you should see this in the local gateway routing table already (once the VPN is set up).
Fred is correct.  I have several site to site tunnels running but not on your gear.

Main two points:  Different subnets on each end; allow the complete subnet on each end to allow connections to all points.
No, he is not. We know second to nothing about the client side, and how they manage that configuration. However, for them it is a site-to-site tunnel only, and no automatoc configuration is done in regard of IPs and routes.

This question is about the "serving" site.

I assume there is no source IP NAT involved? Neither for the supplier nor the branch office? Then the branch office VPN gateway will have to know how to route interesting traffic for that supplier.
Alternatively you can source-NAT the supplier LAN IP to a free local main office IP. Then the packet should get passed back and forth by the branch office as if it were from main office without further branch office configuration changes.
We know second to nothing about the client side,   True.. I made an assumption that the author could ask the other side as they have the need to connect.
The demand of managing VPN traffic by natting to a public IP tells me enough about the other side - they won't be inclined to do anything more for sure.  And there is not much they could do to change the basic issue, which is hairpinning (VPN to VPN transfer) plus NAT plus two-site routing, all issues on the "local" site.
The only changable parts for the demanding site are to use a different address (won't change anything, as I suppose, though handling a private IP might be less prone to errors than a valid public IP), or run anohter tunnel to the branch office themselves.
Qlemo makes a good point.  But now I'm just confused:
A new company supplier needs a VPN LAN to LAN with our Office
I know what LAN to LAN means and that's what I figured on.  The normal thing.
The requirement is that a public IP address is used as the encryption domain instead of our private subnet.
This seems to suggest NOT LAN to LAN.
Thus my confusion.
Avatar of Claudio Pisciottano

ASKER

Hi all and really thanks.
@Qlemo is right because I don't have access and I can't ask to modify or add rules on the other routers, nor the external supplier nor the branch office. In attach the schema I draw; I hope it's clear enough.
The VPN peers are 1.1.1.248/28 and 3.3.3.202/29. The encryption domains are 2.2.2.224/27 and 4.4.4.112/28.
2.2.2.224/27 and 4.4.4.112/28 are Public IP addresses.
Supplier policy not accepts private rfc1918 addresses from trading partners. This includes 10.0.0.0–10.255.255.255 (10/8 prefix); 172.16.0.0–172.31.255.255 (172.16/12 prefix); 192.168.0.0–192.168.255.255 (192.168/16 prefix).
I must configure NAT on my VPN device and hide the private IP subnet behind public IP address.
I did it, and as I say, it's working. The Server_A traffic (192.168.4.101) it's correctly in the VPN tunnel.
My fault is on the Server_B (192.168.8.31) because it's not directly connected on my firewall, it's routed through the interface named "branch". A static NAT like
nat(branch,outside) static 4.4.4.116
it's not working, obviously.
Schema.pdf
That matches exactly what I expected as config.
Most probably the branch office does not know how to route traffic. Since you cannot change the config there, your only choice IMO is to also translate the source IP(s) of the supplier to local IPs of HQ. That should solve the routing problem.
I do not have a clue about the required ASA config changes for hairpinning, but that is a common configuration scenario - the same as getting acces to a branch using a client-to-site VPN terminated at the HQ (but with the added difficulty of the source NAT).
Hi Qlemo and thanks so much for your reply. I think you are on the focus, but why do you say that's about hairpinning? Traffic is on different interfaces (outside and branch), isn't?
How can I translate the external supplier IP addresses (2.2.2.224/27) to local IP addresses?
Thanks to everyone.
As said, I have no clue about ASAs. But if you indeed have different interfaces used, not just the outside and inside ones, it should be a matter of routing and ACLs only - after having applied source NAT.
Ok, thank you so much.

I don't know how to apply NAT, route, ACL in this configuration, as I have a static route for the remote branch on an interface (branch). The target server, Server_B 192.168.8.31, it's reachable via routing, but I have to NAT in local.
Does anyone have other suggestion from now on?
Thank you
Can someone help me with this kind of configuration? Thank you very much
What I think you are trying to acheive is

external vendor public address
 |
 Public to public VPN
 |
ASA Public Interface
 NAT Public address used in VPN to Private address on the ASA (but not on the same subnet as the LAN
ASA Private Interface
|
Router
|
 Link to remote office
|
Router
|
Host that needs to access vendor

Presuming that you used an address that is not on the same subnet as the LAN, the routers (or VPN tunnel cryptomap) need to have the private address for the NAT added to the configuration, and if the remote host has a different default gateway, it would also need a static route.
Hi ArneLovius, and thank you for your reply.
What I'm trying to achieve is what you describe, without a router hop:

external vendor public address
 |
 Public to public VPN
 |
ASA Public Interface
 NAT Public address used in VPN to Private address on the ASA (but not on the same subnet as the LAN
ASA Private Interface
|
 Link to remote office
|
Router
|
Host that needs to access vendor

There is news! I asked the remote branch to add in their router a static route to our new IP subnets (4.4.4.112/28), and they did it. But nothing is changed my site?

I don't understand what you mean, can you please help me consider my diagram example?

Thank you so much
Schema.pdf
so how is the remote office connected to the main office ?
@ArneLovius it's a MetroNid 100/100Mbs interconnection and the ends lands on a core switch (192.168.17.2 - branch office), on the ASA (192.168.17.1 - Main Office).
Thank you so much!
Please create a diagram of the network with appropriate IP addresses and include a suitably santised copy of the ASA config and of the remote route config
This question needs an answer!
Become an EE member today
7 DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.