NAT with DMZ

[sebastien3]

Hello,

Currently I have a central router that allows me to manage backup via a secondary link. It works correctly !

Now I have to add a firewall which will be in DMZ. All ISP-1 and IPS-2 (if ISP-1 become down) traffic must enter the Firewall.

My problem is the use of the ip nat inside source static command for DMZ to be able to manage the two ISPs in the event of a switchover.

interface GigabitEthernet0
  description * DMZ to Firewall .100 *
 ip address 10.0.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
interface GigabitEthernet8
 description * Primary WAN *
 ip address 1.1.1.1 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
!
interface GigabitEthernet9
 description * Secondary WAN *
 ip address 2.2.2.1 255.255.255.252
 ip nat outside
 ip virtual-reassembly in
!
ip nat inside source route-map ISP-1 interface GigabitEthernet8 overload
ip nat inside source route-map ISP-2 interface GigabitEthernet9 overload
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet8 1.1.1.2 name PRIMARY track 1
ip route 0.0.0.0 0.0.0.0 GigabitEthernet9 2.2.2.2 10 name SECONDARY
!
route-map ISP-1 permit 10
 match ip address 101
 match interface GigabitEthernet8
!
route-map ISP-2 permit 10
 match ip address 101
 match interface GigabitEthernet9
!
access-list 101 permit ip 10.0.1.0 0.0.0.255 any
!
ip nat inside source static 10.0.1.100 ISP-1/ISP-2 extendable

How to manage two ip nat inside source static in the case of an active/backup link ?

Thanks

[Richard Burts]

I would think that an EEM script could be triggered by the track event and remove the current static nat command and replace it with the appropriate one.

[sebastien3]

Yes, that's the first point. Another thing is it not possible to make a route-map to manage two ip nat inside source ?

[Richard Burts]

You are correct that a route map can manage nat depending on the interface used when both nat statements are active in the config. But with static nat you want a single nat statement to be active and you want to change it when the ISP changes and route maps do not have that dynamic aspect.

[MHM Cisco World]

this easy, I will share lab with you today, 
but why you mention DMZ in your Q?

[sebastien3]

---

@MHM Cisco World wrote:

this easy, I will share lab with you today,

---

Thanks very much !

I speak of DMZ because the firewall does not have a public IP but a private IP... Only the firewall is connected to the router GE0.

[MHM Cisco World]

IOU2 config

!
track 1 ip sla 1 reachability
!
interface Ethernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
interface Ethernet1/2
ip address 100.0.0.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
!
interface Ethernet1/3
ip address 110.0.0.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
!
ip nat inside source static 10.0.0.1 100.0.0.1 route-map mhm1
ip nat inside source static 10.0.0.1 110.0.0.1 route-map mhm2
ip route 0.0.0.0 0.0.0.0 100.0.0.22 track 1
ip route 0.0.0.0 0.0.0.0 110.0.0.33 100
!
ip sla 1
icmp-echo 100.0.0.22 source-interface Ethernet1/2
ip sla schedule 1 life forever start-time now
!
route-map mhm1 permit 10
match interface Ethernet1/2
!
route-map mhm2 permit 10
match interface Ethernet1/3

[sebastien3]

Thank you, I will test this config. I'll get back to you.

[paul driver]

Hello
you have 3 options when you introduce the FW behind your wan rtr

Routed mode:
-hide your internal network with NAT
- Advertise your internal network and allow the wan rtr to nat for it

Transparent mode:
allow the wan rtr lan interface to ne “bridged” to be the next hop so the fw is running a layer2 but still able to provide fw services again the wan rtr will provide the nat 

[sebastien3]

Hi @MHM Cisco World 

The track ip sla does not work...If ip nat inside source static X .X is used, all flows are sent back to the firewall.

So it is not possible to do a ping test.

[MHM Cisco World]

this is solution for your case

[paul driver]

Hello
It sounds like you've just introduced this firewall so I assume then current role of the central router is not only managing the ISP failover but is also performing nat?

If so then what's the reasoning for now putting the NAT on the FW , as from what I can see the FWs single point of failure is its wan interface (central rtrs lan interface)  and it is shouldn't care what happens upstream as its wan interface is the only egress point it uses and its ip address will always be the same, So wouldn't it  be more applicable to keep the NAT on the central rtr ? 

[sebastien3]

Hi @MHM Cisco World @paul driver 

I explain the final configuration envisaged :

- The central router is connected to the main access (fiber = primary) and also connected to a secondary router (adsl = backup)
- The central router send all flows to a firewall (the local network is behind the firewall)
- The central router does double NAT with the firewall
- The NAT will be managed on the firewall in order to make the rules towards the LAN
- The central router must be accessible by SSH on its WAN IP and send the rest to the firewall

Using ip nat inside (below) static with route-map it is not possible to use ip nat inside source static tcp A.B.C.D 22 interface Z 22

With this it is no longer possible to manage the central router...

ip nat inside source static 10.0.0.1 100.0.0.1 route-map mhm1
ip nat inside source static 10.0.0.1 110.0.0.1 route-map mhm2Is this more understandable ?

[paul driver]

Hello
So why do you need to double nat , you can still set rules on the Fw based on  the original nat from the central router , NAT failover will then be done on the central rtr  along with the ISP failover, less complexity and more manageable. 

[sebastien3]

I don't understand your answer...

The central router forwards all flows to the firewall with ip nat inside source static 10.0.0.1 100.0.0.1 route-map mhm1 or route-map mhm2.

A rule must be added to manage the central router on the ssh port. With the two route-map rules mhm1 and mhm2 it no longer works !