Guest in separate VRF - support for HTTP Redirection in Switch for VRF?

[Gustavo Novais]

Hello,

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.

Gustavo

[jwmolenaar]

Hi Novais,

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:

http://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/113362-config-web-auth-ise-00.html 

Important Note about Switch SVIs

At this time, the switch needs a switch virtual interface (SVI) in order to reply to the client and send the web portal redirection to the client. This SVI does not necessarily have to be on the client subnet/VLAN. However, if the switch has no SVI in the client subnet/VLAN, it has to use any of the other SVIs and send traffic as defined in the client routing table. This typically means traffic is sent to another gateway in the core of the network; this traffic comes back to the access switch inside the client subnet.

Firewalls typically block traffic from and to the same switch, as in this scenario, so redirection might not work properly. Workarounds are to allow this behavior on the firewall or to create an SVI on the access switch in the client subnet.

So from my perspective the key question is: Is there any communication possible between the SVI and the guest client subnet?

[Gustavo Novais]

Hello,

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?

Gustavo

[greg.fuller]

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.

[jwmolenaar]

Hi Greg,

Could you please share an example, including the SVI configuration?

Regards, Jan-Willem

[Gustavo Novais]

Hello,

just a follow up update:

apparently in what concerns 3850, the version 3.7.3E should fix the issue...

to be tested.

Regards

[jwmolenaar]

Hi Gustavo,

Could you please share the "IP HTTP" configuration of the switches and what security measure you have taken on the Guest SVI?

Many thanks,

Jan-Willem Molenaar

[Gustavo Novais]

Hi Jan,

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.

Regards

[jupoole]

Did this ever get resolved? I still see the same issue in 03.07.05.

[sfkabdulkadir]

Hello,

We see the same problem on c9300 switches (ver 16.12.4). C9300 switches are connected to nexus7k switches.( SVIs are on Nexus switches.)