Yes the terms 'Ingress/egress' are counter intuitive for us networking folk from a network (traffic) perspective, but they do work well in describing FW policies and traffic flows 'from and to' a host/device relative to the CX 10000 FW .
The stateful FW function applies to both Egress & Ingress FW policies on the CX 10000.
Typically, 'Egress FW policies' are used for hosts and devices, that are attached to a CX 10000 at the Top of rack. Think as securing 'East-West' as in 'Horizontal' traffic profiles. This is the 'go to' policy framework to be applied when hosts/devices are connect to the CX 10000 switch.
'Ingress FW policies' are very useful to apply policy to secure traffic profiles originating from devices/host that are not connected to a CX 10000 switch. This could be traffic originating from a host from another Top of Rack switch which is not a CX 10000 , or with a North/South profile - traffic inbound to a DC or 'Pod'.
In addition , 'Ingress policies ' support many instances where it enhances the overall security policy framework in conjunction with an 'Egress' policy.
Ingress policies can be applied to traffic profiles from hosts switched/bridged locally on the same CX 10000 switch or traffic arriving from the network spine or core destined to a host on the CX 10000 switch.
The software constraint you highlighted in the statement in bold, I read as:-
applied to software versions prior to 10.10.1000, where an ingress policy could only be applied to traffic arriving from the network 'spine/core' destined to a host on the CX 10000 and not to traffic switched/bridged locally on the CX 10000.
From 10.10.1000 release onwards, an ingress policy can be applied to both traffic profiles, locally switched/bridged traffic traffic between hosts connected on the same CX 10000 and traffic profiles inbound to the CX 10000 from elsewhere in the network, destined to a locally connected CX 10000 host/device.
The statement is perhaps a little bit ambiguous, maybe it needs to be read in context, can you provide a link to where you found it so that I can review in it's entirety?
thank you,
------------------------------
Steve Bartlett
------------------------------
Original Message:
Sent: Nov 22, 2023 04:12 PM
From: mvanoverbeek
Subject: Aruba CX10000 capabilities
Thank you for explaining the difference and providing the link, this clarified a lot! Intuitively I thought of ingress and egress exactly opposite prior to your explanation. So if I understand correctly, the ingress policy is meant more to filter traffic directed to a host, for example a webserver, only allowing port 443 or 80 for example.
The egress policy is the policy that is more suited the stateful firewall, although probably both ingress and egress policies are stateful.
Part of the explanation on the website confuses me though (see bold), is ingress only applicable to hosts on the same switch? TY again for trying to explain this
PSM INGRESS POLICY
Ingress policy applies to traffic destined to a host in a VLAN with an associated PSM Network, with the exception of traffic between two hosts in the same VLAN attached to the same CX 10000. Ingress policy is generally applied to filter inbound traffic destined to an application server.
Ingress policy applies to traffic routed between hosts attached to the same CX 10000, when running AOS-CX 10.10.1000 and above. Previous versions of AOS-CX are constrained to applying egress policy between hosts attached to the same switch for both routed and bridged traffic.
Original Message:
Sent: Nov 21, 2023 08:22 AM
From: Steve.Bartlett
Subject: Aruba CX10000 capabilities
The terminology and some concepts are different. The CX 10000 has two types of policy.
- Traffic leaving the a workload/host and entering the switch is subject to an 'Egress Policy'.
- Traffic coming into the host will be subject to an 'Ingress Policy'.
Policy rules are applied using the standard convention of leveraging source-dest protocol port combinations, the 5 tuple values. To take a simple example:-
- Policy is applied between src-dest IPs as an 'Egress' policy
- Source 'IP A' will be the initiator flow (I)
- Destination 'IP B' will be the 'responder' flow (R)
- Both 'I' & 'R ' flows will be allowed if a permit rule is applied between 'IP A >>>> IP B'
So like a reflexive access list, which dynamically allows the return traffic for an established connection, the policy allows the return path for the 'R' flow without the requirement of an additional 'return path' rule. There the similarity ends with reflexive access lists as the CX 10000 is a 'Stateful Firewall' and is far more secure than a reflexive access list.
High level Data center with policy design with CX 10000 can be found here in one of the DC VRDs:-
https://www.arubanetworks.com/techdocs/VSG/docs/040-dc-design/esp-dc-design-024-policy-design/
------------------------------
Steve Bartlett
Original Message:
Sent: Nov 20, 2023 12:32 PM
From: mvanoverbeek
Subject: Aruba CX10000 capabilities
Thank you,
Does this mean that traffic is filtered both at the ingress direction (source) as well as at the egress direction (destination) and that it acts as a reflexive access-list?
Original Message:
Sent: Nov 20, 2023 06:37 AM
From: vincent.giles
Subject: Aruba CX10000 capabilities
This is L4 FW not L7 FW/IDS/IPS.
Original Message:
Sent: Nov 17, 2023 04:20 PM
From: mvanoverbeek
Subject: Aruba CX10000 capabilities
With curiosity I am reading about the Aruba CX10000 switch and its L4-7 capabilities through the AMD Pensando DPU. I can see the benefits from being able to offload some of the functions traditionally done by Firewalls of platforms such as NSX. But what UTM functions such as Antivirus, or IPS? Is that something that is possible with the CX10000? Or is the current capability more focused on L4-7 filtering not necessarily other UTM functions?
It would also be nice if someone can point me to a more detailed design/validated datacenter design VXLAN EVPN with ToR segmentation.
Thanks,