topic Re: Trustsec enforcement to hosts in ESXi not working in Network Access Control

Trustsec enforcement to hosts in ESXi not working

viveknath.mangalat1 — Sat, 31 Jul 2021 06:16:39 GMT

Hello all,

SGACL is not getting enforced for hosts that are located in the esxi network.

Like for testing, we are trying to block icmp from a BYOD tagged user to the DOMAIN Controller (which is tagged static)

Enforcement wont work, please suggest, I am attaching some screenshots.

Re: Trustsec enforcement to hosts in ESXi not working

viveknath.mangalat1 — Sat, 31 Jul 2021 06:37:42 GMT

hello all, was able to fix the issue, since the interface to esxi was a trunk port, we need to enable dot1x on trunk ports as well

is there any other solution, please let me know,

SW-02#show run int Gi4/0/45
Building configuration...

Current configuration : 339 bytes
!
interface GigabitEthernet4/0/45
description from esxi-1
switchport trunk encapsulation dot1q
switchport mode trunk
authentication host-mode multi-auth
authentication open
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication periodic
mab
dot1x pae authenticator
end

Re: Trustsec enforcement to hosts in ESXi not working

Damien Miller — Sat, 31 Jul 2021 06:42:20 GMT

TrustSec enforcement happens on egress only when the network device knows both the source and destination IP-SGT binding. What you have set up and included screenshots is fine, but what you're not showing us is if the switch knows that the DC 192.168.10.2 = SGT 11.

Because the DC is a static binding configured on ISE, in order for this enforcement to take place, the switch you are expecting to enforce this would have to receive this DC IP-SGT binding via SXP from ISE.

Typically we do not configure SXP to every device due to scaling issues. The enforcement point is usually a capable (and scalable) device that endpoint traffic passes through prior to the DC. Either a WAN router at the DC edge, or a DC aggregation point.

The command "show cts role-based sgt-map all" will very quickly tell you if the NAD knows both the source and destination SGT. But unless you configured an SXP connection to advertise it, the DC won't be there.

Re: Trustsec enforcement to hosts in ESXi not working

viveknath.mangalat1 — Sat, 31 Jul 2021 06:46:08 GMT

@Damien Miller was able to fix the issue, since the interface to esxi was a trunk port, we need to enable dot1x on trunk ports

is this the correct approach?

SW-02(config-if)#do show cts role-based sgt-map all
Active IPv4-SGT Bindings Information

IP Address SGT Source
============================================
192.168.1.36 3 INTERNAL
192.168.10.2 11 CLI
192.168.10.26 3 INTERNAL
192.168.10.132 2 LOCAL
192.168.20.9 3 INTERNAL
192.168.20.130 15 SXP
192.168.20.131 15 LOCAL

IP-SGT Active Bindings Summary
============================================
Total number of CLI bindings = 1
Total number of SXP bindings = 1
Total number of LOCAL bindings = 2
Total number of INTERNAL bindings = 3
Total number of active bindings = 7

Re: Trustsec enforcement to hosts in ESXi not working

viveknath.mangalat1 — Sat, 31 Jul 2021 06:48:47 GMT

@Damien Miller also, had the same issue from the clients connecting wireless, so just had to add dot1x to the port connecting to AP, that solved the problem too

interface GigabitEthernet4/0/2
description from-ap
switchport access vlan 10
switchport mode access
authentication host-mode multi-auth
authentication open
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication periodic
mab
dot1x pae authenticator
spanning-tree portfast edge
end

Re: Trustsec enforcement to hosts in ESXi not working

Damien Miller — Sat, 31 Jul 2021 07:04:17 GMT

That is one solution, the other is to build an SXP speaker connection from ISE to the network device, and a SXP listen on the network device.
The third option is to define an ip-sgt binding for the DC directly on the network device CLI.

Re: Trustsec enforcement to hosts in ESXi not working

viveknath.mangalat1 — Sat, 31 Jul 2021 07:29:57 GMT

ok thanks @Damien Miller for your time