Cisco ISE Posture URL Redirect Switch Config without client nw SVI

[star btsistem]

Hi,

We have ISE 3.1 with posture config. We are using posture on both WLC and switch side. On WLC we have client SVIs defined and url redirection on client side is working. However we did not have defined client network SVIs on switches because we have nearly 500 switches. Switches have management SVIs. Without client network SVIs on switches, url redirection is not working on clients so that posturing on wired connections is not working. While surfing community about this issue, someone has mentioned that switch management SVI has to reach client network. But when we examine the traffic i did not see traffic from switch management SVI to client network. If yes, which ports should be allowed between switch management network and client network ? How can I achieve url redirection issue on wired connections ?

Thanks,

[Flavio Miranda]

Hi @star btsistem 

 This information does not make sense. First, in order to do the Posture you need the client to have Anyconnect, so the posture is done on the client and not on the switch.  You are saying that you switches are layer 2 switches and have only the management  IP address but it does not matter. The important is that the client is getting IP address from the DHCP server somehow. This way, the client will be able to receive the URL from ISE and do the redirect because the client have IP address and therefore connnectivity to the ISE.

[star btsistem]

Hi Flavio,

Of course we are using anyconnect, i did not mention what we do as a long history for posturing And of course i know posture is not on the switch My problem is; url redirection is not working if switch management has not any SVI on client network. When we define a SVI on switch config it works.

Thanks,

[Flavio Miranda]

If that is the case, so is not possible to deploy posture in devices connected to a layer2 switch? only layer3 switch?

[star btsistem]

Of course not, but defining a client network SVI on the switch as a solution is not acceptable considering security and deployment issues. I have a case and to find a solution I have posted here

[Flavio Miranda]

I got it @star btsistem . But it does not make sense, that´s I am trying to say.  I am in agreement with you not the other way around.

 The thing is, I saw posture deployed in devices connected in Layer2 switches before and it does not require the switch to have an IP address on the clients network, after all, it was not even possible as it was not a layer3 switch.

 So, when you say " But when we examine the traffic i did not see traffic from switch management SVI to client network. If yes, which ports should be allowed between switch management network and client network ? How can I achieve url redirection issue on wired connections ?"

 It does not make any sense. The layer2 switch, it seems to be your case, you can not see traffic between management interface and clients network because the switch will not share traffic between VLANs.

  The flow here must be.

The client is connected to a layer2 switch with anyconnect.

The ISE send the URL to client via radius authentication process.

The clients  will resolve the URL using the DNS you provide him in the DHCP.

  The clients gets the ISE IP from the DNS

The cilent try to reach the ISE IP address. Here the client must look to its default gateway which must be your layer3 switch (core). The Core must know how to route the packet to the ISE.

Now, if you must add IP address on the Access switch on the client´s network in order to the redirect works, something is wrong with the network.

[star btsistem]

Hi Flavio,

I think we are not at the same point All our gateways are defined on the firewall. All routes are ok. You mentioned "The ISE send the URL to client via radius authentication process." I think the URL is sent from ISE to the switch. The switch intercept the http session here as described posture flow url I have shared below. Yes i know it is not needed to have l3 sw. Then how it works with a client nw SVI ? What is happening when we create a client nw SVI ? If we have a problem with the network, what is it ?

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/210523-ISE-posture-style-comparison-for-pre-and.html

https://community.cisco.com/t5/network-access-control/url-redirect-does-not-working-with-cisco-switches-catalyst-4500e/td-p/2943401

[Flavio Miranda]

"I think we are not at the same point All our gateways are defined on the firewall."

 Yes, we are. At least, I think I am. And I am here trying to help you, and that´s it.  Whether the gateway is core or firewall does not matter. I dont know your network so mpst of what I say I am supposing.

Then how it works with a client nw SVI ?

that´s a good point.

What is happening when we create a client nw SVI ?

That´s another good point.

If we have a problem with the network, what is it ?

Let´s try to find out.  I will look the link and do some reasearch and hit back here as soon as I have an idea.

[Flavio Miranda]

Hi @star btsistem 

  It did not take long. I have found this doc that explain your acenario.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/117278-troubleshoot-ise-00.html

I believe you fall in this exactly Scenario 5.

Scenario 5 - Destination Host is in Different VLAN, Exists, and is SVI 10 DOWN

If the switch does not have SVI UP in the same VLAN as the client, it can still perform redirection but only when specific conditions are matched.

The problem for the switch is how to return the response to the client from a different SVI. It is difficult to determine which source MAC address should be used.

The flow is different from when SVI is UP:

1. The client sends a TCP SYN to the host in a different VLAN (192.168.2.20) with a destination MAC address set to a default gateway which is defined on the upstream switch. That packet reaches the redirect ACL, which is shown by debugs.
2. The switch verifies if it has a routing back to the client. Remember that SVI 10 is DOWN.
3. If the switch does not have another SVI that has a routing back to the client, that packet is not intercepted or redirected, even when Enterprise Policy Manager (EPM) logs indicate that ACL is reached. The remote host might return a SYN ACK, but the switch does not have a routing back to the client (VLAN10) and drops the packet. The packet cannot just be switched back (L2), because it reached the redirect ACL.
4. If the switch does have a routing to the client VLAN via a different SVI, it intercepts that packet and performs the redirect as usual. The response with URL-redirect does not go directly to the client, but via a different switch/router based on the routing decision.

Notice the asymmetry here:

• Traffic received from the client is intercepted locally by the switch.
  
  
• The response for that, which includes the HTTP redirect, is sent via the upstream switch based on the routing.
  
  
• This is when typical problems with the firewall might occur, and a TCP bypass is required.
  
  
• Traffic to the ISE, which is not redirected, is symmetrical. Only the redirection itself is asymmetric.

[star btsistem]

Hi Flavio,

I know you are trying to help and very thank your replies and comments, may be I could not express myself. Thanks for this document. I have read that document before i've written here, and I have focused TCP bypass here. Here I think we need to enable TCP state bypass on firewall with a specific source and destination. And here the source: client nw dest: ISE PSNs right ?

[Flavio Miranda]

Yes. Because the problem occurs when the ISE initiate the communication, the switch intercept but the Client must finish the communication, then the Firewall will complain.  

[hslai]

@star btsistem Do try the call home list.

[star btsistem]

Hi @Flavio Miranda and @hslai ,

Thanks for your comments and Sorry for late response i was a bit busy nowadays. Now i want to describe the architecture and what i need. We are using F5 LTM for load balancing and we have 2 psn nodes behind F5. We have configured ip forwarding on F5 for accessing to ISE PSN nodes directly from client network for posturing. We are using call home list on posture config. When client initiates radius request, F5 sends the client to PSN-2. However on client anyconnect, system scan server is seen as PSN-1 (on call home list, PSN-1 is the first node). On the anyconnect it is seen as compliant on PSN-1. But when we check ISE it is seen as pending on PSN-2 (At first on ISE the client is seen as compliant with PSN-1 then it turns to pending). When we change the order on call home list (when we changed the PSN-2 to the first line) on anyconnect system scan server is seen as PSN-2 and it works. Then I think it means call home list is working. The other thing, if i create SVI as i mentioned earlier and discussed with Flavio, on the client anyconnect it is also seen as scanned at PSN-2 then also it works. We are using call home list, the client also is scanned with the PSN mentioned in call home list but i think PSNs did not share status between them i think ? How can i achieve this issue ? My description may be too complicated sorry for this. I have also examined the documents below.

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-software/215260-ise-posture-deployment-best-practices-an.html#anc8

https://community.cisco.com/t5/security-knowledge-base/how-to-cisco-amp-f5-deployment-guide-ise-load-balancing-using/ta-p/3631159#toc-hId--291151311