Start Free Trial

asked on

One to One NAT with VPN

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

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

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

ASKER

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!

Can you provide the information for your tunnel?

ASKER

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

Can you please run "clear ip nat trans *" and then "show ip nat trans" and provide the output here?

ASKER

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?

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.

ASKER

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.

ASKER

Are you still available to work with me on this? I would like to make the changes tonight.

Thanks!

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....

ASKER

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

Close. It should be "deny ip 192.168.80.0 0.0.0.255 host 71.x.x.35".

ASKER

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

ASKER

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

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.

Would something like this work?

I would say the best evidence is empirical evidence....

ASKER

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

ASKER

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

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.

ASKER

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?

Can you repost the full current config?

ASKER

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

Which is the terminal server having difficulty accessing the Internet?

ASKER

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

ASKER

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

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

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.