FSSO and multiple network connections

[MikeMo]

I' m curious if anyone has run into this problem and if so, what have they done to fix it? (v4 MR3 P8) I have FSSO configured and it has been working properly now for several years. However, in the last few years more and more wireless connections are being made available to our users. We have implemented group policy to configure our wireless adapters to authenticate users using 802.1x and PEAP to allow authenticated users access directly onto our corporate wireless network and keeping guest users separate. The problem we have is that with this setup, users frequently use both wireless and wired connections simultaneously as they generally forget to disable their wireless connections. This seems to present a problem with FSSO. It seems (this is a bit of an educated guess) that when a user authenticates they may source from either the wireless or the wired connection resulting in a event log entry that is monitored by the collector agent. However, sometimes when a user later goes to the internet, the traffic sources from the other adapter' s IP address. This seems to confuse the FSSO system and the user ends up with Guest access even though they are authenticated. I know this is a lot of info...but has anyone run into this? Thoughts/Suggestions?

[MikeMo]

Does anyone have any thoughts on this?

[MikeMo]

Not sure if anyone is interested...but I have isolated this problem to a DNS issue. The problem is caused by dynamically update settings in the DNS settings for the DHCP scope. While FSSO can handle duplicate logins from multiple IPs, it still utilizes DNS when logging entries in its table. FSSO seems to log the IP, hostname, and username for each user it " authenticates" . The problem: Sometimes a wired connection' s DNS entry is dynamically removed and the wireless IP is registered with DNS as an A record. This is not normally a problem. However, if the binding order is set properly and the PC utilizes the wired connection as it' s outbound connection, this presents a problem for FSSO. The firewall sees the user connection coming from the wired segment but the entries in the FSSO table on the collector sees the user associated with the A record which is now pointing to the wireless address. The fortigate then determines that the user should get " guest" access as it cannot match the user to the appropriate IP. The solution: Not sure yet. There are multiple ways to attack this but I am still trying to figure this out. Suggestions welcome.

[jmac]

This may be a problem with network adapter binding order. The FSSO collector will only see the IP address of the network connection which was used for initial authentication to the server. If the wired and wireless adapters are both active then it depends on a few factors. If the wired network adapter is highest in the binding order, then domain authentication and internet traffic should traverse it as long as it was present at startup and remains active. If the wireless network adapter is highest in the binding order, then it depends on whether the wireless network is available when the user logs in and how the wireless connection is authenticated. The wired network may be used for authentication if they log in quickly after startup before the wireless network is available, then switch to the wireless network when available because it' s higher in the binding order. This may cause the computer to use the wireless network and FSSO will have no authentication record for that IP. If the user always connects the network cable before startup, then ensuring the wired network adapter is top of the binding order should help. If they tend to plug in cables after startup, then it' s difficult to control.

[Dave_Hall]

Wasn' t the " FSSO IP address change verify interval" option suppose to overcome this?

[MikeMo]

Thank you both for the replies. @Dave - Not sure if that feature will specific resolve this issue. It seems to me that Fortinet is using DNS as a part of this process to authenticate users. So if the DNS entry is pointing to a wireless IP and the PC is configured to use the wired interface then the issue persists. @jmac - Yes you are on to something there. We investigated this as well. The problem is that we always set the binding order for the wired interface to be ahead of the wireless interface. This allows for a better connection if both interfaces are enabled at the same time. So we have the binding order set the way we want it. However, we also have group policy configured which sets up a wireless configuration using PEAP. This is to allow our mobile users to move from wired to wireless and AP to AP seamlessly on the network while maintaining security. When you set this in group policy the wireless connection will always attempt to connect to this immediately if the network is in range and the adapter is enabled. So in our experience setting the binding order also doesn' t seem to resolve this issue. A simple solution would be to " just switch the dang wireless off" . Apparently this is not something people can easily get used to as they use wireless at home and forget to disable it when returning to the office. So at this point I think I am down to either adjusting some setting in FSSO that I am unaware of (open ticket with Fortinet) or modifying the way we handle DNS either on the server or client to prevent this from occurring. In most situations multiple connections hasn' t even been an issue but for FSSO it creates a problem sporadically. Thanks again for the responses. Any other thoughts?

[Rick_H]

Mike, I see this exact problem, though not widely because we have pretty strict controls on who can use the Corporate wireless. Funny enough, it is my boss (the IT Director) that I have the most frequent problems with. I came to the same conclusions that you have, largely, and have tried the same fixes to no avail. So, right now we' re just living with it. I did find some third-party utilities that will monitor both the wireless and wired interfaces and automatically disable the wireless if the wired is hooked up. This seems like a viable solution, but none of the utilities I found were free and I have not yet convinced my boss that the expense is worth it. As an aside, we migrated from Websense to the webfilter in the Fortigate mostly because of cost (we didn' t even start using the firewall portion until recently). Websense did not have this problem, but it also seemed to have a different method for identifying users. Hopefully someone up at Fortinet keeps an eye on these forums and can suggest to engineering to take a look at the way Websense does user identification.

[MikeMo]

Yeah I have looked at those too. There are even some solutions that suggest using a script that runs via scheduled tasks to monitor the network connections and shut off wireless when wired is in use. However, this seems like it might have it' s own set of issues. I do have a ticket in with Fortinet to see what they suggest and will post back if they provide a solution. Thanks for the reply it' s good to hear I' m not alone in this. If you are interested in the scripted option check this article out... http://community.spiceworks.com/how_to/show/14437-how-to-bring-harmony-to-your-mixed-wired-and-wireless-networks

[Dave_Hall]

The corporate standard we have deployed is to simply create two wireless network: one internal corporate wireless network and one public (for guests only). The corporate wireless network is merged into a soft-switch with the internal subnet -- authentication is done thorough a RADIUS server. Guest wireless is strictly firewalled off from any contact at all to the internal network.

[MikeMo]

@Dave - this is very similar to what we have for corporate and public. We use group policy to configure windows to handle the corporate settings since we use PEAP. This results in the network automatically connecting if it is enabled (the system will follow the order in group policy). Do you have this same issue if both interfaces are enabled and connected at the same time? Do you use DHCP? If so, do you use dynamically controlled DNS settings in the DHCP scope?