Bluecoat Layer Merge
FortiConverter is able to merge SSL intercept layer, authentication layer and forwarding layer in Bluecoat into the proxy policy list in FortiGate.
In Bluecoat proxy rules are separated into multiple layers, and each layer has different functions such as authentication, SSL intercept, web access and forwarding. A traffic needs to go through one layer to perform one function and go through the next layer to perform another function.
In FortiGate, those functions are performed by proxy policies and there is only one proxy policy list. When converting Bluecoat rules, FortiConverter first converts web access layers into proxy policies, then matches the proxy policies with other layers and applies the action of those layers into the proxy policies.
Currently FortiConverter supports the layer merge of SSL intercept layer, authentication layer and forwarding layer.
Specify web access layers by adding key strings
- SSL Intercept layer merge
- Authentication layer merge
- Forwarding layer merge
- The order of layer merge
Specify web access layers by adding key strings
To perform the layer merge, it is required to add the keyword "Web Access Layer" into the name of web access layers inside the config file. Since FortiConverter cannot always correctly identify web access layers in the config, it is needed to manually specify them in the layer name. For example:
Originally, the definition of web access layer name is:
;; Tab: [User WAL]
Please add the keyword "Web Access Layer" into the layer name:
;; Tab: [User WAL Web Access Layer]
When FortiConverter finds the keyword in the layer name, the layer will be marked as a web access layer.
SSL Intercept layer merge
Currently FortiConverter supports merging the SSL intercept rules with the setting ssl.forward_proxy(no) into proxy policies, and enable SSL SSH inspection for other policies. For example:
If there is a web access rule:
client.address=1.1.1.0/24 url.domain=" fortinet.com" Allow ; Rule 1
It would be converted into a FortiGate proxy policy like this:
config firewall policy
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "n-1.1.1.0_24"
set dstaddr " fortinet.com "
set service "webproxy"
set action accept
set ssl-ssh-profile "deep-inspection"
next
end
The SSL SSH profile will be set to "deep inspection" by default.
SSL Intercept layer merge - Full match
If an SSL intercept rule is defined for domain "fortinet.com":
url.domain=" fortinet.com" ssl.forward_proxy(no) ; Rule 1
Then the SSL intercept rule covers the whole web access rule, which is a full match, so no SSL SSH inspection should be performed on the proxy policy. Hence after merging the SSL intercept rule into the web access rule, the converted proxy policy will become:
config firewall policy
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1"
set dstaddr " fortinet.com "
set service "webproxy"
set action accept
next
end
set ssl-ssh-profile "deep-inspection" would be removed from the proxy policy.
SSL Intercept layer merge - Partial match
If the SSL intercept rule is defined like this:
client.address=1.1.1.1/32 url.domain=" fortinet.com" ssl.forward_proxy(no) ; Rule 1
In the SSL intercept rule, only client host 1.1.1.1 is used, but in the web access layer, the whole subnet 1.1.1.0/24 is used, so this is a partial match. In this case, the original rule would not be changed, but another proxy policy will be created before the original proxy policy:
config firewall policy
edit 50010001 --- The prefix "5xx" is added for new SSL intercept rules.
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1" --- The traffic of the SSL intercept rule.
set dstaddr " fortinet.com "
set service "webproxy"
set action accept
next
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "n-1.1.1.0_24"
set dstaddr "fortinet.com "
set service "webproxy"
set action accept
set ssl-ssh-profile "deep-inspection"
next
end
The first proxy policy is created with no SSL SSH profile because host 1.1.1.1 does not need SSL incept according to the SSL intercept rule. The second proxy policy is converted from the original web access rule, which needs to do SSL intercept.
The newly created proxy policies from SSL intercept layer merge would have prefix "5xx". For example, if three proxy policies from SSL intercept are created for proxy policy 10001, their policy names will be 50010001, 50110001 and 50210001.
Authentication layer merge
For authentication layer, FortiConverter supports merging the authentication rules into proxy policies, and adds the user group into the matched proxy policies.
The user group mentioned in authentication rule would be converted into a user group with prefix “Domain Users”.
For example, an authentication rule with:
authenticate(Fortinet) authenticate.force(yes)
will be converted into a user group called “Domain Users Fortinet”. A member “Fortinet” will be added into the group, but users need to check if the configuration needs to be modified.
If proxy policy matches with an authentication rule, the proxy policy will use the user group from the authentication rule. If there is already a user configured in the proxy policy, but it matches with a rule with authenticate(no), then the users inside the proxy policy will be removed.
An example of authentication layer merge:
For the web access rule (the same as the example in the previous section):
client.address=1.1.1.0/24 url.domain=" fortinet.com" Allow ; Rule 1
There is no user configured in the rule.
Authentication layer merge - Full match
If an authentication rule is defined for domain “fortinet.com”:
url.domain=" fortinet.com" authenticate(Fortinet) authenticate.force(yes) ; Rule 1
Then the authentication rule covers the whole web access rule, which is a full match, so the user group “Domain Users Fortinet” will be applied on the proxy policy. Hence after merging, the converted proxy policy will become:
config firewall policy
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1"
set dstaddr " fortinet.com "
set service "webproxy"
set groups "Domain Users Fortinet" --- the user group from the authentication rule
set action accept
next
end
Authentication layer merge - Partial match
If the authentication rule is defined like this:
client.address=1.1.1.1/32 url.domain=" fortinet.com" authenticate(Fortinet) authenticate.force(yes) ; Rule 1
In this rule, only client host 1.1.1.1 is used, but in the web access layer, the whole subnet 1.1.1.0/24 is used, so this is a partial match. In this case, the original rule would not be changed, but another proxy policy will be created before the original proxy policy:
config firewall policy
edit 60010001 --- The prefix “6xx” is added for new authentication rules.
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1" --- The traffic of the authentication rule.
set dstaddr " fortinet.com "
set service "webproxy"
set groups "Domain Users Fortinet" --- the user group from the authentication rule
set action accept
next
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "n-1.1.1.0_24"
set dstaddr "fortinet.com "
set service "webproxy"
set action acceptnext
end
The first proxy policy is created with the user group because only host 1.1.1.1 needs to authenticate according to the authentication rule. The second proxy policy is converted from the original web access rule, which does not need authentication.
The newly created proxy policies from authentication layer merge would have prefix “6xx”. For example, if three proxy policies from authentication layer merge are created for proxy policy 10001, their policy names will be 60010001, 60110001 and 60210001.
Forwarding layer merge
For forwarding layer, FortiConverter supports merging the forwarding rules into proxy policies, and adds the forward server into the matched proxy policies.
An example of forwarding layer merge:
For the web access rule (the same as the example in the previous section):
client.address=1.1.1.0/24 url.domain=" fortinet.com" Allow ; Rule 1
There is no forward server configured in the rule.
Forwarding layer merge - Full match
If a forwarding rule is defined for domain “fortinet.com”:
url.domain=" fortinet.com" forward("Fortinet") ; Rule 1
Then the forwarding rule covers the whole web access rule, which is a full match, so the forward server “Fortinet” will be applied on the proxy policy. Hence after merging, the converted proxy policy will become:
config firewall policy
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1"
set dstaddr " fortinet.com "
set service "webproxy"
set webproxy-forward-server "Fortinet" --- the forward server from the forwarding rule
set action accept
next
end
Forwarding layer merge - Partial match
If the forwarding rule is defined like this:
client.address=1.1.1.1/32 url.domain=" fortinet.com" forward(Fortinet) ; Rule 1
In this rule, only client host 1.1.1.1 is used, but in the web access layer, the whole subnet 1.1.1.0/24 is used, so this is a partial match. In this case, the original rule would not be changed, but another proxy policy will be created before the original proxy policy:
config firewall policy
edit 70010001 --- The prefix “7xx” is added for new forwarding rules.
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "h-1.1.1.1" --- The traffic of the forwarding rule.
set dstaddr " fortinet.com "
set service "webproxy"
set webproxy-forward-server "Fortinet" --- the forward server from the forwarding rule
set action accept
next
edit 10001
set type explicit-web
set explicit-web-proxy "web-proxy"
set dstintf "INTERNET"
set srcaddr "n-1.1.1.0_24"
set dstaddr "fortinet.com "
set service "webproxy"
set action acceptnext
end
The first proxy policy is created with the forward server because only host 1.1.1.1 needs to be forward according to the forwarding rule. The second proxy policy is converted from the original web access rule, which does not need to be forwarded.
The newly created proxy policies from forwarding layer merge would have prefix “7xx”. For example, if three proxy policies from forwarding layer merge are created for proxy policy 10001, their policy names will be 70010001, 70110001 and 70210001.
The order of layer merge
The order that FortiConverter merge the layers into proxy policies is: 1. SSL intercept layer, 2. Authentication layer and 3. Forwarding layer, and the merged policy list of the previous layer would become the input policy list of the next layer merge.
For example, if a proxy policy 10001 has one partial match to the SSL intercept layer, then the merged policy list will become:
50010001, 10001
Then this policy list will match with the authentication layer. If it is found that 50010001 has one partial match, and 10001 has two partial matches, then the created policies will be places just before the merged policies. The merged policy list will become:
60010001, 50010001, 60110001, 60210001, 10001
50010001 is the proxy policy created from 60010001, and 50110001 and 50210001 are created from 10001.
All these proxy policies will match with the forwarding layer. If there is one match with 5010001 and one match with 10001, then the merged policy list will become:
60010001, 50010001, 70010001, 60110001, 60210001, 70110001, 10001
After the layer merge, the proxy policy list becomes longer, but in this way, it approaches the behavior of the multi-layer rules configured in Bluecoat.