Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 27 subscribers
  • Views 2503 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FOS18: Reject Rule is allowing traffic

layer9

Dear all,

I have just experienced a very strange issue in our XG running 18.0.0 GA-Build379. I have the two rules in place:

Rule 5: Allows HTTP & HTTPS from LAN to WAN
Rule 6: Log and Reject all traffic from LAN -> WAN and vice versa

1. When configuring the XG as explicit webbrowser on my client (xg:3128) I can access websites in WAN even though rule 5 does not allow tcp/3128 as service
2. Even more strange: The aforementioned access only works with rule 6 (Reject) being enabled!

You can see here in the logs that rule 6 is the one that allows access from the client to the webproxy on the XG - even though rule 6 has reject as action!!

If I disable rule 6 the client cannot access the webproxy anymore. The same happens if I change the rule action in rule 6 from Reject to Drop...

Any ideas?
Best Regards
Michael



This thread was automatically locked due to age.
Parents
  • 0

    That a taff question... 

    So there is the standard proxy, which will take traffic depending on the Rule in Device access. 

    The standard proxy (port3128) will accept the traffic, because Device Access allowing this one on the Port(Zone). 

    But the Firewall Rule will actually notice, there is matching traffic, what should i do? 

    As the Firewall Rule is likely hitting, the log viewer notice this one and put it into place as "Hey there was firewall traffic, which is hitting your rule, but i have to allow it, because of Device access".

    That is the "issue" here. 

    This issue will be resolved in a future version, whenever the Default Drop rule is able to log the dropped traffic. There are feature request to protocol this traffic. 

     

    Another point is: The Proxy in XG is both: Transparent and Standard at the same time. Therefore if you have HTTP/HTTPs enabled, you can actually communicate with the XG via Port 3128.

    Its the same like UTM. The Transparent proxy allows you to communicate with Port 8080. 

  • 0 in reply to LuCar Toni

    Hi Toni,

    thanks for your answer to this one as well. However, actually I'm not sure if I can follow you or if the situation you describe is actually the issue here. 

    But the Firewall Rule will actually notice, there is matching traffic, what should i do? 

    I guess you mean that the reject-all firewall rule matches because it basically set to Any-Any? In that case you could be right in that the HTTP/HTTPS traffic actually matches that rule. It might also be that the log viewer then handels as you describe and inadvertently reports this traffic as allowed.

    But I have another mysterious one: If I change the rule from REJECT to DROP, access to the web proxy stops working and the log viewer does not report those false positives anymore. Once the rule is set to drop, the behavior is exactly the same as when configuring a web proxy rule with http/https only but not specifying port 3128 (basically the issue from my other thread!).

    In generall it currently still seems to me that all the issues I reported have to do with the drop/reject all rule at the bottom, either the new default one from v18 or a manually created one.

    If someone from Sophos is interested in debugging with me I'm happy to help (I'm from Germany btw.).

    Best Regards
    Michael

  • +1 in reply to layer9

    Generally speaking it is hard to explain, what is happening here.

    As the proxy creates some sort of "own connection" , you are actually able to drop / reject the proxy own sessions.

    Thats the reason you are able to "destroy" your setup by configuration of a drop rule. The Traffic will not reach the Proxy, as the firewall will drop the traffic before reaching the proxy. 

     

    The "default drop rule 0" on bot on XG is simply a visibility tool. It shows the administrator, there is a deny, if no rule is matching. 

    Down side of this rule: There is no logging for traffic, which does not meet any firewall. So default drop is not logged. 

  • 0 in reply to LuCar Toni

    Thanks Luca, I guess I'll just leave it at that and remove the manually created drop rule as I don't think it's a good idea to use it in case of such strange effects. I'm rather waiting for Sophos to add logigng to the default drop rule then.

    Best Regards
    Michael

Reply
  • 0 in reply to LuCar Toni

    Thanks Luca, I guess I'll just leave it at that and remove the manually created drop rule as I don't think it's a good idea to use it in case of such strange effects. I'm rather waiting for Sophos to add logigng to the default drop rule then.

    Best Regards
    Michael

Children
No Data