Transitioning ASA NAT/PAT Rules to ISR Router

[CW7]

Hi all,

Am making the transition from an ASA to a Cisco ISR Router. Trying to figure out how to transition all my PAT rules from ASA format to ISR. On ASA I am doing PAT on a public IP to three different mail clients on my LAN. The public IP is on the block of IPs assigned to my ASA. On ASA you create objects, create object nat, create access rules. So an ASA config looks like this.

object network Mail1
host 192.168.20.151

object network Mail2
host 192.168.20.150

object network Mail3
host 192.168.20.152

object network Mail1
nat (any,any) static 56.25.3.6 service tcp 1677 1678
object network Mail2
nat (any,any) static 56.25.3.6 service tcp 1677 1677
object network Mail3
nat (any,any) static 56.25.3.6 service tcp 1677 1679

object-group service Mail_Ports tcp
port-object eq 1677
port-object eq 1678
port-object eq 1679

access-list WAN_access_in extended permit tcp any4 object Mail1 object-group Mail_Ports
access-list WAN_access_in extended permit tcp any4 object Mail2 object-group Mail_Ports
access-list WAN_access_in extended permit tcp any4 object Mail3 object-group Mail_Ports

The ISR, however, has object groups, but no object nat that I can see. Can someone point me in the right direction on how to program the above PAT and access rules to where they would work on ISR router?

[Georg Pauwen · Accepted solution]

Hello,

I think object groups can be used only in access lists on the ISR. Either way, the below should be the equivalent of your ASA config. Static NAT entries have been used:

object-group network MAIL_SERVERS_OBJ_GROUP
host 192.168.20.151
host 192.168.20.150
host 192.168.20.152

object-group service MAIL_PORTS_TCP_OBJ_GROUP
tcp range 1677 1679

ip access-list extended WAN_ACCESS_IN_ACL
permit tcp object-group MAIL_SERVERS_OBJ_GROUP object-group MAIL_PORTS_TCP_OBJ_GROUP

ip nat inside source static tcp 192.168.20.150 1677 56.25.3.6 1677
ip nat inside source static tcp 192.168.20.151 1677 56.25.3.6 1678
ip nat inside source static tcp 192.168.20.152 1677 56.25.3.6 1679

[CW7]

Thanks guys for answers, both ways look right.  Do you need a command to apply the access list to an interface?  For example on the ASA to apply the access list to incoming traffic on the WAN you use the command:

access-group WAN_access_in in interface WAN

Am assuming I need to do something similar on the ISR?

[Georg Pauwen]

Hello,

the command is sort of similar:

interface GigabitEthernet0/0

ip access-group WAN_ACCESS_IN_ACL in

[CW7]

Thanks, that is most helpful.  One final question if I may.  I have an  ISR4431 with the K9Security bundle.  Out of the box does this router act as a basic firewall like the ASA does, or do the firewall features have to be preconfigured?  Out of the box I see no ACLs, so am assuming the router is wide open.  I will have a FirePower Appliance between the router and my network, it just feels odd leaving a router wide open on the edge of my network : -).  Hard concept for me as I have always worked with ASAs.

[Georg Pauwen]

Hello,

the ISR is 'wide open', with no ACLs or anything preconfigured security wise like on the ASA...

It basically behaves just like any other out of the box IOS router...

[paul driver · Accepted solution]

Hello

As this rtr seems to be going to be wan facing and your are migrating nat rules from asa to iOS-xe suggest you implement some software based security features on the rtr because as @Georg Pauwen  so correctly stated the rtr isn’t like a Fw and it wide open to security threats so you could  possibly look hardening the rtr.

CBAC or ZBFW are two software features you could look at  the latter being more flexible as it doesn’t tie you to a single interface.

Zbfw

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/15-mt/sec-data-zbf-15-mt-book/sec-zone-pol-fw.html

Cbac 

https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/13814-32.html

Hardening iOS  

https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.pdf

[CW7]

Thank you both for some excellent advice and pointing me in the right direction.  I agree, that having a naked router on the edge of my network is not good.  Even though the FirePower Appliance will handle the bulk of the security, a little extra protection never hurts.

[CW7]

Thank you both for some excellent advice and pointing me in the right direction.  I agree, that having a naked router on the edge of my network is not good.  Even though the FirePower Appliance will handle the bulk of the security, a little extra protection never hurts.

[paul driver]

Hello

Another possible solution :

access-list 100 permit tcp host 192.168.20.151 any range 1677 1678
access-list 101 permit tcp host 192.168.20.150 any eq 1677
access-list 102 permit tcp host 192.168.20.152 any range 1677 1679

route-map Mail1 permit 10
match ip address 100

route-map Mail2 permit 10
match ip address 101

route-map Mail3 permit 10
match ip address 102

ip nat pool MailSrv 56.25.3.6 56.25.3.6 prefix-length 24
ip nat inside source route-map Mail1 pool MailSrv
ip nat inside source route-map Mail2 pool MailSrv
ip nat inside source route-map Mail3 pool MailSrv