I'm working on a deployment where we need to redirect wired guests to a web portal for authentication. We're using CWA - the radius server sends a url-redirect to the switch, as well as the url-redirect acl that is meant to specify the traffic to be redirected. The switch doing the redirection has an SVI on the same vlan as the wired users.
This would be a standard design, covered by ISE design guides, if not for a small detail: We have the requirement to keep the wired guests in a separate VRF, on the switch doing the L3.
My problem is that, if we keep the clients on the default VRF, the web redirection works perfectly, but as soon as we place the communication path (switch interface + RADIUS + Web Portal Connectivity) doing the redirection in a non-default vrf, I can see that the RADIUS transactions are successful (url-redirect is applied to interface), but the client never gets redirected to the portal where he needs to authenticate.
Is URL redirect supported in a non-default vrf? is the HTTP code, running on the switch, and responsible for the 30x redirect code vrf aware? Is there a magic command that I need to put (either on url-redirect av-pair, url-redirect-acl or on the HTTP server config) to make this vrf aware?
I've tested this in 2960's, 3750 and 3850 and all of those seem to not be able to redirect the client when on non-default vrf.
Thanks for any insight.
You mentioned a very interting issue. I'll be in charge of a project to arrange exactly the same: Guest User in a different VRF then the SVI of the switch.
There is a CWA guide on CCO which mentioned the following about Switch SVI's:
So from my perspective the key question is: Is there any communication possible between the SVI and the guest client subnet?
Thank you for your reply. I'm aware of that specific note, hence the creation of an SVI on the guest's subnet.
Communication between SVI and Guest is assured (they can ping each other). The problem is that when we have the SVI on the default VRF, url redirection works, but when SVI (and remainder of RADIUS+WEBPortal) is on a non-default VRF, url-redirection doesn't work.
The client can always ping the SVI (and RADIUS/WebPortal). It just doesn't get redirected.
I found a bug related to ISE - CSCuq77696, but it didn't say anything relatively to changing switch config or http vrf support.
Any insights on that?
When the redirect happens on the switch, the packet is punted to the cpp for processing. The cpurpose does the rewrite and then kicks it back down a layer to be routed. This process isn't vrf aware and is sent back to the global vrf (at least it was with our 3750x switches running 15.0.2 se6).
In our case global was routed to a different firewall interface (which we had unicast rpf enabled on) and it was dropped there.
What we ended up doing was creating a fake route on each 3750x for the subnet that the guest vlan on that switch stack was on and specify the physical vlan interface it should exit out on. This resolved the problem when the redirect packed from the cpu came back to be routed. I can provide an example if you need it.
Could you please share the "IP HTTP" configuration of the switches and what security measure you have taken on the Guest SVI?
The bit I can share is
ip http server
ip http secure-server
ip http secure-active-session-modules none
ip http active-session-modules none
This bit of code disables all management modules on the switch (what we want is simply that the switch intercepts HTTP/S requests and send a 30x redirect, not for it to be managed via http)
Then we need to harden the switch interface so that people cannot connect to it in SSH, etc - which means basically access-classes in lines vty.
You can put inbound ACL's on the Switch SVI too to avoid traffic directed to the specific switch IP address (there shouldn't be any traffic directed to the switch) but we didn't go that far.