Good Day,
I have a situation where I am using ASA in a non-standard way. I have run into behavior that I do not understand and hope that someone can explain to me. This is a sample topology of what I am dealing with:
The "dmz" interface is not a real DMZ, it resides on a bridge group along with the internet. Its default gateway resides on the other ASA interface in the same bridge group. What I want to do, is intercept traffic destined for the inside server and identity-NAT it over, and vice versa. I start out with blank config, and set up the ASA as per the diagram. The only things that are not mentioned are: same-security-traffic permit intra and inter as well as inspect icmp in global policy.
Everything pings to ASA, dmz server pings to its gateway.
Strange behavior:
when I ping from inside server to dmz server, the ping succeeds. In icmp debug on ASA I can see 192.168.1.100 (inside) sent to 172.16.10.100 (dmz), then reply going in opposite direction. I am using a switch in my lab in place of dmz server, and I can see icmp replies in the debug of that as well.
when I ping from dmz server to the inside server, the ping times out. In icmp debug on ASA I can see 172.16.10.100 (dmz) sent to 192.168.1.100 (inside), but the ping does not make it to the server and there is no reply in opposite direction. I can tell it does not make it to the server as I tried putting another switch in place of the inside server and saw no echo requests in debug.
You would think, perhaps Mike-J missed some ACL command or something, right? I did too... BUT! when I change the default gateway on the dmz server to point to the ASA, the ping makes it through. I then see both request and replies flowing through ASA in the debug... I also confirmed ACLs are not an issue through packet-tracer.
As far as I understand, the only change that would be made to the frame when I change default gateway would be the destination MAC address, right? L3 source and destination will be the same for routing purposes. So it seems like when the MAC is not ASA's own, it does not want to forward frame out of the interface that it gets NAT'ed to. I further confirmed this by performing identity NAT between dmz and internet interfaces with proxy-arp. The dmz server would grab ASA's MAC address and map it to default gateway's IP 172.16.10.1, and again, pings from dmz to inside server work. Of course nothing else does then.
So, can anyone explain this? Is there some sort of feature that I am not aware of that may be causing ASA not to forward out of interface after successfully performing NAT? I would accept that ASA is not able to intercept stuff not destined to itself on bridged interfaces, except that the icmp debug shows that it does! and that it translates it to the correct interface... Is icmp debug misleading me? And if there is some kind of inspection that does not accept this "wrong" MAC address upon translation, is there a way to circumvent it?
Any input is appreciated! My first time posting on this forum, so I apologize if I am doing something wrong, I am sure I will get corrected.
EDIT 01:
I see some views and no responses, I wonder if people are actually interested in this or this is a stupid question not worth an answer.
Just in case someone does find this helpful, I have gathered a bit more information which sheds light on process.
Through packet capture trace I found that pings from dmz interface first get matched through "L2-EGRESS-IFC-LOOKUP" and egress interface is then determined to be "outside" interface. It makes sense to me, since this is a bridge group, but I would expect my plan to fail at this point. Regardless of this match, the process continues on and packet is then matched to the NAT in place, and result egress interface is then "inside" and result is "allowed". Capturing dropped packets does not return anything, so it does not look like the pings get dropped! Question becomes where do they actually exit? "outside" or "inside" interface? I put capture on "inside" interface, and I see the pings going out! But wait, look at the details of the packets, and I see something peculiar - the destination MAC is still that of the gateway (that hangs off the "outside" interface). As an afterthought, I want to check the outside interface to see if exits both...
So now, what I want to find out is whether this is normal behavior and whether or not I can manipulate MAC address translations. If anyone has any input, it is greatly appreciated!
