DescriptionThis article describes how to allow Terminal Server or Citrix system update traffic in TSagent deployments.
In
a FSSO Terminal Server Agent (TSagent) deployment, users authenticated
traffic leaves the Terminal Server (TS) and/or Citrix server using a
specific source port range.
The same source port ranged is used by the FortiGate to identify the traffic as user traffic for FSSO via the Collector Agent.
In the example below, the source port range is 20000-39999.
However,
some system services like Windows Update, FortiClient, other vendors
clients or third party applications update may need to use ports ranged
outside the TSagent port allocation range scope.
The
FortiGate would see such traffic as unauthenticated and might block the
traffic. This article explains which steps can be taken to ensure such
traffic is not blocked.
ScopeTerminal Server Agent (TSagent)SolutionThere are two options to allow the 'system traffic' to go through the FortiGate.
1) Enable guest access for this traffic.
This example shows how to configure a FortiGate running FortiOS v5.2 to allow Windows and FortiClient updates.
#config firewall policy
edit 7
set srcintf "port2"
set dstintf "port1"
set srcaddr "TS-CITRIX-Farm" <----- Custom
address group of the Terminal Server and or Citrix servers host
set dstaddr "all"
set action accept
set schedule "always"
set service "HTTP" "HTTPS" "DNS" <----- These
ports are been used by the servers for Windows and FortiClient updates
set utm-status enable
set webfilter-profile "monitor-all" <----- Optional webfilter inspection, profiles additional filtering
set profile-protocol-options "default"
set ssl-ssh-profile "certificate-inspection"
set fsso enable
set groups "SSO_Guest_Users" <----- FSSO guest group for v5.2
set nat enable
next
In
this example, all HTTP / HTTPS / DNS based unauthenticated traffic
coming from the CITRIX server farm matches this policy and uses guest
access.
#diag sys session list
session info: proto=6 proto_state=11 duration=10 expire=3595 timeout=3600 flags=00000010 sockflag=00000000 sockport=80 av_idx=1
use=4
...
user=guest group=SSO_Guest_Users state=redir log local may_dirty authed none app_ntf acct-ext
statistic(bytes/packets/allow_err): org=707/6/1 reply=828/5/1 tuples=3
orgin->sink: org pre->post, reply pre->post dev=4->3/3->4 gwy=172.17.97.254/192.168.1.211
hook=post dir=org act=snat 192.168.1.211:49258->142.231.1.165:80(172.17.97.181:49258)
hook=pre dir=reply act=dnat 142.231.1.165:80->172.17.97.181:49258(192.168.1.211:49258)
hook=post dir=reply act=noop 142.231.1.165:80->192.168.1.211:49258(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=2 auth_info=4294967295 chk_client_info=0 vd=0
serial=00016d5d tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
2) Bypass policy
This
option could be use in scenarios in which guest access is not desired
or guest access is configured in interactive mode (asking for
credentials). In this scenario, a bypass policy using a custom
service is needed.
The custom service allows the FortiGate to
identify the interesting traffic. Only the traffic outside the
Terminal/Citrix servers users range has to match this policy. In this
TSagent config example, the users source port range is 20000-39999.
For
simplicity, consider that all servers in the farm has the same port range
configured on all TSagents. If for some reason all TSagent
installations cannot be configured with the same port range, separate
custom services and policies will need to be configured.
Similar to
option 1, the example provides pass-through ability to HTTP(S) traffic
used by Windows Update and FortiClient services.
The following custom
service matches traffic with destination port TCP 80 and TCP 443 and
source ports outside the users' range 20000-39999.
#config firewall service custom
edit "TS-system-services"
set tcp-portrange 80:1024-19999 80:40000-65535 443:1024-19999 443:40000-65535
next
end
Firewall policy:
#config firewall policy
edit 2
set srcintf "port2"
set dstintf "port1"
set srcaddr "TS-CITRIX-Farm" <----- Custom
address group of the Terminal Server and or Citrix servers host
set dstaddr "all"
set action accept
set schedule "always"
set service "TS-system-services" "DNS" <-----
TS-system-services - custom service filtering interesting traffic
set utm-status enable
set webfilter-profile "monitor-all" <----- Optional webfilter inspection, profiles additional filtering
set profile-protocol-options "default"
set ssl-ssh-profile "certificate-inspection"
set nat enable
next
end
#diag sys session list
session
info: proto=6 proto_state=11 duration=2 expire=3598 timeout=3600
flags=00000010 sockflag=00000000 sockport=80 av_idx=1 use=4
...
state=redir local may_dirty none app_ntf
statistic(bytes/packets/allow_err): org=402/4/1 reply=486/3/1 tuples=3
orgin->sink: org pre->post, reply pre->post dev=4->3/3->4 gwy=172.17.97.254/192.168.1.211
hook=post dir=org act=snat 192.168.1.211:49254->142.231.1.182:80(172.17.97.181:49254)
hook=pre dir=reply act=dnat 142.231.1.182:80->172.17.97.181:49254(192.168.1.211:49254)
hook=post dir=reply act=noop 142.231.1.182:80->192.168.1.211:49254(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=2 auth_info=0 chk_client_info=0 vd=0
serial=0001608f tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
As
an additional security measure, an administrator might consider
combining the first option (guest access) with the second one (custom
service).
This would assure that the guest access will be applied only for traffic outside the users' port range.