topic Packet treatment by asa in Network Security

Packet treatment by asa

olympicair — Tue, 12 Mar 2019 01:45:12 GMT

I have the following question.

I have a 5525-X and in one DMZ a couple of ISA servers with load balancing in unicast mode (that means that both ISA server have the same MAC).

When another machine (in the same DMZ) tries to send a packet destined to ISA, the packet is flooded on local switch .

ASA receives the packet and sends a RST back.

Is this the normal behavior? How ASA handles packets that

How asa is treating packets that arriving in its interface and the packet is not destined or must go through the asa?

Thanks

Apostolos

Packet treatment by asa

Julio Carvajal — Tue, 21 May 2013 23:40:30 GMT

Hello Apostolos,

By default the ASA will deny traffic that comes from Interface "X" and needs to go out that same interface "X" some sort of split-horizon rule that you might override using the same-security-traffic permit intra-interface command,

Remember to rate all of the helpful posts

Julio Carvajal

Packet treatment by asa

Patrick Moubarak — Wed, 22 May 2013 03:07:39 GMT

Julio, I don't think the ASA sends a RST if the same-security-traffic is not enabled, I think it just silently drops the packet.

Since both the machine and ISA are on the same subnet, the ASA should not interfere with the traffic (assuming the ASA is in routed mode not transparent)...

are you matching an ASA inspection policy that has reset as action?

are you running IPS in promiscuous and using TCP resets? you might be matching one of the IPS signatures...

Patrick

Packet treatment by asa

Julio Carvajal — Wed, 22 May 2013 16:56:21 GMT

Hello Patrick,

I agree with you, Traffic on the same LAN should never reach the default-gateway as this is only LAN traffic...

And also agree on the fact that not having the same-security-traffic command will not generate a reset... In fact we will see on the ASP captures on the ASA an ACL drop for that.

The client or server machines will never know about that....

Now what it confuses me is the following statement:

the packet is flooded on local switch .ASA receives the packet and sends a RST back.

What do you mean Apostolos by packet is flooded on local switch?

The only way that this could happen would be if the packet is a broadcast/multicast (without CGMP,IGMP Snooping) or an unknown unicast packet) so I would ask for more information on this

Regards

Packet treatment by asa

olympicair — Thu, 23 May 2013 07:13:13 GMT

Hello jcarvaja and Patrick

Thanks for your answers.

The ISA servers are using the same mac address.

From ASA

ciscoasa/act# sh arp | i airisa

PARTNERS airisa1 02bf.0a3c.046e 67

PARTNERS airisa2 02bf.0a3c.046e 515

From 6509

Koropi_6509#sh mac address-table dynamic address 02bf.0a3c.046e

Legend: * - primary entry

age - seconds since last seen

n/a - not available

vlan mac address type learn age ports

------+----------------+--------+-----+----------+--------------------------

No entries present.

Since there is no entry for this mac i suppose the switch "floods" the packet and then ASA receives the packets and send back a RST to the originating server.

As you already mentioned the same-security-traffic command is not configured on ASA.

Regarding the inspection policy that Patrick mentioned. There is inspection policy (IPS on promiscuous mode) but is not applied to this interface.

What i don't understand is why ASA is replying to a packet that is not destined for ASA (different destination MAC/IP).

Is this normal ??

Regards

Apostolos

Packet treatment by asa

Julio Carvajal — Thu, 23 May 2013 16:26:59 GMT

Since there is no entry for this mac i suppose the switch "floods" the packet and then ASA receives the packets and send back a RST to the originating server.

Agree with you, this will be an unknown unicast packet so it will be flood it across the switch ports on the same vlan.

What i don't understand is why ASA is replying to a packet that is not destined for ASA (different destination MAC/IP).

Is this normal ??

We will need to check the NAT statements you have there because I am almost sure that there got to be a NAT statements that will create a proxy-arp rule for this traffic, that for me would be the only explanation (at least with the information provided so far)

My real question would be, why is the switch not learning the MAC address of those ISA servers?

Regards,

Julio

Re: Packet treatment by asa

malshbou — Thu, 23 May 2013 18:15:42 GMT

I believe that the packet for which the ASA sent RST has a destination MAC of the ASA, otherwise it would get dropped at

layer 2.

would you please post the ASA config and get captures that show the flooded packet and the RST packets at the ASA ?

capture cap interface

show capture cap detail

i guess the switch behvaiour of not learning the the MAC is normal as it cannot learn the same MAC on two ports, probably the MAC entry keeps flapping, hence not appearing in CAM table.

------------------
Mashal Alshboul

Re: Packet treatment by asa

Julio Carvajal — Thu, 23 May 2013 19:12:59 GMT

Hello Mashal,

i guess the switch behvaiour of not learning the the MAC is normal as it cannot learn the same MAC on two ports, probably the MAC entry keeps flapping, hence not appearing in CAM table.

On these particular scenarios we relay on Network Load Balancing.... This allows the ISA servers to masquerade the cluster MAC address on a way that each member of the ISA cluster will have a dedicated MAC address..

For further information check:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

Regards

Julio

Re: Packet treatment by asa

malshbou — Fri, 24 May 2013 06:08:33 GMT

Hi Julio,

will this LB setup normally lead to two MAC addresses forwarded from different switch ports ?

The ASA seems seeing the same MAC addresses via the switch:

ciscoasa/act# sh arp | i airisa

PARTNERS airisa1 02bf.0a3c.046e 67

PARTNERS airisa2 02bf.0a3c.046e 515

------------------
Mashal Alshboul

Re: Packet treatment by asa

Julio Carvajal — Fri, 24 May 2013 17:40:46 GMT

Hello Mashal,

Exactly, Pointing to an issue in the deployment