This is an amazing method for getting users in their correct groups in Fortigates. This way we can apply different security profiles to individual groups, all through one 802.1x login. This example is using Ruckus wireless , but will work exactly the same for any wifi vendor..
This method works by using 802.1x WPA2/AES logins on the Ruckus , and passing the users info over to the Fortigate by Radius accounting. Then on the Fortigate we are using RSSO (Radius single sign on) groups to collect the username/group that is sent to the Ruckus by the Windows NPS server. Lots of moving parts here, but it is really simple. I have had problems finding good documentation about Fortigate’s RSSO profiles – but they work great.
The goal of this project/entry is to have the Fortigate know the Username, IP and group (if assigned) of the user who just authenticated to the wireless network. Once you know these things you can apply different UTM policies to users VIA RSSO groups in the Fortigate. There are many good scenarios and uses for this – one example that I have is for a school network. I set this up recently for a school that has students and faculty authenticate through the same Ruckus controller, but to different 802.1x WLANs (SSIDs: Student and Faculty). The fortigate can then apply correct policies to each user (student or faculty) and therefore lock down student web surfing much more than a faculty member. You might be saying – you could just use captive portal on the fortigate,with LDAP groups. I would say yes, but that is another step users have to take, and its called “Single Sign on” for a reason.
So what is needed to make all this happen: Ruckus wireless using 802.1x, NPS (or any radius server) , Fortigate – that’s it.
I am going to assume that we already have Ruckus using 802.1x and NPS with no problems.
I had trouble at first setting this up, because I thought that that the NPS server should send the radius accounting info to the Fortigate, I was wrong. The controller is the Authenticator – therefore the device that knows about the authentication, and needs to pass on the info to the Fortigate. The Authenticator (Controller) needs to send the radius accounting info to the Fortigate.
That means you have a AAA server setup on the controller for 802.1x authentication, and a AAA radius accounting server pointing to the Fortigate.
Setup Radius accounting between Ruckus and Fortigate
First we need to create the connection between Ruckus and Fortigate via radius accounting.
On the Ruckus system, go to Configure – AAA servers – create a new server. Then click the box that says “Radius accounting” Fill in the IP of your Fortigate, and create a PSK between the two.
Next on our Fortigate we need to create a RSSO profile for the Ruckus system.
Feel free to name this Ruckus or whatever. The PSK has to match what you created on the Ruckus system. By default the RSSO profile uses the Class variable to match the users. You can change what to match, for example you could match by NAS-Port, User-Name, Class, etc.
So, if we go into CLI we can modify many of these settings. Below are the settings I have used
config user radius
set rsso enable
set rsso-secret ENC eoTXOqectoW0sjb5lLVW/7rr3BB0DocxlKeW64yfoIq7NTblyMc1TT9/V2M8m2LJmotwNrDYS+hOBSWV68wWULjuT88tOZHli7Nqqe8k5hoK4iHmLuG6x9R7apR9b+JU6O48mY8jiUaf48pY8wamagNdOALtrew6k+yWFzfd7gzo+qgag2sOI+Q46GnI1ybGPo6YQQ== set rsso-endpoint-attribute User-Name
Next we need to modify NPS to send the values that we will match on the Fortigate. In this example I am matching I am saying that if any Domain users authenticate through the ZD, then send the IP/Username/”Tag” to the Fortigate so it knows who to apply the correct firewall policy to. My “Tag” I am sending in is the Class Variable of “Domain Users”.. Something to note is this is not the given AD group, but a variable I am assigning that just references the group. I could say “Social media” if I wanted, then match on that.
So lets modify the Microsoft NPS policies to reflect what we need.
Remember, we are going from the assumption that 802.1x is up and working, and NPS is great. So, how do we match a variable from NPS on the fortigate? We could really use a ton of different variables. Lets use the class variable. To assign the class variable we will modify the the Network Policy in NPS that we want to apply a to a certain criteria.
I will modify my “Connections to Wireless VIA AD Authentication” Policy. Then once, you edit the policy and go to “Settings” tab, there will be a few attributes already listed . You may have some already or not. We will add the “Class” variable, and then assign it to what ever value we want to match in the firewall group. In this case I am setting my value to “Domain Users”.
So from the settings tab, lets click “Add” under the Radius Attributes standard section.
Select “Class” from the list of attributes that comes up, it will then ask you to enter a string that you want to set. This is the Keyword you will use to match the user to group in the Firewall. Just like use a FSSO group and matching the domain group. Some examples might be students vs teachers, or Domain users.
Press OK, and now we have the variable added, you can confirm as seen below:
Great, now we have the hard part done. Now, have some users log in to wireless, and see if you get correct RSSO users found in the firewall. you can check this my navigating in the firewall to User&Device – Monitor – Firewall
Awesome, it found my username, and my IP, but my group is blank, how can you apply a policy to user if they have no group? The answer – is just the same as the FSSO. If you do not have a firewall policy that references the Radius group that you created then no group, no filtering, nothing. So you need to create a new firewall policy and select the RSSO group you created as the source group. In my example the group is called Radius Domain Users.
To show a policy example check out below: My domain FSSO is above my RSSO policy.
Now that that is created and enabled, lets check the user monitoring – BAM! there it is, my group included.
Using RSSO and 802.1x is awesome, it allows you to kinda use a single pane of glass aspect and have Firewall, and Wireless be able to know who the user is just my them logging into the wireless network. Also, using 802.1x for wireless authentication and Key management is very secure. Having users known that are on wireless no matter what device can really be beneficial in reporting, either through Forticloud of FAZ.
I thought I would blog on this. It could be useful for someone who might have an IOS router instead of an ASA and need to create a IPSEC Site-to-Site VPN to a remote peer, then NAT VPN traffic to a different address or subnet if needed, or the local subnets conflict with each other.
Here is a nice little Visio to kind of show what I am going for with the traffic:
Because of duplicate subnets on both sides, I need to nat traffic going to 188.8.131.52 from 192.168.10.10, otherwise traffic should flow normally. How can I achieve conditional nat? By using a route-map and then natting only the traffic in the Route-map. So, lets get our VPN setup first. Remember, we add the NAT network or host IP to our interesting traffic ACL that will be used to define our Phase2
These are my commands:
ip access-list extended VPN-to-Remote permit ip host 10.255.232.10 host 172.20.0.192
crypto map Crypto 6 ipsec-isakmp set peer 184.108.40.206 set transform-set Transform match address VPN-to-Remote
That pretty much gets the VPN up and going. Now for the interesting part – we need to create a new ACL, match my private 192.168.10.10 address and the destination address of the remote server, then match that ACL in my Route-map.
ip access-list extended Nat-for-VPN permit ip host 192.168.10.10 host 172.20.0.192
route-map VPN-to-REMOTE permit 10 match ip address Nat-for-VPN !
Great! So, we now have the route-map created.. so now what? We need to create a NAT statement that references my Route-Map. Then of course with any VPN we need to modify the “NO-NAT” ACL to include the traffic for both the 192.168.10.10, and the 10.255.232.10 to my remote destination.
ip nat inside source static 192.168.10.10 10.255.232.10 route-map VPN-to-HCN extendable
ip access-list extended NO-NAT deny ip host 10.255.232.10 host 172.20.0.192 deny ip host 192.168.10.10 host 172.20.0.192
Now, if we try to access the remote side, does it work? Yes it does, but lets check to see if our nat is really working. It is! As you can see, 192.168.10.10 going to 172.20.0.192 is being natted into 10.255.232.10, but all other traffic gets natted out of the WAN interface.
Lets just check for translations of 10.255.232.10
Bingo, everything works great. Lets make sure that we are getting hits on our Route-Map.
Recently I was seeing this error pop up on many Windows desktop clients:
The system detected an address conflict for IP address 0.0.0.0 with the system having network hardware address Ed-Ef-A9-B8-CC-2E. Network operations on this system may be disrupted as a result. Mac will vary.
To give some highlights : “Cisco IOS® uses the Address Resolution Protocol (ARP) Probe sourced from an address of 0.0.0.0 in order to maintain the IP device-tracking cache when IP device tracking and a feature that uses it is enabled (such as 802.1x) on a Cisco IOS switch. ”
“If the switch sends out an ARP Probe for the client while the Microsoft Windows PC is in its duplicate-address detection phase, Microsoft Windows detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network for 0.0.0.0”
So we now know the issue is with IP Device tracking, but what the heck does this do? IP Device tracking keeps an active list of devices that are connected VIA ARP. The function has as Cisco put it “Always been around”, is extremely beneficial when using MAC ACLs or using 802.1x. Recently it has really been used with Network Mobility Services Protocol (NMSP), this feature manages communication between the mobility service engine and the wireless controller in newer switches.
So how it works – When a link is detected, it sends unicast Address Resolution Protocol (ARP) probe with a default interval of 30 seconds; these probes are sent to the MAC address of the host connected on the other side of the link, and use Layer 2 (L2) as the default source the MAC address of the physical interface out of which the ARP goes and a sender IP address of 0.0.0.0, — Bingo there’s are default IP that pops up.
So how do we remove device tracking? Easy huh.. just “no ip device-tracking” – this currently gives an error in certain firmwares. Firmware 03.02.02.SE and below give, the error is:
% IP device tracking is disabled at the interface level by removing the relevant configs
So, you could upgrade to 3.3 and then use the no ip device-tracking command, or if you cannot upgrade still disable all the features of IP device tracking. To do this:
Under each interface use commands:
nmsp attach suppress
no ip device-tracking max
I would recommend using a range command to get all the ports at once. This has fixed the issue for me.
I was working with some wireless bridge the other day that I had never used. I needed to get VLAN tags to pass through this wireless bridge, but for some reason they were not. I thought.. “this is a bridge it should pretty much be plug and play”. I was wrong. These bridges seem to do a great job, and are easy to setup, but I had problems finding out how to do this. I thought I would write up a simple post on how to allow VLAN tags to pass through this bridge.
My first issue was the bridges were on a very old firmware. I was on version 5.3, after finding some documentation I thought it was best that I upgrade. I upgraded all the way to the newest version which is 5.6.
Next I noticed that the WDS was not checked. To give some background on why this is so important:
WDS, which stands for Wireless Distribution System, is a feature that enables single-radio APs to be wirelessly inconnected instead of using a wired Ethernet connection.WDS connections are MAC address-based and employ a special data frame type that uses all four of the (MAC) address fields allowed in the 802.11 standard, instead of the three addresses used in normal AP <-> STA (client) traffic. (In the 802.11 frame header, address 1 is the destination address, address 2 is the source address, address 3 is the BSSID of the network and address 4 is used for WDS, to indicate the transmitter address.)
So that’s the reason that Vlan tags would not pass – WDS was not checked, so basically this was a acting as a switch instead of a transparent bridge.
Here are my settings that in the end fixed my vlan tagging issues. First had to upgrade the firmware, then next enable WDS on both aps, one being a Station (Client) the other being a AP. Last, of course make sure that switches both bridges plug into are trunk ports, and have the vlans created.