cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2151
Views
6
Helpful
6
Replies

Guest users behind NAT?

dazza_johnson
Level 5
Level 5

Hey guys, so my scenario is guests are on 10.2.3.x/24 in the DMZ. When they hit the Guest portal (ISE at IP address 4.5.6.7), they are NAT'd to IP address 54.54.54.54. So basically, ISE see's the guests using the same IP address 54.54.54.54 - does this still work or not?

Forget the bit about best practise - just curious if it would work. In my mind (and I'm happy to be corrected), this will still work as the URL that the guests are redirected to contains some unique information for each user, so ISE is able to inform the WLC (via CoA) after a guest is logged in (CoA is basically tell WLC MAC address is now auth'd so permit full access to internet).

Thoughts?

DJ

1 Accepted Solution

Accepted Solutions

In general, all the RADIUS traffic to/from WLC should pass through the LB.  This will provide symmetric pathing and also facilitates SNAT of CoA from PSNs back to NAD.

Starting in ISE 1.3 we added support to automatically return traffic on same interface it was received provided a default route is configured for that interface.  In ISE 2.0 we added logic to use global default gateway for PSN-initiated traffic that transcends individual default routes (ip route 0.0.0.0 ...).

Some additional multi-interface examples with and without NAT are provided in reference version of BRKSEC-3699 presentation posted to CiscoLive.com.

/Craig

View solution in original post

6 Replies 6

paul
Level 10
Level 10

Darren,

Works fine.  The guest IP is irrelevant in the guest flow.  As long as the WLC can talk back and forth with the ISE PSNs it all works fine.  I have done setups where at remote sites the guests are completely isolated networks on FlexConnect APs and they access dedicated guest PSNs I have sitting in the DMZ in the datacenter.  The guests come across the Internet to go through the portal.  The PSNs can talk just fine to the WLC and the CoA on the session ID gets the user on the Internet after they go through the guest portal sequence.

Darren,

Here is a drawing I put together for a client that shows all the steps in the guest process.  This was for the customer that had the guest PSNs in the DMZ off the firewall and access the guest portal across the Internet.Guest Flow.JPG

Nice job on the drawing Paul. Curious how many interfaces you are using on the Guest PSNs and whether the guest internet traffic is also flowing through a firewall. Do 4, 11 and 14 route through the load balancers to communicate with the WLCs?

In this customer case, we had setup dedicated Guest PSNs with single interfaces in the DMZ behind the load balancers.  All flows went through the load balancers and firewall to get to the guest PSNs.  The load balancer was also responsible for changing the CoA traffic source IP to the VIP address.  In other cases I have used multiple NICs on the PSNs to do a similar setup but that is messy because the PSNs use a unified routing table.  So your default gateway on the PSN points to the DMZ and you have to add static routes for internal subnets pointing out the internal NIC.

On the guest side, they were going through a PAT device (FW, router VRF with PAT, etc.).  I don’t remember what security was being applied to that traffic.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

In general, all the RADIUS traffic to/from WLC should pass through the LB.  This will provide symmetric pathing and also facilitates SNAT of CoA from PSNs back to NAD.

Starting in ISE 1.3 we added support to automatically return traffic on same interface it was received provided a default route is configured for that interface.  In ISE 2.0 we added logic to use global default gateway for PSN-initiated traffic that transcends individual default routes (ip route 0.0.0.0 ...).

Some additional multi-interface examples with and without NAT are provided in reference version of BRKSEC-3699 presentation posted to CiscoLive.com.

/Craig

Ahh thx Craig. I don’t have many multi-NIC deployments so haven’t played around with the routing logic too much. Good to know the logic exists to return out the same interface.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250