Static TCP NAT rule causing issues when routing from internal VPN

[Drew T]

A bit of a curly one.

I have a small network of routers that are all connected back to a single site via a crypto-map and matching subnets in ACL's.

In addition, I have an inbound static TCP NAT rule on the same inbound interface to a host on the internal LAN (on the main router that all sites VPN's terminate back to):

ip nat inside source static tcp 192.168.0.1 499 interface GigabitEthernet0/2 499

This works fine (ie. if I go to the IP of Gi0/2, on port 499 from the general internet, it works).

The problem comes from other sites. The other sites all use subnets in 192.168.x.x and are using IPSEC via a crypto-map on each interface back to this router. The destination is the IP address for Gi0/2 on the main router. The IPSEC has been up and running for some time, working fine. 

From a remote site, I can ping 192.168.0.1, I can connect to any other port but if I try to connect to port 499, it times out.

All other sites have NAT disabled when trying to access 192.168.0.0/24 (on the main router) so it should not be hitting the static NAT rule from Gi0/2 to the internal host. 

I have tried a few different ACL/route-map configs on the main router to attempt to force anything originating from another site to not NAT to TCP 499 on that host, but it hasn't worked.

Has anyone seen something like this before? Quite urgent to fix this. 

[Jon Marshall]

You do need to use a route map for this. 

I am on phone so searching a bit limited but I found a previous thread where I answered

Just follow the links :)

Jon 

[Drew T]

Thanks Jon, which thread was it? :)

[Jon Marshall]

Sorry, obviously answering on a phone is too complicated for me :) 

Here it is - 

https://supportforums.cisco.com/discussion/12547961/service-access-nat-and-vpn-conflict

Jon

[Drew T · Accepted solution]

Thanks Jon :)

I must have it wrong. Here's the sanised config...

ip nat inside source static tcp 192.168.0.205 499 x.x.x.x 499 route-map no-nat-ipsec extendable

! It's added the 'extendable' by default; can't seem to remove that

ip access-list extended deny_nat_172_16

 permit ip 192.168.0.0 0.0.255.255 host 192.168.0.205

!

ip access-list extended permit_any

 permit ip any any

!

route-map no-nat-ipsec deny 10

 match ip address deny_nat_172_16

route-map no-nat-ipsec permit 20

 match ip address permit_any

!

With that in place, the outside world NAT to the inside 192.168.0.205 tcp 499 works fine, but still failing from anything on the IPSEC network. (trying from 192.168.48.254 to 192.168.0.205 on 499 and it fails, but if I try from 192.168.48.80 to 192.168.0.205 port 80, it's fine). 

should route-map counters increment for NAT translations? I'm not seeing any in a show route-map:

route-map no-nat-ipsec, deny, sequence 10

  Match clauses:

    ip address (access-lists): deny_nat_172_16 

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

route-map no-nat-ipsec, permit, sequence 20

  Match clauses:

    ip address (access-lists): permit_any 

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

Thanks again for your help.

[Jon Marshall · Accepted solution]

Managed to lab this up today. 

Can you change  - 

"permit ip 192.168.0.0 0.0.255.255 host 192.168.0.205" 

to 

"permit ip host 192.168.0.205 192.168.0.0 0.0.255.255" 

and retest. 

Jon 

[Drew T]

Ahh that looks to have done the trick. Port 499 is now accessible from the outside world via the NAT to internal, and from other networks on the IPSEC mesh also appear to be working (At least telneting from source interfaces on the remote routers). Will have to get the customer to check locally but think you've saved the day :) Thanks a heap!

Just out of interest, i'm assuming the counters won't increment on the route-map when used in a nat capacity? sh route-map shows 0 packets/bytes on both. 

[Jon Marshall]

Didn't check the counters to be honest so would have to setup the lab again but they don't always increment if I remember correctly. 

Glad to hear it seems like it is working.

Jon

[Drew T]

Talk about rotten timing with the forum migration!

Did you have any suggestions Jon (or anyone else)? I figured the config posted should be working.

[Jon Marshall]

Yes, not the best timing :)

Looks to me like it should work so if I get the chance tomorrow I'll knock up a quick lab and have a look. 

I can't do the IPSEC part but that shouldn't matter, it is really the NAT from two different places that needs testing, hopefully get back to you tomorrow. 

Jon