04-12-2019 08:00 AM
Hi
I'm working on a TrustSec dev environment using ISE for SGT assignemnt and Policy enforcement.
I started looking at a policy that would restrict authenticated clients on a vlan to only ping their default gateway (vlan svi)
ISE is configured with a policy permitting icmp only from SGT 3100 to SGT 2 - the switches download the cts environment data successfully and can be viewed from the switch cli
IPv4 Role-based permissions from group 3100:TEST to group 2:TrustSec_Devices:
SGACL_ICMP-01
Deny IP-00
These permissions aren't being enforced - I can still SSH to the SVI. If I set permissions to just Deny IP-00 I can still ping/ssh to the SVI.
From cisco documentation:
"SGACL enforcement can be applied to packets switched within a VLAN or forwarded to an SVI associated with a VLAN, but enforcement must be enabled explicitly for each VLAN"
I have the command "cts role-based enforcement vlan-list <vlan>" on both access/distribution switch but policy is still not enforced. All other ISE policies work as configured but not this one - I've checked that SGT propagation (manual inline) between access/distribution is working ok.
Does anyone have any idea why I can't enforce policy for SVI bound traffic? I don't think I had this issue in the past (with same/similar config) when the distribution switch was a VSS 6880.
Thanks
Andy
Solved! Go to Solution.
04-12-2019 05:04 PM
04-12-2019 09:19 AM
04-12-2019 10:30 AM
Hi Damien - thanks for the reply:
Do you see the ip sgt mappings for both svi and pc in "sh cts role-based sgt-map all" on a single switch? No - I see ip-sgt binding for the pc only on the access layer switch and the ip-sgt binding for the vlan svi only on the distribution layer switch
Within ISE, is the trustsec egress policy in "monitor mode"? No
Is anything showing denied in "sh cts role-based counters"? No - I'm seeing zero hits for SGT tag 3100 (PC) to SGT 2 (SVI)
I'll double check the configs and try different ios to see if that makes a difference.
Thanks
Andy
04-12-2019 05:04 PM
04-13-2019 03:34 AM
Thanks for that - I wasn't aware of that 3k hardware limitation.
I was testing the trustsec policy with Distribution switch SVI and loopback ip addresses (all with the SGT tag of 2). I can confirm that I'm running into this hardware limitation by testing the policy with a Distribution switch IP Address on a physical interface (which also has an SGT tag of 2).
I'll check that next week and update the thread.
Cheers
Andy
04-15-2019 04:08 AM
After a bit more testing I found that I couldn't enforce Trustsec policy for traffic destined to any Distribution switch owned IP Address (virtual or physical) when the source endpoint is in a Distribution switch VLAN.
This was the case whether the endpoint was connected to the Access switch or the Distribution switch (distribution switch had both SRC and DST SGTs in its table).
I resolved this by creating an SXP connection between Access (listener) and Distribution (speaker) so that the Access switch learned all distribution switch owned IP addresses (SGT of 2) - see below. With this in place, the Trustsec policy worked as expected with policy enforced on egress from the access switch.
Not sure if this is related to the 3k hardware limitation or a bug but I'll mark thread as resolved. It'll be interesting to see if I have the same problem when the Distribution switch is a Catlayst 6880
Cheers
Andy
DISTRIBUTION SWITCH
cts sxp filter-enable
!
cts sxp filter-list SGT2
permit sgt 2
!
cts sxp filter-group speaker SGT2
peer ipv4 <ACCESS-SWITCH-MGMT-IP>
!
cts sxp connection peer <ACCESS-SWITCH-MGMT-IP> source <DISTRIBUTION-SWITCH-MGMT-IP> password default mode local speaker
ACCESS
cts sxp connection peer <DISTRIBUTION-SWITCH-MGMT-IP> password default mode peer speaker
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