在Cyberoam中，是可以透過封鎖內對外的http及https，
來強迫使用者要掛proxy才能上網。




但在XG，我們來看看同樣的設定是否能達成強制使用者掛proxy的目的？

首先，確定80及443已在XG proxy的Trusted Ports清單之中。



然後，在policy中擋掉內對外的80及443服務，強制使用者掛proxy。



測試結果如下，
在擋掉內對外的80及443 port後，
內部使用者對外不論掛不掛proxy，都無法以80及443上網！

只有在放行內對外的80及443 port的情況下，把XG做為proxy掛載才能生效；
但這一放行，使用者掛不掛proxy都能上網...

在無法強制要求使用者掛proxy的情況下，那我幹麻掛proxy？
而且XG的proxy中也沒有設定網站黑白名單的功能，
只能透過內對外的web filter規則來過濾，
XG所謂的proxy，根本是假的...！



至少在V15版的韌體中是如此，這可是跟原廠確認過的喔...

********2017/01/02更新********
V16.01.2測試結果相同，Proxy功能一樣是假的...

之前老在抱怨XG上的proxy是假的，
昨天意外在 Community 上發現，要強制使用XG做為proxy還是有方法的！

在建立一條內對外，只放行TCP 3128 port的防火牆規則後，就可以實現這樣的需求。



而且Web Filter一樣可以套用；
可以透過Web Filter來進行所需的網頁類別限制。
看來之前抱怨的問題都不見了！？

不過在這條規則後面不要再加block HTTP/HTTPS的規則，
要由XG隱藏的0號預設規則來block才能觸發proxy機制。

若加上drop的block規則，開啟任何網頁都會出現XG阻擋頁面，無法實現direct proxy架構；
若加上reject的block規則，開啟任何網頁都會出現拒絕連線，無法連上網站的畫面。
官方解釋與解決方法，為在這block規則之前，再加上一條allow http/https的規則，並套用上Deny All的Web filter。

另外，關於開啟web filter造成軟體干擾的部分，在這種direct proxy模式下有可能會有些狀況。
例如在Line的例外放行上，順子之前測出來的結果是，
除了放行整理出來的FQDN與IP外，還要放行一整個203.104.150.0/24與203.104.153.0/24網段，
而Web Exception中， 接受的內容只有FQDN、IP與網頁類別，無法接受放行一整個網段的輸入設定。
在非proxy的架構下，我們可建立一條置頂的優先放行規則，放行一整個網段來達成目的；
但在proxy架構下，罝頂放行規則無法發揮作用，這部分順子還找不到解法！！

確定要用XG來做為direct proxy？
請再考慮一下...


參考資料
How can I set up web access via PROXY PORT only?

在V18之後，Sophos把原本隱藏的0號阻擋規則強制顯示了！
而這條規則在Direct Proxy的使用上又會造成什麼影響？
就讓順子來實測看看。



經實際測試，將可正常運作的V17 Direct Proxy升級到V18後，
原本user可以正常開啟的網頁，現在都打不開了！



原因就跟V17版一樣，當清單最後有一條阻擋http/https的規則時，
就必需在這阻擋規則的前面，加上一條套用Deny All的Web filter的http/https放行規則，
否則所有網頁都將無法正常開啟！





在預設阻擋規則前，加上Deny All Web filter的http/https放行規則後，網頁就可以正常開啟了，
不僅可以依照Proxy規則中的Web filter來進行網頁控管，
而且log中，也可以看到Proxy的Web filter log記錄。



而端點沒有掛上proxy，就無法打開所有網頁。



基本上V18的Direct proxy的設定就沒有太大問題了。
(除了那個整個目標網段無法在web exception中放行的問題無法解決以外...)


參考資料
Resolve issues related to web proxy when...l rule is added