ASA NAT with 2 interfaces with public IP ranges

[Peter Ellwood]

Hi All,

I am having some difficulty with what I believe is a NAT issue.

We have a Cisco ASA 5520 that we have a large amount of sub-interfaces on.

Some of these sub-interfaces have public IP address ranges, whilst others have private IP address ranges.

Our outside interface, for example, is one with a public IP address range.

I am experiencing an issue when trying to access a webserver server from one of the sub-interfaces with a public IP address range associated to it.

I am leaning towards it being a NAT issue because I can see the traffic leaving the Public interface A and I can see it reaching the outside interface but it does not reach the back end server.

Originally I thought it may be hairpinning but I don't believe it is as these are 2 different interfaces with different security levels.  Public interface A has security level 50 and the outside interface has security level 0.

The outside interface of the Cisco ASA is in a /28 however the public IP address on the outside interface is part of a routed /24.  The IP address we are trying from is in a seperate /28 that is also routed to the Cisco ASA but is associated to a sub-interface.

The NAT on the outside interface of the web server uses Proxy Arp and does not use DNS translation.

Has anyone done anything similar successfully (I imagine so?).  

I am not seeing any denies or portmap translation errors in the logs, nor am I seeing any packets reaching the backend host when using Wireshark.

One the firewall I can see the SYN's reaching the outside interface but not progressing any further.

I have tested several different NAT scenario's all to no avail and am hoping someone can point me in the right direction.

[Vibhor Amrodia]

Hi,

Please explain a bit more about the setup.

Clients ---- Public IP Interface [ASA]---Outside interface-----Interface

Where is the WebServer located ? If on the Outside , can you give me the packet tracer output:-

packet input <Public IP Interface> tcp <IP of the client> 3456 <Webserver IP> 80 det

If not , which interface is it located behind and what NAT statements are there on the ASA device for it ?

Thanks and Regards,

Vibhor Amrodia

[Peter Ellwood]

Hi Vibhor,

What we have is follows: -

Clients -> virtual firewall with public IP on sub-interface (security level 50) of Cisco ASA -> Outside interface of Cisco ASA (security level 0) -> private sub-interface (security level 100) -> Webserver with private IP

The 2 sub-interfaces are on the same physical interface.

The NAT statement is an object NAT statement as below: -

object network WEBSERVER_DMZ.HTTPS
 nat (WEBSERVER_DMZ,outside) static <public IP> service tcp https https 

Packet Tracer output: -

FW01# packet-tracer input outside tcp <client public IP> 3456 <server private IP> 443 detailed

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x73fdbd08, priority=1, domain=permit, deny=false
        hits=6961066005, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0100.0000.0000
        input_ifc=outside, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   1.2.3.0      255.255.255.128 WEBSERVER_DMZ

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   a.b.c.d   255.255.255.224 ClientExternalNetwork

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: WEBSERVER_DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed

hmmm... is that packet trace correct?  Is the RPF the cause of my issue?

[Vibhor Amrodia]

Hi,

You need to correct the Packet trace.

The packet tracer has to be for the destination as server public IP and not the private IP.

Also , why are you routing the traffic from the Source Sub interface of the client to the Outside interface first and then routing it back to the Webserver DMz interface ?

Why can't it be routed from the Source Sub Interface for the client to the WebServer DMZ on the ASA device ?

Thanks and Regards,

Vibhor Amrodia

[Peter Ellwood]

Hi Vibhor,

Packet trace below, corrected as advised.

With regards to the your question on the routing, the Web Server and the client are different customers - they should not "see" each other's private IP ranges and should only see the public IP addresses.

FW01# packet-tracer input outside tcp  <client public IP> 3456 <web server public IP> 443 detailed

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x73fdbd08, priority=1, domain=permit, deny=false
        hits=6971222339, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0100.0000.0000
        input_ifc=outside, output_ifc=any

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:

object network WEBSERVER_DMZ.HTTPS
 nat (WEBSERVER_DMZ,outside) static EXT-WEBSERVER service tcp https https
Additional Information:
NAT divert to egress interface WEBSERVER_DMZ
Untranslate <public IP>/443 to <private IP>/443

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   a.b.c.d  255.255.255.224 ClientExternalNetwork

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: WEBSERVER_DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (rpf-violated) Reverse-path verify failed

[Vibhor Amrodia]

Hi,

If i understand it correct , you are using ASA in mutiple context on the ASA device ? Is that correct ?

Thanks and Regards,

Vibhor Amrodia

[Peter Ellwood]

Hello Vibhor,

Thanks for trying to assist.

No we are not running the ASA in multi-context mode, it is running in single-context mode.

[Vibhor Amrodia]

Hi,

Can you share the complete packet tracer output and the configuration.

Thanks and Regards,

Vibhor Amrodia

[Peter Ellwood]

Hi Vibhor,

That's difficult due to the confidential nature of the information but I'll do the best I can.

Having said that, it is definitely RPF on the outside interface - if I disable RPF on the outside interface it works like a charm.

For some reason the traffic flow is acting like this: -

client -- virtual firewall with public IP on sub-interface (security level 50) of Cisco ASA -- routed externally -- back to outside Interface of Cisco ASA -- Cisco ASA drops the packet due to RPF (as it originated from a sub-interface of the ASA).

Argh!  It shouldn't have to NAT as I can't imagine it having to translate anything - it's going from a public IP on one interface to a public IP on another interface, that should be routing, not NAT'ing... though thinking about it, it's sending it externally because the IP on the outside interface isn't directly on the outside interface, it's in a different subnet (class /24) that's routed down to the outside interface and proxy-ARP'd so there's no route on the firewall for that subnet....