FOS18: Access to webproxy (Direct Mode) does require allowing HTTP and HTTPS within firewall rule?

Question

Dear all, 
 in FOS17.5 we allowed access to the XGs webproxy on port 3128 by creating a firewall rule with allowing traffic from LAN to WAN with allowed service 3128 as documented in the following KB article: https://community.sophos.com/kb/en-us/125585 . 
 After migrating to SFOS 18.0.0 GA-Build379 this does not work anymore. When a LAN client accesses the webproxy on port 3128, no website can be opened and the connction on the client times out. In the XGs logfile I can see the following: 
 1. Traffic from the LAN client to the webproxy (3128) is allowed 2. Traffic from the XGs WAN interface to the destination website is dropped 
 When adding HTTP & HTTPS in addition to tcp/3128 in the firewall rule everything is working fine - that however means, that transparent proxying is also allowed. To disable the transparent proxy, I need to create an additional firewall rule with allowing HTTP & HTTPS from LAN to WAN with Web Policy set to deny as mentioned in https://community.sophos.com/kb/en-us/132117 . 
 My firewall rule for allowing access to the webproxy looks like the following: 
 
 Is this behavior normal in FSOS18 because of the new drop rule at the end, so that in addition to tcp/3128 HTTPs & HTTPs always have to be explicitly allowed in the firewall rule as well? 
 Thanks Michael

Michael Dunn · Accepted Answer

two last questions on this one. As port 3128 needs to be included in a firewall rule for allowing direct access to the webproxy of the XG: If I set the destination to Any Host this should also allow clients access to port tcp/3128 on other hosts on the Internet, correct? To restrict access to tcp/3128 ONLY to the XGs webproxy and enable HTTP/HTTPS over it I guess we have to create two rules: 
 1. One rule for port 3128 with destination set to the internal interface / IP address of the XG (allows access to web proxy) 2. Another rule for http/https to WAN and Any Host (allows http/https over webproxy) 
 
 Sounds correct. The QA in me says you'd have to test it to be sure.

Secone question: I noticed that if another protocol than HTTP/HTTPS over the webbroxy in Direct Mode needs to be used (like FTP), this protocol has to be added to the firewall rule as well - even though the general webproxy settings list other destination ports in its config as allowed: 
 
 However, unless FTP is not allowed in the firewall rule as well, FTP access over the webproxy does not work. Is this correct as well? As this is also misleading - the list from the screenshot above implies that once direct access to the webproxy over port 3128 is used, all ports listed are implictily allowed over it. 
 
 Again, sounds correct. However the list of ports here is not configuring the firewall, it is configuring the web proxy. This is the list of ports the web proxy will accept, rejecting anything on other ports. It is important security that the web proxy maintain its own list, as there are easily ports you might want to allow normal services on but you wouldn't want to allow HTTP on. 
 Take this request: 
 curl -x myfirewall:3128 http://www.example.com:1111/ 
 This tells the curl client to make a connection to myfirewall on port 3128, to speak HTTP, and to ask that proxy to make a connection out to port 1111. When myfirewall receives it on port 3128 it first tries to match it to a firewall rule that would tell it what web policy should be used. If it finds a firewall rule it hands the connection to the web proxy telling it which policy to use (if there is no firewall rule then it hands it to the web proxy telling it Deny All). It is important to note that 1111 is not involved here because that is data within the connection, part of the HTTP header, not the connection itself. The web proxy then looks at and parses the HTTP headers. It looks at its policy to determine the destination category is allowed or not. It also looks at its policy to determine if the destination port (1111) is allowed or not - this is the configuration you posted. If it isn't allowed then it sends back a block page saying it is a blocked destination. After the web proxy determines it is allowed it tries to make an external connection to that port (1111). The firewall now gets involved - is the XG allowed to make connections to that port. If the firewall allows it fine, but if the firewall does not the connection hangs open for 60 seconds before the proxy gives up and says the destination timed out (it has no idea that the firewall was the reason for the timeout, it just knows it never got a reply), and the proxy returns a error page to the client. 
 This scenario is also true if you do ftp to port 3128, in something called ftp-over-http. There is an extra process involved on the XG but the principal is the same.

Michael Dunn · Answer

I don't know iptables that well, so I personally don't think in those terms. 
 layer9 said: 
 
 1. Allowing traffic to port 3128 of the webproxy is configured in the firewall rule from LAN to the XG interface/port 3128 2. Allowing traffic to http/https form the webproxy to the Internet is configured in the firewall rule from LAN to WAN/port 80/443 [*] 3. Filter settings are derived from the web filter settings of a matching firewall rule 
 I'm however not sure at which step the rule for allowing web proxy access in Device Access comes into play. Maybe in step 3: If the webproxy receives packets on port 3128 (after the rule in step 1 has allowed them) it will actually not allow access if the checkbox for the corresponding source zone in Device Access is not set. 
 
 When a packet arrives at an interface the XG can ignore it (eg "closed port") or it can look at it and send it to the firewall to be processed. This is what the Device Access controls. If the packets arrives on a port and the port is WAN then "Web Proxy" is unchecked and the packet is ignored. If it arrives on LAN and Web Proxy is checked, it is sent to the firewall which looks at its rules and may send it to the proxy or may choose to ignore it. Note: what matters is the zone of the port the packet arrives at, not the zone of the port the packet is addressed to. 
 layer9 said: 
 [*] I guess what caused confusion to me is that the rule from step 2 (outgoing http/https access from webproxy to the Internet) does not indicate that it is also used as an "OUTPUT" rule (from an iptables perspective) for local outgoing connections from the webproxy as well. For that I would have expected that we have to configure the rule with source zone WAN and source network as the external interface of the XG (as that is used from the webproxy for outgoing connections to the Internet). 
 
 In 17.5 and earlier you did not need to configure a rule, the "default drop rule" was not applied to internal->WAN connections. You only needed a rule allowing 80/443 if there was an explicit Drop All rule. It appears that in 18.0 it is now needed all the time, likely due to some system hardening. When I get time (haha) I'm retest and update the KB ( https://community.sophos.com/kb/en-us/132117 ).