04-07-2014 10:54 AM - edited 03-11-2019 09:02 PM
I understand the fix to this problem with the "same-security-traffic permit intra-interface" command but I'm curious if anyone knows the reason behind by RPC on tcp/135 would need to consult the ASA for a host on the same subnet? The ASA is the gateway for hosts on this subnet but a host should not have to consult the ASA unless it is attempting to communicate with another node on a different subnet. I also understand that the ASA would receive the flooding of a broadcast when the host doesn't know the MAC of a host on the same subnet. But in this case, the ASA is denying traffic from host 172.18.3.212:49450 on interface inside4 to host 172.18.3.211:135 on interface inside4. Proxy arp is also disabled on the ASA. Thoughts on why this would occur?
04-07-2014 04:16 PM
It sounds like some oddness at the host level. Have you done an analysis (arp cache review, etc.) or packet capture on either of the endpoints to see why they might be sending packets to one another via the ASA?
Even if the ASA were - against all expectation - in the path it should allow the traffic given the "same-security-traffic permit intra-interface" command. The only simple reason (assuming there are no access-lists at play) I can think it would block it is due to an inspection service-policy.
04-07-2014 07:54 PM
Yeah I could turn the same-security-traffic permit intra-interface command on and I'm sure it would work. I'm just curious why I would run into this problem in the first place. In this case the two servers are MS SQL servers and they are testing failover. I could run some captures on the servers to see what they are doing specifically I was just curious if anyone else has run into this issue...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide