0

I have been trying to work out how to accomplish PATing from Outside to Inside on a Cisco IOS router, in this case specifically a Cisco 2901 running IOS Version 15.1(4)M1.

Firstly, the problem I am trying to solve is that we'd like external port forwards to work regardless of which connection is the default gateway.
On this particular router we have two WAN connections. One is on the built in Gig0/0 interface and the other by an EHWIC card exposing Gig0/0/0.

An example port forward rule in this device:
ip nat inside source static tcp 192.168.1.10 3389 x.x.x.x 3389 extendable

Where x.x.x.x is the IP address of interface Gig0/0/0.

This works fine if Gig0/0/0 is the default gateway for the router, however if Gig0/0 is the default gateway the port forward breaks.

It's also worth noting that the Gig0/1 interface is the default gateway for all LAN computers and servers, and is designated ip nat inside where Gig0/0 and Gig0/0/0 are both ip nat outside.

I am performing my standard Inside to Outside PAT by using route-map items which matches my NAT ACL with the interface.

I know I can mess around with ip nat outside and NAT pools, but is there a cleaner way I can achieve what I want? Even if I'm going about it the complete wrong way and NAT/PAT isn't the solution to my problem, pointing me in the right direction would be a major help!

The only reason why I think this is my best bet is the fact that every firewall device I've used has functionality in its policies to perform source NAT translation to the IP address of the egress interface, and it is so simple to turn on!

Edit: Watered down config

interface GigabitEthernet0/0
 description ----WAN_INTERFACE_PRI----
 mtu 1596
 ip address x.x.x.x 255.255.255.248
 ip access-group SECURE-IN in
 ip flow ingress
 ip nat outside
 ip virtual-reassembly in
 duplex full
 speed 1000
 no cdp enable
 service-policy output EthernetAccessService
!
interface GigabitEthernet0/1
 description ----INTERNAL----
 ip address 192.168.1.1 255.255.255.0
 ip access-group OUT-FILTER in
 no ip redirects
 no ip proxy-arp
 ip flow ingress
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface GigabitEthernet0/0/0
 description ----WAN_INTERFACE_BACK----
 ip address y.y.y.y 255.255.254.0
 no ip redirects
 no ip proxy-arp
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat inside source static tcp 192.168.1.10 3389 interface GigabitEthernet0/0/0 3389
ip nat inside source route-map BACK_WAN interface GigabitEthernet0/0/0 overload no-payload
ip nat inside source route-map PRI_WAN interface GigabitEthernet0/0 overload no-payload
! <Many port forwards cut>
ip route 0.0.0.0 0.0.0.0 (x.x.x.x Gateway) permanent
ip route 0.0.0.0 0.0.0.0 (y.y.y.y Gateway) 10 permanent
!
ip access-list extended NAT-ACL
 permit ip 192.168.1.0 0.0.0.255 any
 deny   ip any any
ip access-list extended OUT-FILTER
 permit icmp any any
 permit ip object-group Unrestricted-Access-Group any
 deny   ip 192.168.1.0 0.0.0.255 any
 deny   ip any any
ip access-list extended SECURE-IN
 permit ip host <allowed telnet/ssh addresses> any
 deny   tcp any any eq telnet log
 deny   tcp any any eq 22 log
 permit ip any any
!
no cdp run
!
!
!
route-map PRI_WAN permit 10
 match ip address NAT-ACL
 match interface GigabitEthernet0/0
!
route-map BACK_WAN permit 10
 match ip address NAT-ACL
 match interface GigabitEthernet0/0/0
Antix
  • 383
  • 1
  • 6
  • 19

1 Answers1

0

From what I understand, you have two internet connections on the router - I assume for redundancy. Can I assume that if Gi0/0/0 goes down, then Gi0/0 takes over your internet connection?

If that is the case, then the reason the PAT translation stops working is because the public IP address that is used by Gi0/0/0 for port 3389 is no longer available

Can you not just add a second line:

ip nat inside source static tcp 192.168.1.10 3389 y.y.y.y 3389 extendable

Where y.y.y.y is the IP address of your Gi0/0 interface.

If I've misunderstood, please describe the configuration in more detail, or better yet, post your config.

ChadH360
  • 414
  • 2
  • 3
  • That's correct, two internet connections for redundancy except our Gi0/0 is primary - so in the normal operating case where both connections are physically up, and the default gateway is the Primary Gi0/0, we cannot come in through the Backup Gi0/0/0 using the 3389 port forward. Doing a wireshark actually shows the packets hitting the destination server but what happens after that I'm guessing the router is sending return traffic out the default route instead of the WAN of the source of the traffic (which should be Gi0/0/0). Hope that clears it up a bit – Antix Apr 20 '15 at 13:18
  • Thanks. Can you clarify a bit further. Are both of these interfaces up at the same time, or does the backup kick in in the event of the primary failing. Do the two connections have different public IP addresses or is there a shared address space? Can you post a cleansed version of your config. – ChadH360 Apr 20 '15 at 22:15
  • Not a problem, yes both interfaces are up at the same time and both have different public IP addresses. I have updated my question to include a shortened config. Also last night I confirmed that return traffic was indeed exiting the router out of Gig0/0 rather than Gig0/0/0, when I attempted to RDP to y.y.y.y:3389 – Antix Apr 20 '15 at 23:46
  • Thanks for the additional info. This should be do-able with a route map. I can look into this for you tomorrow, but just don't have the time right now. However, one quick, dirty fix would be to assign a second internal IP address to the machine you are RDPing to, and then adjust your PAT for one of the interfaces to point to that address instead. That should cure your route issue. Like I say, a route map should do it, and that would be the preferred solution. – ChadH360 Apr 21 '15 at 00:03
  • I've just taken another look at your config, and you are missing the 'extendable' keyword at the end of the static PAT entry. Extendable is required when using duplicate local or global addresses. With that correction, my original answer should then work. – ChadH360 Apr 21 '15 at 07:27
  • Thanks for that, I haven't had a chance to test this again but will get back to you once I have. I'm pretty sure I tried the NAT entry both with extendable and without, but I'll get a concrete answer – Antix Apr 22 '15 at 13:58