Solved

One to One NAT with VPN

Posted on 2014-12-02
28
281 Views
Last Modified: 2014-12-22
I have a client where I need to perform a one-to-one NAT on three of their terminal servers for external access. When I NAT everything works just fine, however traffic from the terminal server no longer can reach the other end of the existing VPN tunnel.

Do I need to build another route map or create a no-nat ACL for this?

interface FastEthernet8
 ip address 71.x.x.34
 ip access-group outside-in in
 no ip redirects
 no ip unreachables
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 crypto map TUNNEL

ip nat inside source route-map NAT_TO_ISP interface FastEthernet8 overload
ip nat inside source static 192.168.80.41 71.x.x.36
ip nat inside source static 192.168.80.42 71.x.x.37
ip nat inside source static 192.168.80.43 71.x.x.38

ip access-list extended outside-in
 permit esp any host 71.x.x.34
 permit ahp any host 71.x.x.34
 permit gre any host 71.x.x.34
 permit tcp any host 71.x.x.36 eq 3389
 permit tcp any host 71.x.x.37 eq 3389
 permit tcp any host 71.x.x.38 eq 3389

ip access-list extended outbound-nat-list
 deny   ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255
 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
 permit ip 192.168.80.0 0.0.0.255 any

route-map NAT_TO_ISP permit 10
 match ip address outbound-nat-list
 match interface FastEthernet8
0
Comment
Question by:lconnell
  • 16
  • 12
28 Comments
 
LVL 28

Assisted Solution

by:asavener
asavener earned 500 total points
Comment Utility
This is an issue with order of operations.  NAT takes place before CRYPTO, so the traffic from the terminal servers is being NAT'd, but then it doesn't match the interesting traffic for the VPN.


You can fix it several ways.

First, you can use route-maps on your NAT rules, so that inside-to-inside traffic is not NAT'd.

Alternately, you can add the public IPs of your terminal servers to the list of traffic that is permitted over the VPN.

Third, I've seen folks pull tricks with loopback interfaces and route maps, so that the traffic from the terminal servers doesn't ever go from a nat inside interface to a nat outside interface, as long as the other end is a VPN user.  This prevents the NAT rule from being triggered.

Fourth, you can modify your VPN so that it uses a GRE tunnel.  That way, the traffic from the terminal servers will not transit the outside interface, and will not be NAT'd.

Finally, and this is probably easiest, you can use PAT rules instead of NAT rules.  If you only publish port 3389, then VPN traffic to/from your terminal servers won't match an existing NAT rule.


Try this:

no ip nat inside source static 192.168.80.41 71.x.x.36
ip nat inside source static tcp 192.168.80.41 3389 71.x.x.36 3389

(repeat for the other two rules)

(You might have to execute "no ip nat trans *" to get the above commands to work)
0
 

Author Comment

by:lconnell
Comment Utility
Ok, that worked and makes it easier as you said, thank you. I have another question that is related. In this situation I am doing a one-to-one NAT, as soon as I apply the access-group I can no longer get to 443 on 71.x.x.35. In addition to that, how would I get the host 192.168.80.39 to go over that VPN tunnel we talked about earlier?  Can you show me an example using either the route-map or the public ip to the permitted VPN traffic?

interface FastEthernet8
 ip address 71.x.x.34 255.255.255.240
 ip access-group outside-in in

ip access-list extended outside-in
 permit tcp any host 71.x.x.35 eq 443

ip nat inside source static 192.168.80.39 71.x.x.35
0
 

Author Comment

by:lconnell
Comment Utility
So, I ended up breaking the users over the tunnel that were accessing the terminal server on 3389. I assume I have to change something in the tunnel acl as discussed above since NAT happens before CRYPTO. Looking forward to your response. :)

Thanks!
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Can you provide the information for your tunnel?
0
 

Author Comment

by:lconnell
Comment Utility
ip access-list extended TUNNEL_ACL
 permit ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255

interface FastEthernet8
 ip address 71.x.x.34 255.255.255.240
 no ip redirects
 no ip unreachables
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 crypto map TUNNEL

interface Vlan1
 ip address 192.168.80.1 255.255.255.0
 no ip redirects
 no ip unreachables
 ip nat inside
 ip virtual-reassembly in

!
crypto isakmp policy 5
 encr aes
 authentication pre-share
 group 2
crypto isakmp key ****** address 64.x.x.76
!
!
crypto ipsec transform-set AES-SHA esp-aes esp-sha-hmac
!
crypto map TUNNEL 1 ipsec-isakmp
 set peer 64.x.x.76
 set transform-set AES-SHA
 match address TUNNEL_ACL
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Can you please run "clear ip nat trans *" and then "show ip nat trans" and provide the output here?
0
 

Author Comment

by:lconnell
Comment Utility
I don't have the nat in place anymore since it causes issues with users on the other side of the tunnel connecting to the terminal server on port 3389.

I can try again at night and send the output if you'd like. Is this a matter of adding the public ip of the nat statement to the interesting traffic ACL?
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
It's good practice to run "clear ip nat trans *" after making changes to your NAT rules, because it forces the router to rebuild any NAT rules.  Even after you remove a NAT translation in the configuration, the router can still have NAT translations in its database.  My hope was that clearing the NAT translations table would eliminate the issues for the VPN users.

Setting this up with a PAT rule should work just fine, and it keeps your VPN configuration clean.
0
 

Author Comment

by:lconnell
Comment Utility
Keep in mind that the users can communicate across the tunnel with no problem, it's only to that specific server on port 3389 in which I have a NAT statement for that is the issue.

ip nat inside source static tcp 192.168.80.41 3389 71.x.x.36 3389

Removing that statement allows the users to connect to 192.168.80.41:3389.
0
 

Author Comment

by:lconnell
Comment Utility
Are you still available to work with me on this? I would like to make the changes tonight.

Thanks!
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
It's fairly straight forward.  Add the NAT rules like before, then edit the VPN access lists:

ip access-list extended TUNNEL_ACL
 permit ip host 71.x.x.35  192.168.32.0 0.0.0.255
 permit ip host 71.x.x.36  192.168.32.0 0.0.0.255

and then on the remote branch add these two lines to the tunnel access-list:

 permit ip 192.168.32.0 0.0.0.255 host 71.x.x.35  
 permit ip 192.168.32.0 0.0.0.255 host 71.x.x.36


You may have to exclude those two public IPs from the dynamic NAT, though, since NAT takes place before crypto....
0
 

Author Comment

by:lconnell
Comment Utility
Ok, so you're saying I may need to add 71.x.x.35 to...

ip access-list extended outbound-nat-list
 deny   ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255
 deny   ip 71.x.x.35 0.0.0.0 192.168.32.0 0.0.0.255
 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
 permit ip 192.168.80.0 0.0.0.255 any
 permit ip 192.168.81.0 0.0.0.255 any
 permit ip 192.168.79.0 0.0.0.255 any
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Close.  It should be "deny ip 192.168.80.0 0.0.0.255 host 71.x.x.35".
0
 

Author Comment

by:lconnell
Comment Utility
i added the commands above, cleared the nat, still can't access the host via it's private ip over the tunnel.

ip access-list extended outbound-nat-list
 deny   ip 192.168.80.0 0.0.0.255 host 71.11.15.35
 deny   ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255

ip access-list extended TUNNEL_ACL
 permit ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255
 permit ip host 71.x.x.35 192.168.32.0 0.0.0.255

** remote side **

access-list TUNNEL_ACL extended permit ip 192.168.32.0 255.255.255.0 host 71.x.x.35
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 

Author Comment

by:lconnell
Comment Utility
Would something like this work? This way it doesn't NAT if it's destination is the remote network?

ip access-list extended exchange_nat
 deny 192.168.80.39 0.0.0.0 192.168.32.0 0.0.0.255
 permit 192.168.80.39 0.0.0.0 any

route-map NAT_EXCHANGE permit 20
  match ip address exchange_nat

ip nat inside source static 192.168.80.39 71.x.x.35 route-map NAT_EXCHANGE extendable
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
i added the commands above, cleared the nat, still can't access the host via it's private ip over the tunnel.
They would need to use the public IP when it's configured that way.
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Would something like this work?
I would say the best evidence is empirical evidence....
0
 

Author Comment

by:lconnell
Comment Utility
The following code worked perfectly :). It translated my port from the outside and did not attempt to translate when communicating with 192.168.32.0 which is on the other side of the tunnel.

ip nat inside source static tcp 192.168.80.41 3389 71.x.x.36 3389 route-map NAT_TO_TOWN extendable
ip nat inside source static 192.168.80.39 0.0.0.0 71.x.x.35 0.0.0.0 route-map NAT_TO_TOWN extendable

ip access-list extended town_nat_list
 deny   ip host 192.168.80.39 192.168.32.0 0.0.0.255
 permit ip host 192.168.80.39 any

route-map NAT_TO_TOWN permit 10
 match ip address town_nat_list

Open in new window

0
 

Author Comment

by:lconnell
Comment Utility
With that fixed I tried to apply my acl to the outside interface to lock it down and the tunnel stopped working. I could connect  to one of the terminal servers via the public ip address, however once logged in, it could not access the internet until I added 'permit ip any any' to the acl, which also brought the tunnel back up.  I don't understand why. I know this is a separate question from my original. I can create a new question....

ip access-list extended outside-in
 permit tcp any host 71.x.x.36 eq 3389
 permit esp any host 71.x.x.34
 permit ahp any host 71.x.x.34
 permit gre any host 71.x.x.34
 permit ip any any <----- this fixed it but obviously this is not what I want.

int fa8
  ip access-group outside-in in
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Yeah, I've seen this on some IOS-based routers when you apply an access list on the outside interface.

Remember order of operations.   Decryption happens earlier in the order than encryption.  So I think decryption is taking place before checking the access list.

Instead of allow any any, try allowing from the source private subnet to the terminal server private address.
0
 

Author Comment

by:lconnell
Comment Utility
OK great that makes sense. How about the terminal server which had nothing to do with the tunnel not being able to access the internet? 192.168.80.x which is being NAT'd?
0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Can you repost the full current config?
0
 

Author Comment

by:lconnell
Comment Utility
crypto map TOWN_TUNNEL 1 ipsec-isakmp
 set peer x.x.x.x
 set transform-set AES-SHA
 match address TOWN_TUNNEL_ACL
!
interface FastEthernet8
 ip address 71.x.x.34 255.255.255.240
 ip access-group outside-in in
 no ip redirects
 no ip unreachables
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
 crypto map TOWN_TUNNEL

interface Vlan1
 ip address 192.168.80.1 255.255.255.0
 no ip redirects
 no ip unreachables
 ip nat inside
 ip virtual-reassembly in

ip nat inside source route-map NAT_TO_ISP interface FastEthernet8 overload
ip nat inside source static 192.168.80.39 71.x.x.35 route-map NAT_TO_TOWN extendable
ip nat inside source static tcp 192.168.80.41 3389 71.x.x.36 3389 route-map NAT_TO_TOWN extendable
ip nat inside source static tcp 192.168.80.42 3389 71.x.x.37 3389 extendable
ip nat inside source static tcp 192.168.80.43 3389 71.x.x.38 3389 extendable
ip route 0.0.0.0 0.0.0.0 71.x.x.33

!
ip access-list extended TOWN_TUNNEL_ACL
 permit ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255

ip access-list extended outbound-nat-list
 deny   ip 192.168.80.0 0.0.0.255 192.168.32.0 0.0.0.255
 deny   ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
 permit ip 192.168.80.0 0.0.0.255 any

ip access-list extended outside-in
 permit tcp any host 71.x.x.35 eq 443
 permit tcp host 208.x.x.164 host 71.x.x.35 eq smtp
 permit tcp any host 71.x.x.34 eq 22
 permit tcp any host 71.x.x.34 eq telnet
 permit tcp any host 71.x.x.36 eq 3389
 permit tcp any host 71.x.x.37 eq 3389
 permit tcp any host 71.x.x.38 eq 3389
 permit esp any host 71.x.x.34
 permit ahp any host 71.x.x.34
 permit gre any host 71.x.x.34
 permit ip any any

ip access-list extended town_nat_list
 deny   ip host 192.168.80.39 192.168.32.0 0.0.0.255
 permit ip host 192.168.80.39 any
!
!
!
!
!
route-map NAT_TO_ISP permit 10
 match ip address outbound-nat-list
 match interface FastEthernet8
!
route-map NAT_TO_TOWN permit 10
 match ip address town_nat_list
!

Open in new window

0
 
LVL 28

Expert Comment

by:asavener
Comment Utility
Which is the terminal server having difficulty accessing the Internet?
0
 

Author Comment

by:lconnell
Comment Utility
ip nat inside source static tcp 192.168.80.41 3389 71.x.x.36 3389 route-map NAT_TO_TOWN extendable
0
 

Author Comment

by:lconnell
Comment Utility
Looks like we got it figured out. I added the following and it is working, maybe the ip inspect firewall in fixed the outgoing internet issue...? Then added the udp isakmp rule which fixed the tunnel.

int vlan 1
  ip inspect firewall in

ip access-list extended outside-in
 permit tcp any host 71.x.x.36 eq 3389
 permit udp host 96.x.x.158 host 71.x.x.34 eq isakmp
 permit esp host 96.x.x.158 host 71.x.x.34

Open in new window

0
 
LVL 28

Accepted Solution

by:
asavener earned 500 total points
Comment Utility
You should almost never use ip inspect firewall in.  IP inspect firewall out is the normal usage.  (To dynamically open return ports when a client makes an outbound connection.)

IP inspect firewall in is a security vulnerability, in almost every case.  The fact that traffic is allowed with it enabled is not an indication that it is the correct configuration.
0
 

Author Comment

by:lconnell
Comment Utility
Yes, thank you. I misunderstood the flow of traffic in regards to the inspection functionality. You apply it outgoing so it knows what should be allowed coming back in, bypassing the ACL.
0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Join & Write a Comment

From Cisco ASA version 8.3, the Network Address Translation (NAT) configuration has been completely redesigned and it may be helpful to have the syntax configuration for both at a glance. You may as well want to read official Cisco published AS…
Problem Description:   Couple of months ago we upgraded the ADSL line at our branch office from Home to Business line. The purpose of transforming the service to have static public IP’s. We were in need for public IP’s to publish our web resour…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now