Help with ASA 5510 Nat/Routing DMZ with dual ISPs (4 legged)

[longboringusername]

Hello,   I am in the process of configuring a ASA 5510 to replace an older PIX.  This change is part of migrating to a new ISP, so the process is complicated by the existence of two outside interfaces.  I have virtually everything working, but there is a requirement to be able to access hosts from the internal networks using both their private IPs and their public IPs.  The older PIX took care of this silently with little configuration, but the ASA has me twisted on the details.  Some of the hosts with public IPs are on the internal network and some are on a DMZ (not my design, inherited).  For the internal ones I implemented hairpinning to take care of the requirement, but I am having trouble with the DMZ based hosts.. Since there are two external interfaces each internal host has two IPs and two static NAT rules to handle incoming traffic from each external interface.

The routins and dynamic NAT entries we have in place take care of accessing the hosts using their private IPs on the DMZ, but I cannot figure out how to get the public IPs to work from the internal network.  It seems like a simple Static D-Nat shoudl do it, but when I add a Static D-Nat on the DMZ the public IP works, but the private IP breaks..  Is there a way to get them both to operate ?

Network layout looks like this (IP ranges altered):

DMZ  172.10.0.0.0 Class C

INTERNAL 10.0.0.0  Class C

Outside  1.2.3.0  Class C

Outside2  2.3.4.0  Class C

Host IP addresses are paired, (ex: IP 172.10.0.2 is sam host as 172.10.0.102  first address is primary second not registered in DNS)

Currently the pertinent NAT rules look like this (there are many more, but only these relate to the networks as whole and hosts on DMZ):

global (outside) 1 interface

global (inside) 5 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 5 access-list inside_nat_outbound

nat (inside) 1 10.0.0.0 255.255.255.0

nat (DMZ) 0 access-list dmz_nat0_outbound

nat (DMZ) 1 0.0.0.0 0.0.0.0

static (DMZ,outside) 1.2.3.50 172.10.0.2 netmask 255.255.255.255

static (DMZ,outside2) 2.3.4.50 172.10.0.102 netmask 255.255.255.255

static (DMZ,outside) 1.2.3.51 172.10.0.3 netmask 255.255.255.255

static (DMZ,outside2) 2.3.4.51 172.10.0.103 netmask 255.255.255.255

static (inside,DMZ) 10.0.0.0  access-list inside_nat_static

static (DMZ,outside) 1.2.3.173 172.10.0.10 netmask 255.255.255.255

static (DMZ,outside2) 2.3.4.173 172.17.0.110 netmask 255.255.255.255

route outside 0.0.0.0 0.0.0.0 1.2.3.161 1

route inside 0.0.0.0 0.0.0.0 10.0.0.1 2

route outside2 0.0.0.0 0.0.0.0 2.3.4.97 3

Currently when I access the hosts from the internal network using their internal IPs  (ex: 172.10.0.2 ) everything works as it should.

When I try to access them using their public IPs (ex: 1.2.3.50 )  there is no connectivity.

I added a D-Nat to try to fix it as follows

static (DMZ, inside) 172.10.0.2 1.2.3.50 netmask 255.255.255.255

After applying it I could access the public IP (1.2.3.50) from the internal network, but I could no longer access the DMZ IP (172.10.0.2) from the internal network. Is there any way to get this configuration to allow access to both IPs from the internal network ?

The problem here is that there are website links based on the public IP and the DNS is split so DNS returns the internal IP to users. As a result both need to be accessible from the internal network.. Not my favorite design, but the client (or in this case the boss) is always right so I need to get it working somehow.

Any ideas ?

Dave Bean

[rizwanr74]

Hi David,

Please try this.

static (DMZ, inside) 172.10.0.2 172.10.0.2 netmask 255.255.255.255

static (DMZ, inside) 1.2.3.50 1.2.3.50 netmask 255.255.255.255

Let me know, this helps.

thanks

Rizwan Rafeek

[longboringusername]

Hi Rizwan,

Thanks for the suggestion. I went to try it over the weekend, but it seems to have no effect.  The direct access to 172.10.0.2 continues to work, but the access to the public IP at 1.2.3.50 does not work with these NAT rules added.

I tried the original D-Nat entry again.

static (DMZ, inside) 172.10.0.2 1.2.3.50 netmask 255.255.255.255

It had the same effect. internal access to the public works, but I looked at the packet trace.

The packet trace shows it being blocked by RPF in the last NAT lookup.

The odd thing is that I have Anti-Spoof disabled so I was surprised to see RPF as the cause..

Are you sure the entries should both be identical source/dest ?

Dave

[longboringusername]

Here is som additional detail..

Whenever the D-Nat is in place the public IP works, but the private does not.  The last step of packet trace looks like this:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
static (DMZ,inside) 1.2.3.50 172.10.0.2 netmask 255.255.255.255
  match ip DMZ host 172.10.0.2 inside any
    static translation to 1.2.3.50
    translate_hits = 15, untranslate_hits = 3
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Does RPF failure on this NAT indicate a missing ACL definition or NAT for the original private IP ?

Confused about why adding a static NAT is breaking the working routing of private IP..

ASA is version 8.2(1)  [provided by ISP]

[rizwanr74]

Hi David,

Please attach a diagram, with server-hosts in question, physical switches in between, ports in port-fast-mode or in trunk-mode, where firewall is located and public/private traffic directions.

This will give good info to nail the issue.

Look forward to hear from you.

[longboringusername]

Hi Rizwan,

I think I see where you are going with this, but the network is 'flat' or transparent. That is to say all of the switches are used out of the box and have no VLANs or routing configured at all. The direction of traffic is actually identical in both cases, the traffic is from the inside interface to the DMZ interface and travels between the same two hosts. The only difference is the addressing...  Since no switches are routing or filtering I am pretty sure the problem is the ASA configuration.

Essentially we are trying to do this: 

Host1 (10.0.0.50)  retreives HTTP from HOST2 (172.10.0.2) on DMZ  (SAME HOST2 VIA PRIVATE IP)

Host1 (10.0.0.50) retreives HTTP from HOST2 (1.2.3.50) on DMZ  (SAME HOST2 VIA PUBLIC IP)

traffic is between same two physical hosts on same network paths via two different IPs and the only intervening component doing any routing that we can control is the ASA5510. Although the ISP has components we have no access to configure them so the traffic redirection and handling needs to occur in the ASA5510.  Although there are two ISPs one is due to be phased out at the end of the month so it can be ignored.

I am attaching a diagram, but I doubt it changes anything..

       If it would help I can send the full config without anonimization.. Preferably via email rather than posting it here.

Much of the ruleset is inherited from an outgoing PIX and we have not finished a security review to clean out old cruft, but if you need to see it I can send it along...

[rizwanr74]

Hi David,

here is my email address:  mrm.rizwan@gmail.com

thanks

[rizwanr74 · Accepted solution]

Hi David,

access-list inside_access_in_V1 extended permit ip 191.168.0.0 255.255.0.0 172.10.0.2 255.255.255.0

Please add above permit-line before your (last-line: extended permit icmp any any) and you know there is an implicit deny kicks in meaning you deny everything else other than permitted traffic, in the AC:inside_access_in_V1

Please add below line in the ACL:inside_nat_static

access-list inside_nat_static extended permit ip 191.168.0.0 255.255.0.0 host 1.2.3.50

static (inside,DMZ) 191.168.0.0 access-list inside_nat_static

static (inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

Let me know

Thanks

---------------------------------------------------

What is this: route inside 0.0.0.0 0.0.0.0 191.168.0.1 2

--------------------------

interface Ethernet0/2

description LADO_DMZ

nameif DMZ

security-level 50

ip address 172.17.1.1 255.255.255.0

--------------------------

your ASA is hosting a DMZ zone (Ethernet0/2) and it is not in the same subnet as your hosting-server(172.10.0.2), I am puzzled.

[longboringusername]

Hi Rizwan,

Sorry for the long lag in responding.  As luck would have it my computer crashed in the middle of this whole process forcing me to rebuild it while I worked this out.  I finally got it all working, but as soon as I did I discovered that some of our execs use a VPN that drops them into the DMZ forcing me to replicate the whole mess on the DMZ as well.

Some of your questions are just based on mixing up the anonimized IPs with the actual config, I used similar IPs which made it easy to do (sorry about that). The anonimized was 172.10.x.x while the real one was 172.17.1.x..

Overall what I needed to do was this:  I needed to be able to access hosts on DMZ and on internal network via both private IPs and public IPs. Thanks to the VPN equipoment I needed to work from both the internal->DMZ and also from DMZ->internal without affecting entry from oustide (external) using the public IPs.

I was being tripped up in part by the old VPN setup in teh ASA which had overlapping addresses with the DMZ and a NAT exemption. That exemption was the source of many of the rpf failures I kept running into setting up the statics. I found that when I used simple D-Nat statics for the public addresses, inter-interface access using the private addresses ceased to function. Since I needed both to work I was forced to use static policy d-nat entries that specified the destination as the public IP, this prevented them from altering the IPs on the traffic directly to/from the private IPs.  The next problem I ran into was that the source IPs from both DMZ and internal were being altered by a catch all dynamic that assumed all traffic was outbound and used interface PAT. To avoid that I had to add a dynamic policy NAT entry that also specified the public IPs as a destination and provided a compatible routable source address. Since this had to work for hosts on both DMZ and on the internal network from either the same net/interface or from the other net/interface I also had to set up hairpins to handle the ones that were purely intra interface.

Rather a complicated config considering that the old PIX took care of all of this transparently and silently. It is nice to have more control, but I'm not convinced it is an improvement when it takes so much more work to get it all going.. The older PIX versions seemed to be smarter about routing, they would have just used a handful of aliases at most and those would not have mucked up direct access from the private IPs. 

I also made some additions to the ACL list based on your suggestions and the errors that surfaced once I configured the NAT.

I am in the final stages of testing now, but so far so good. Thanks for you help and pointers..  I will mark this question as answered.

It did not end up exactly as you suggested, but your directions put me on the path to getting it all going in the end. With your help and good old elbow grease it is working. It took a few hours of trial and error (but fortunately your help made it more trial and less error).