Description
Fortinet TSagent provides the ability to use FSSO authentication on terminal servers.
This is accomplished by providing a specific source port range for every user connected to a terminal server.
Each user traffic will then be identified by the source ports.
This article describes how to troubleshoot when HTTP traffic is being blocked.
Solution
1) Check that FortiGate has recorded the correct information from TSagent.
#diagnose debug authd fsso list
IP: 192.168.1.101 User: FTNTUSER Groups: CN=FORTINET,CN=USERS,DC=FTNT-LAN Workstation: 192.168.1.101!FTNT-LAN!00000003 MemberOf: ftntuser FSAE_SUPPORT Session ID: 3 Port Range(1): 29600-29799
In this line we see that FortiGate recorded this information about an authenticated user:
IP: 192.168.1.101 <----- IP of your Terminal Server.
User: FTNTUSER
Port Range(1): 29600-29799 <----- assigned source port range.
Note: the setup can contains more information about users.
The port range of 200 (29600-29799=200ports) matches the configuration of the TSagent, to allocate 200 ports per user in several slows (shown by the number (1), and if needed, allocate another slot of 200 ports.
The setup might look different but the 'port range' shows that FortiGate has learnt about the user FTNTUSER with a defined port range, coming from FSSO TSagent.
Traffic that is coming from that IP with source ports belonging to this entry will be identified as belonging to the user.
2) Check incoming packet information using flow trace
FTNTUSER is still logged on, so make use of that same user session to create traffic to some webserver whose destination IP is known.
In this example it would be 12.23.34.45. Knowing the destination IP will make it easier to spot the packet of the following flow trace.
There may be other traffic such as Windows Updates which could run outside the defined port range as system traffic.
#diagnose debug console timestamp enable
#diagnose debug flow filter saddr 192.168.1.101 <----- Filter for source IP of the terminal server.
#diagnose debug flow trace start 10
#diagnose debug enable
2019-11-14 07:16:35 id=13 trace_id=223 func=resolve_ip_tuple_fast line=4299 msg="vd-root received a packet(proto=6, 192.168.1.101:63839->12.23.34.45:80) from port1."
2019-11-14 07:16:15 id=13 trace_id=223 func=init_ip_session_common line=4430 msg="allocate a new session-0283e214f"
2019-11-14 07:16:15 id=13 trace_id=223 func=vf_ip4_route_input line=1603 msg="find a route: gw-192.168.100.254 via wan2"
2019-11-14 07:16:15 id=13 trace_id=223 func=__iprope_tree_check line=534 msg="use addr/intf hash, len=41"
2019-11-14 07:16:15 id=13 trace_id=223 func=fw_forward_handler line=533 msg="Denied by forward policy check"
Lines below are showing:
Source IP: 192.168.1.101 <----- Terminal Server IP.
Source port: 63839 <----- Port outside of users range.
Destination IP: 12.23.34.45 <----- webserver the terminal server user FTNTUSER is trying to reach.
Destination port: 80 <-----webserver port, HTTP.
A problem with the HTTP traffic is visible .
The source port is not in range specified for that authenticated user.
The flow trace shows that this traffic is denied, since there is no policy that would allow unauthenticated traffic.
- Check the ports used on the Terminal Server using the netstat -anb tool on the command prompt or the 'tcpview' utility.
- Locally installed software may be intercepting and modifying HTTP traffic.
Example:
Some antivirus softwares can use a local proxy service to scan HTTP traffic for URL filtering and AV functionality.
Such proxies will intercept traffic originated by the Terminal Server user, and will create a new session using the Windows default dynamic port range.
Since the source port is being changed, the use of such software would break the TSagent functionality.
Depending on the requirements such traffic scans could be handled by the FortiGate.
