We have a site to site VPN which works perfectly ok. The host IP on our end is 192.168.35.10\32 which our vendor is accessing over the VPN tunnel.. no issues there.
Recently we had to modify the IP address of the host to 192.168.45.10\32 and instead of asking the vendor to modify the security policy on his end we wish to do the translation on our end, ie. NAT 192.168.35.10 to 192.168.45.10
In other words, the vendor will still access 192.168.35.10 from their end and our firewall should translate it to 192.168.45.10
Both IP's are on the inside of the firewall.
How does the nat look like?
I believe there is no need to modify the VPN config but only add a nat translation, is that true?
static (inside,outside) 192.168.35.10 192.168.45.10 netmask 255.255.255.255
Correct, no need to change any of the VPN config.
So basically our vendor will still access 192.168.35.10 and the firewall will translate this to 192.168.45.10, correct? Note that this IP 192.168.35.10 will no longer be valid on our internal network.
I initially thought of creating an ACL :
access-list translate permit ip host x.x.x.x host 192.168.35.10
global (inside) 1 access-list translate 192.168.45.10
where x.x.x.x is the host coming from the vendor (other side of the vpn)
I imagine both would work but your proposal is simpler, correct?
"So basically our vendor will still access 192.168.35.10 and the firewall will translate this to 192.168.45.10, correct?"
If you are not Natting 192.168.45.10 to any other IP address for external access then yes the static solution is simpler.
Jon, I have to admit, as always you are very helpful... let me bounce a similar question for you:
Say we want our vendor to access multiple hosts\segments on our internal network over this VPN we were discussing. But instead of exposing the segments\hosts, i think it is better if we give the vendor one single private IP address (different vlan) and then nat this IP to the hosts of interest on the inside... that way the vendor has no visibility to our internal network.
I guess the nat solution would not work because we want to lock down the access to specific devices on the inside.
What do you think?
"Say we want our vendor to access multiple hosts\segments on our internal network over this VPN we were discussing. But instead of exposing the segments\hosts, i think it is better if we give the vendor one single private IP address (different vlan) and then nat this IP to the hosts of interest on the inside... that way the vendor has no visibility to our internal network."
You can do this as long as each internal server is connected to on a different port(s) ie. you won't be able to have 2 internal servers natted to same address on the same port. But if the ports are unique to servers you could do this.
Bear in mind though that this is really an exmaple of security through obscurity. You are still allowing the vendor onto the servers and you should be locking down access for that vendor anyway so they can only access the servers you want them to.
But if the tunnel is one way, there is no need to introduce ports.
Of course, OS security is also applied.
The reason I introduced this is because nat'ing from the outside directly to the inside may not be ideal.
Lets say your Nat address that you present to the vendor is 10.5.1.1
Also you have 2 internal servers - 192.168.5.10, 192.168.5.11
you cannot do
static (inside,outside) 10.5.1.1 192.168.5.10
static (inside,outside) 10.5.1.1 192.168.5.11
because the firewall won't know which one to use. You also can't do
static (inside,outside) tcp 10.5.1.1 80 192.168.5.10 80
static (inside,outside) tcp 10.5.1.1 80 192.168.5.11 80
for the same reason as above.
But you could do -
static (inside,outside) tcp 10.5.1.1 80 192.168.5.10 80
static (inside,outside) tcp 10.5.1.1 443 192.168.5.11 443
because the ports are different so there is no ambiguity and the firewall will know which address to send it to.
"So in your example, 10.5.1.1 is the address that will be nonat'd and on the cryptomaps, correct?"
10.5.1.1 would be the address the vendor use to connect to your servers. Yes it would be the address used in the crypto map.
And there is a last scenario:
18.104.22.168 -- fw1 -- fw2 -- 22.214.171.124 & 126.96.36.199
so all hosts behind fw2 should be able to access 188.8.131.52 but not the other way.
so the idea is to have 184.108.40.206 point to 220.127.116.11 for the tunnel config (interesting traffic) and have a pat on fw2 that pats 18.104.22.168 & 22.214.171.124 to 126.96.36.199 when destined to 188.8.131.52
Does that make sense?
How would that look like?
so 184.108.40.206 has no visibility to the hosts behind fw2 and because there is no port associated (as in your previous example), 220.127.116.11 will not be able to access the hosts.
Here's the setup I came up with to hide the internal hosts:
object-group network MYHOSTS
network-object host 18.104.22.168
object-group network VENDORHOSTS
network-object host 22.214.171.124
access-list Inside_nat_outbound_3 extended permit ip object-group MYHOSTS object-group VENDORHOSTS
nat (Inside) 15 access-list Inside_nat_outbound_3
global (Outside) 15 126.96.36.199 netmask 255.255.255.255
crypto map Outside_map 3 match address Outside_3_cryptomap
crypto map Outside_map 3 set peer 188.8.131.52
crypto map Outside_map 3 set transform-set ESP-3DES-SHA
crypto map Outside_map 3 set security-association lifetime seconds 28800
crypto map Outside_map 3 set security-association lifetime kilobytes 4608000
access-list Outside_3_cryptomap extended permit ip host 184.108.40.206 object-group VENDORHOSTS
so basically traffic from MYHOSTS to VENDORHOSTS are PAT'd to 220.127.116.11 and therefore the vendor does not see my internal address (18.104.22.168), and this address(22.214.171.124)is applied on the cryptomaps. I noticed though that there are no nonat's in this setup.
Also when the traffic is coming from the VENDORHOSTS to MYHOSTS, it is pointing to 126.96.36.199, how is it being translated to 188.8.131.52? Is there a need for a
static (inside,outside) 184.108.40.206 220.127.116.11 netmask 255.255.255.255 ?