Technical Tip: Specific different FQDNs are unreachable on Web Proxy

[MigenaM]

Description	This article describes the behavior behind different FQDNs not being reachable when a Web Proxy is being used.
Scope	FortiGate.
Solution	Depending on the network requirements, there are cases in which different VMs cannot communicate with specific applications to get the required updates to correctly function. In this scenario, some packages need to be downloaded while an Explicit Web Proxy is being used. An example of the firewall policy and web proxy created for this traffic is added below: edit 45    set uuid 510f5674-3dc6-41ef-97e6-0869c0a76606    set proxy explicit-web    set dstintf "Destination_Test"    set srcaddr "10.47.111.98" "47.111.99" "47.111.100" "10.47.111.0/24"    set dstaddr "fqdn-code.test.com" "fqdn-test.test.com" "fqdn-*.customapplication.com" "fqdn-automationsuite.test.com"                "fqdn-test.dev.azure.com" "fqdn-gallery.customapplication.com"     set service "CustomSOCKSService"    set action accept    set schedule "always"    set logtraffic all next config firewall service custom    edit "webproxy"         set proxy enable         set category "Web Proxy"         set protocol ALL         set tcp-portrange 0-65535:0-65535    next    edit "CustomSOCKSService"         set proxy enable         set category "Web Proxy"         set protocol ALL         set app-service-type app-category         set app-category 6         set tcp-portrange 0-65535    next As visible, the custom profile created has the range of ports '0-65535', and the default profile '0-65535:0-65535'. The behavior noticed in these cases, is that the traffic does not hit the policy with the custom profile enabled, but another policy below that has the 'webproxy' service specified. The errors seen on the wad debug logs will usually look like this: __wad_http_build_replmsg_resp :632 Generating replacement message. 407 error repmsg_id 1102426.853: 4 __wad_http_build_replmsg_resp :632 Generating replacement message. 407 error repmsg_id 102426.853: 14 In this scenario, to mitigate the issue, the default service profile 'webproxy' can be used. The issue seems to be related to the custom service that has a few more options enabled in comparison to the default one. The 'CustomSOCKSService' configuration specifies an application category (6) for the service, which may have specific implications or restrictions based on the defined category. By setting the app-service-type to app-category, the custom service is essentially associated with a specific application category, which helps in organizing and managing firewall policies effectively based on the type of applications being used. The issue might be related to different FQDNs or different services used in policies.