Solved

One to One NAT with VPN

Posted on 2014-12-02
28
298 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 16
  • 12
28 Comments
 
LVL 28

Assisted Solution

by:asavener
asavener earned 500 total points
ID: 40476643
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
ID: 40477797
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
ID: 40478349
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
Get Actionable Data from Your Monitoring Solution

Your communication platform is only as good as the relevance of the information you send. Ensure your alerts get to the right people every time with actionable responses. Create escalation rules that ensure everyone follows the process and nothing is left to chance.

 
LVL 28

Expert Comment

by:asavener
ID: 40478464
Can you provide the information for your tunnel?
0
 

Author Comment

by:lconnell
ID: 40478816
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
ID: 40478852
Can you please run "clear ip nat trans *" and then "show ip nat trans" and provide the output here?
0
 

Author Comment

by:lconnell
ID: 40481420
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
ID: 40481535
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
ID: 40482677
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
ID: 40496451
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
ID: 40496465
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
ID: 40496843
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
ID: 40496873
Close.  It should be "deny ip 192.168.80.0 0.0.0.255 host 71.x.x.35".
0
 

Author Comment

by:lconnell
ID: 40503974
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
 

Author Comment

by:lconnell
ID: 40504011
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
ID: 40504660
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
ID: 40504663
Would something like this work?
I would say the best evidence is empirical evidence....
0
 

Author Comment

by:lconnell
ID: 40511204
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
ID: 40511208
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
ID: 40511721
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
ID: 40511756
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
ID: 40511949
Can you repost the full current config?
0
 

Author Comment

by:lconnell
ID: 40512008
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
ID: 40512142
Which is the terminal server having difficulty accessing the Internet?
0
 

Author Comment

by:lconnell
ID: 40512166
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
ID: 40512295
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
ID: 40512402
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
ID: 40513042
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

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Use of TCL script on Cisco devices:  - create file and merge it with running configuration to apply configuration changes
Many of the companies I’ve worked with have embraced cloud solutions due to their desire to “get out of the datacenter business.” The ability to achieve better security and availability, and the speed with which they are able to deploy, is far grea…
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…
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

717 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