Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Parents
  • I have a problem with firewall rules. Since I upgraded from 19.0 GA to 19.0 MR1, my WIFI rule is not working anymore, nothing is let through. No ping, no TCP connection from LAN zone to WIFI zone:

    As you can see, 0 bytes sent/received. When I switch back to 19.0 GA it all works again and counters go up. I have no explanation why this is happening, any idea where to look for in the logs?

    Edit: Same seems to be the case for Rule #11 SMTP.

  • Why do you use a rule without Logging? 

    Check the packet capture - There you should see the used Firewall/NAT Rule. 

    Maybe another rule picks up the traffic. Automatic VPN Rule is something, which could potentially cause issues. 

    __________________________________________________________________________________________________________________

  • What kind of appliance is this? Is wlnet1 a internal Wireless? 

    __________________________________________________________________________________________________________________

  • Its a Home Edition on a Intel based 4-Port Barebone. No internal wireless. The network 10.0.2.0/24 is the network configured on wireless APX120.

  • It is indeed odd. Looks like something is not rendering your policy. Rule 0 is simply default drop, therefore you do not see anything in Logviewer. If you already recreated the zone, what i could potentially suggest: 

    Try to re save the IoT Zone. See if you can save the wireless zone or if there is any error. 

    Then check the policy tester in logviewer, does it give you the same result or rule 32? This will lead to the next steps. 

    __________________________________________________________________________________________________________________

  • No luck. I tried saving the wireless IoT network, the WiFi zone, all without problem.

    Then I even tried to set the rule "LAN to WIFI"  Any,Any, to Any,any.

    Still the same. All networks and rules are properly evaluated, just this WiFi network is not.

    I will try the policy test with 19.0GA

    in 19.0 GA it is working and picking the rule:

  • That is very odd. Try to change the Zone of Wifi to something else. Does the Policy test work? 

    In any case, feel free to give me the Access ID (Support access) via DM. I will try to reach out to somebody to check this. 

    __________________________________________________________________________________________________________________

  • OMG. Now as I recreated the zone on 19.0 GA I have the same issue!

    I could finally resolve it by deleting the wireless network including its DHCP range, and do it from scratch.

    Then a new firewall rule and it starts working and is accepting.

    So I was hopeful to try the same thing on MR1, but unfortunately this didn't do the trick. So it really seems something has changed regarding wireless routing (as in separate zones, bridging is working).

    I will send you the access ID.

  • Why do you use a rule without Logging? 

    Lucar? The more important question is: Why is "log firewall traffic" not checked by default?

  • It is per design not enabled. If you want Default Drop logged, you can create a own Rule, which does this for you. You cannot enable Default drop logging. docs.sophos.com/.../index.html

    __________________________________________________________________________________________________________________

  • It is per design not enabled. If you want Default Drop logged, you can create a own Rule, which does this for you. You cannot enable Default drop logging. docs.sophos.com/.../index.html

    It is not about logging default drop.. it is about creating a new firewall rule and having to enable logging every time... Why could sophos not check the "log firewall traffic" per default? it makes absolutely no sense to leave it unchecked...

  • It is quite simple. The rule you see is is not a actual firewall rule, which could be potentially be edited. It is simply a placeholder to present to the admin, there is a default drop in place. It is not like this rule actually exists within the system. Default drop is a rule within the system and cannot be edited at this time of being. So you cannot "simply add logging to this rule", as there is no rule. Default drop is a principle, which the core system does, if there is no rule in the first place. So there is no logging enabled in this scenario. If you want to have a logging, you can do this by your own by creating your own rule. 

    To enable the default drop logging per default is something on the roadmap for a future release, but there are other items, which are more compelling than revamping the default dropping due the fact, you can simply enable this by using your own rule. 

    __________________________________________________________________________________________________________________

Reply
  • It is quite simple. The rule you see is is not a actual firewall rule, which could be potentially be edited. It is simply a placeholder to present to the admin, there is a default drop in place. It is not like this rule actually exists within the system. Default drop is a rule within the system and cannot be edited at this time of being. So you cannot "simply add logging to this rule", as there is no rule. Default drop is a principle, which the core system does, if there is no rule in the first place. So there is no logging enabled in this scenario. If you want to have a logging, you can do this by your own by creating your own rule. 

    To enable the default drop logging per default is something on the roadmap for a future release, but there are other items, which are more compelling than revamping the default dropping due the fact, you can simply enable this by using your own rule. 

    __________________________________________________________________________________________________________________

Children