cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4166
Views
35
Helpful
7
Replies

URL-Redirect does not working with Cisco Switches Catalyst 4500E

I implement ISE v1.4 on our network we use 'Compus Design', We have one subnet for all switches '192.168.40.0/24' as SVI for management, and we have many VLANs for end-users, Web Redirection does not work on any of this VLANs, It work only when I but end-user with same subnet of management VLAN. what can I do resolve this issue.

should I create SVIs for all end-users VLANs?.

Best Regard 

2 Accepted Solutions

Accepted Solutions

Mohammed,

Does your management subnet have a route and is allowed access to the subnets where your users and devices reside? This is required when doing wired ISE URL redirect as the redirect comes from the switch's management SVI and is sent to the client device IP (which it knows by virtue of ip device tracking).

I had a similar problem where the customer's management network was firewalled away from user VLANs. Once we opened the necessary access-list entry, redirects were received and started working.

No additional SVI is required. (Although having an SVI in the user VLAN also fixes the problem - but it's not the "proper" solution architecturally.)

View solution in original post

The origin IP of the URL redirect is the local switch's management SVI. It will need to communicate with the end host IP addresses on tcp/80 (http) and tcp/443 (https).

You didn't include it above, but be sure that your switch has:

ip http server
ip http secure-server

...enabled. Those are required for the switch to be able to do the URL redirect.

If your're concerned about enabling those services increasing the attack surface of the switches' management plane, you can restrict that via the following (the ports will still be open but the switch will not accept any sessions on them):

ip http secure-active-session-modules none
ip http active-session-modules none

View solution in original post

7 Replies 7

nspasov
Cisco Employee
Cisco Employee

Hi there, I have a couple of questions:

1. Who is doing the routing for those end user VLANs? (Where is their default gateway)?

2. Can you post your RADIUS and dot1x related configs?

Thank you for rating helpful posts!

Dear Eng. Neno:

Thank you for support, Firstly I want explain you the big picture:

End-user<----> (Access_SW also act as Distribution_SW ) <-----> (Core_SW)<--->(Core_SW)<--->(Access_SW)<---> ISE Server. 

  Communication done between NAC agent and ISE 'Authentication Authorization Accounting', Just Web-redirect does not work with clients on any VLANs only when I put client into Management VLAN. 

I tested with add another SVI for specific VLAN and Web-redirect working. From that I suppose it I need SVI for every VLANs?,

I have a lot of VLANs should I create SVI for all VLANs???

1. We use OSPF on Core Switch for all VLANs routing.(there not any routing Access SW, Just they're one SVI 192.168.40.11 for VLAN Manage and default route '0.0.0.0 0.0.0.0 192.168.40.1'.)

2. 

aaa new-model
aaa authentication login default enable
!
radius server ISE
address ipv4 192.168.1.100 auth-port 1645 acct-port 1646
key password
!
ip device tracking
radius serer vsa send authentication
radius serer vsa send accounting
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius

aaa server radius dynamic-author
client 192.168.1.100 server-key password
radius server attribute 8 include-in-access-req
dot1x system-auth-control
!
interface gigabitEthernet 0/1
switchport access vlan 600
switchport voice vlan 500
authentication host-mode multi-auth
authentication open
authentication periodic
authentication timer reauthenticate server
dot1x pae authenticator
dot1x timeout tx-period 10
authentication port-control auto

Mohammed,

Does your management subnet have a route and is allowed access to the subnets where your users and devices reside? This is required when doing wired ISE URL redirect as the redirect comes from the switch's management SVI and is sent to the client device IP (which it knows by virtue of ip device tracking).

I had a similar problem where the customer's management network was firewalled away from user VLANs. Once we opened the necessary access-list entry, redirects were received and started working.

No additional SVI is required. (Although having an SVI in the user VLAN also fixes the problem - but it's not the "proper" solution architecturally.)

Dear Eng.  Rhoads:

      I hope you well, Yes I think the problem from firewall. That mean management IP its involving in redirect process. But what port should be open it on firewall ? .

The origin IP of the URL redirect is the local switch's management SVI. It will need to communicate with the end host IP addresses on tcp/80 (http) and tcp/443 (https).

You didn't include it above, but be sure that your switch has:

ip http server
ip http secure-server

...enabled. Those are required for the switch to be able to do the URL redirect.

If your're concerned about enabling those services increasing the attack surface of the switches' management plane, you can restrict that via the following (the ports will still be open but the switch will not accept any sessions on them):

ip http secure-active-session-modules none
ip http active-session-modules none

Thank Marvin

do you mean the vlan management  and vlan client have a route between them , that mean must I route all my vlans to mangement subnet .

what the necessary access-list entry you opened on your firewall.

No you do not need to route all your VLANs to management subnet.

The URL redirect traffic will originate from the switches' management SVIs (assuming that is the only IP address on a typical campus access switch). Those switches have a default gateway or default route on some upstream device. Depending on your design, that could be a distribution switch, a core switch a firewall etc.

Whatever it is, it must have in its routing table a way that will reach the end hosts' subnets. Any security enforcement device in the path must allow that traffic.

In the simplest scenario it would be a core switch with an interface ACL on the management subnet. I have seen that, I have seen it be a firewall (Cisco ASA or other) and I have seen the separation be via use of VRF in the core.

The ACL would be something like:

ip access-list extended <acl name> 
permit tcp <management subnet> <mask> any eq www
permit tcp <management subnet> <mask> any eq 443

...for a switch.

If the device is an ASA firewall it would be something like:

access-list <acl name> permit tcp <management subnet> <mask> any eq www
access-list <acl name> permit tcp <management subnet> <mask> any eq 443