Perform Conditional Static NAT with Dynamic External IP

[davidk3]

I've kind of simplified the reality here a little bit, just to kind of get to the heart of the matter:

We have a main office on network 192.168.0.0/16 and a branch office on network 10.19.0.0/16. The main office has a static public IP address on its external interface. The branch office does not; it's using DHCP. There is a site-to-site IPsec tunnel between the two locations. The branch office is behind a Cisco router, and is hosting a camera system at 10.19.10.3 on TCP port 2003. Currently we have the following command configured on the branch office router, to allow connections to the camera system from over the public internet using its public IP address:

ip nat inside source static tcp 10.19.10.3 2003 interface FastEthernet4 2003

Unfortunately this statement has the side effect of making it so we can't access the camera system from the main office via 10.19.10.3; we have to use the public IP address. We'd like to be able to use 10.19.10.3 to access it from the main office, though.

I'm not great at this networking stuff, but I was thinking the way to fix this would be to just find some way to make it so this NAT rule only gets applied when the camera system's being accessed from any IP besides 192.168.0.0/16; that way NAT would not be applied when accessing it from the main office. After some googling I found out about something called Policy NAT, where you can use an access list to specify when the rule should be applied. I'd then apply it using a command similar to the following:

ip nat inside source static tcp 10.19.10.3 2003 interface FastEthernet4 2003 route-map MYROUTEMAP

Unfortunately it looks like you can't use the "route-map" keyword after using the "interface" keyword to specify the second address in the command; you can only use "route-map" if the second address in the command is an actual IP address, as far as I can tell. Anyone know how we might be able to accomplish what we're trying to do here?

[Larry Sullivan]

Maybe post a diagram and sanitized configs.  You should be able to access the camera system over the IPsec VPN without any sort of NATing.  You have tunnel interfaces right?  Can you ping the camera system IP 10.19.10.3 from a Main office 192.168.0.x/16 IP?

[davidk3]

Yeah, we can ping the camera system no problem from the main office, but if we try to connect to it via https://10.19.10.3:2003 instead of the public IP address it won't work. I've always assumed this is because the return traffic from the camera system is matching the NAT rule, being NAT'ed to the interface's address, and therefore essentially not properly making it back to us. Historically this has never been a problem for us, though, because we just connect to it via the public IP address instead; but now, for certain reasons we're going to want to be able to connect to it via the private IP address now. I was hoping this could be done just by modifying that NAT rule to specifically not NAT traffic coming from the main office.

I have to be honest, I'm no expert at this networking stuff, but I can post a config if it's necessary. We don't have tunnel interfaces (I'm not really sure what that is, actually), the tunnel's using a crypto map applied to the physical interface. Thanks for the reply!

[paul driver]

Hello
Append your nat acl to deny nat between your internal subnet, my assumption is you have dynamic pat also applied for internet access?

Example;
access-list 100 deny host 10.19.10.3  x.x.x.x y.y.y.y
access-list 100 permit 10.19.10.0 0.0.9.255 any

ip nat inside source-list 100 interface FastEthernet4 overload 
iip nat inside source static tcp 10.19.10.3 2003 interface FastEthernet4 2003

[davidk3]

Thanks for replying! Unfortunately our configuration is already pretty much exactly as you've described; we are indeed using PAT, and our access list does indeed contain a deny statement so that our internal traffic is not subject to PAT, but this doesn't seem to be the fix for this. I think it's because the two commands (the NAT overload statement and the static NAT statement) are two different statements, so internal traffic is successfully not subjected to NAT overload due to the deny in the ACL, but it is still being subjected to the static NAT, because it's not being denied there.

[paul driver]

Hello

---

@davidk3 wrote:

I think it's because the two commands (the NAT overload statement and the static NAT statement) are two different statements,

---

You still need to make sure the overload acl is not including the host of your specific static nat statement, Im wondering if we are missing something or not taking into account, this should really be straight forward.

As suggested and if applicable can you post the nat statements that you now have running inducing any acls. or maybe run cfg of the rtr?

[davidk3]

Ok, below is our branch office router configuration:

Building configuration...

Current configuration : 3885 bytes
!
! Last configuration change at 08:09:36 MDT Thu Mar 23 2023 by admin
!
version 15.5
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
enable secret XXXX
!
no aaa new-model
ethernet lmi ce
clock timezone MST -7 0
clock summer-time MDT recurring
!
ip dhcp excluded-address 10.19.0.0 10.19.2.255
ip dhcp excluded-address 10.19.5.0 10.19.255.255
!
ip dhcp pool dhcp-pool
network 10.19.0.0 255.255.0.0
dns-server 192.168.5.12 192.168.5.16
default-router 10.19.5.1
domain-name XXXX
!
no ip domain lookup
ip domain name XXXX
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
license udi pid C881-K9 sn XXXX
!
username admin secret XXXX
!
no cdp run
!
crypto isakmp policy 1
encr aes
authentication pre-share
group 2
!
crypto isakmp peer address X.X.X.X
set aggressive-mode password XXXX
set aggressive-mode client-endpoint fqdn XXXX
!
crypto ipsec transform-set name-i-chose esp-aes esp-sha-hmac
mode tunnel
!
crypto map branchmap 10 ipsec-isakmp
set peer X.X.X.X
set transform-set name-i-chose
match address to-office
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
no ip address
!
interface FastEthernet4
ip address dhcp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
crypto map branchmap
!
interface Vlan1
description Connected to LAN 10.19.0.0/16
ip address 10.19.5.1 255.255.0.0
ip nat inside
ip virtual-reassembly in
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip nat inside source list nat-list interface FastEthernet4 overload
ip nat inside source static tcp 10.19.10.3 2003 interface FastEthernet4 2003
ip nat inside source static tcp 10.19.10.3 2004 interface FastEthernet4 2004
ip ssh version 2
!
ip access-list extended nat-list
deny ip 10.19.0.0 0.0.255.255 192.168.0.0 0.0.255.255
permit ip 10.19.0.0 0.0.255.255 any
ip access-list extended to-office
permit ip 10.19.0.0 0.0.255.255 192.168.0.0 0.0.255.255
!
control-plane
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
line con 0
logging synchronous
login local
no modem enable
line aux 0
line vty 0 4
logging synchronous
login local
transport input ssh
!
scheduler allocate 20000 1000
!
end

[Larry Sullivan]

Hmmmm, seems like you stepped in a black hole with this.  I'm assuming someone needs to access the camera system outside of the Main branch via public IP?  If not you can remove the port forward and just access over VPN?

I can think of one alternate solution that requires a reconfigure if you need both public and private IP access.  This is why I asked about there being a tunnel interface earlier.  If your VPN had a tunnel interface it would mitigate this issue, it would be easy to re-do on the Branch router, but the Main site depends on the device.

Something else that might be worth trying with the current setup is port forwarding with an arbitrary port on the outside to the inside, so say 1003 to 2003, then access 2003 from the Main site over VPN per normal.  Not sure if this would work but it's something I would try if I ran into this.

Just curious, when you try to access the camera system from the Main site and at Branch you do a "show ip nat translations" is there anything indicating a NAT translation for that Main to Branch Camera system in the translations?

[davidk3]

Yeah, so the actual situation is that we have a remote site that's not currently on DHCP, but we may be switching that site to StarLink at some point, which doesn't supply static IP addresses. This is renewing my interest in making it so we can connect successfully via the internal IP address, since now it will be more difficult to connect via the public IP address (seeing as how we won't necessarily know what it is anymore). Because of it being on DHCP, we probably really won't need the ability to connect over the public internet via its public IP address, because I'll just do the easiest thing and just tell everyone they can't connect to the cameras anymore now unless they're on an internal subnet; but I also just wanted to see what I could do about getting it to work, in order to keep our options open.

I did take a look at the output for "show ip nat translation" after attempting to connect from the main office, and it does indeed show a translation from 10.19.10.3:2003 to 192.168.9.6:58006 (my address), so I assume that kind of verifies that the problem is indeed that it's NAT'ing the return traffic.

I googled tunnel interfaces, and while I think I get the gist of it, I'm still not sure how it mitigates this issue. Does it "automatically" fix it just by virtue of existing, and if so is that because there'd now be a route to the main office which specifies a tunnel interface? Or would additional steps be needed over and above just implementing tunnel interfaces before the issue would actually be resolved?

I won't have a chance to try out the tunnel interface thing until Monday, but thank you again for your help!

[Larry Sullivan]

With the tunnel interface, there would be no NAT applied, it's an interface logically separate from the WAN interface, so NAT would work from inside interface to WAN outside interface per normal, but for site to site communications the Branch tunnel would have no "ip nat outside" applied, so no NAT taking place.

[davidk3]

Shortly after making the post above with the configuration the forum hid the post for some reason, so I basically re-posted it here. Then at some point the forum un-hid the post, so then I edited this post to remove the duplicate configuration!

[paul driver]

Hello
The issue is the nat order for external traffic, the static nat is associating the ports 2003-2004 with the outside interface,as such any external traffic for ports 2003-2004 will be natted before any routing takes place, I envisage if you leave those static nat statements in place and change the http host port to be anything else it will work via the main site on its internal address and new port number however then the outside nat will fail.

The most simplistic solution from what I can see and IF applicable to you would be to give that http host a secondary ip address but connect on the SAME port via that secondary address and leave the primary for external connection, that should work both for s2s and external traffic.

Additionally, this is something not really related, i would suggest append a specific default static for the nat router otherna leaving to dhcp tp assign.

Example:
ip route 0.0.0.0 0.0.0.0  FastEthernet4 dhcp

[davidk3]

Oh, ok, I guess I can see that, so if I could find a way to give the http host (the camera system) a secondary IP address that would help circumvent the issue. I'll see if that's something I can do, thank you!

[paul driver]

Hello
you should have no issue giving a host an secondary address and when you do i envisage it will solve your current problem