ASA routing

[gregbeifuss]

I have dual firewalls on either end of my DMZ and would like for my DMZ hosts to serve up content to both internal and public users. My issue is that I'm not sure how to simplify the routing.

I have my DMZ host with a default gateway of the public firewall (192.168.2.1, per the diagram) which allows it to serve up pages externally. I am currently using static routes defined on the DMZ host (ie. route 192.168.1.0/24 has a gateway of 192.168.2.251) which works fine. I'd like to do away with static routes and have the public firewall reroute the traffic. Traffic from the DMZ host to the internal network should, in my mind, travel:
DMZ Host (192.168.2.10)
Default Gateway (192.168.2.1 / public firewall)

Inside firewall (192.168.2.251)

Inside host (192.168.1.x)

How do I go about setting this up?

Thanks,

Greg

[Federico Coto Fajardo]

Hi,

To be able to allow the ASA to reroute traffic backout the same interface in which it received it you need this:

same-security-traffic permit intra-interface

If routing is correct, then when the internet-facing firewall receives from the ''inside'' interface traffic intended to the internal LAN, then it will u-turn the traffic and reroute it back to the ''inside'' interface (same interface in which it received the traffic).

Is this what you're looking for?

Federico.

[gregbeifuss]

I should have mentioned that I already have the same-security-traffic permit intra-interface statement in my configuration.

When I use the packet tracer, the packet is dropped during a NAT phase by the rpf-check.

[Federico Coto Fajardo]

Perhaps when the traffic reaches the ASA, there's a NAT rule and the ASA is expecting a corresponding NAT rule to translate that IP.

I see two options to try:

NAT the traffic, i.e

nat (outside) 1 IP_of_DMZ_server 255.255.255.2555

global (outside) 1 interface

Or, disable NAT Control?

Federico.

[Federico Coto Fajardo]

Also, on previous releases there was a limitation with u-turning the traffic because it was only used on encrypted traffic.

For example, to terminate the VPN tunnel and then redirect it either trough another tunnel (encrypted) or in the clear to the Internet.

I have not tested myself if it works now on receiving clear text and sending it back as clear text.

Federico.

[gregbeifuss]

Thanks for your comment on the u-turning not working properly. No matter which NAT rule I write, the rpf-check drops me everytime. I'm using 8.2.2 and I'll just leave in the static route entries for now.