updated subject: Creating outbound rule silently creates mirrored inbound rule

Comments

34 comments

  • Avatar
    Firewalla

    Have you tried the target list?  https://help.firewalla.com/hc/en-us/articles/1500005941962-Firewalla-Feature-Target-List-Beta-

    With this feature, you can group multiple IP address (or domain) together and then allow/block them.

    0
    Comment actions Permalink
  • Avatar
    mobius strip

    @Richard

    If I understand correctly, you want to create an Allow rule exception for a device A on VLAN1 to reach/contact (i.e. print) to a device B on VLAN2 (a printer).
    This Allow rule is an exception to another 2 rules you have previously created, in which you have:

    • Blocked all traffic from from all devices on the network tagged with VLAN1 to all devices on the network tagged with VLAN2
    • Blocked all traffic from from all devices on the network tagged with VLAN2 to all devices on the network tagged with VLAN1

    If so, I think you had the right idea in how you went about creating your allow exception rule, but I believe you got the rule structure/logic backwards…

    I personally find that the logic of the rules creation interface in the Firewalla app to be a little confusing/unintuitive in this specific scenario of creating a granular rule from one specific device to another device on another subnet VLAN, because the firewall logic on most other networking gear that I happen to have gotten used to using before using the FWG lists the logic of their firewall rule creation interface in reverse order with respect to the source and destination (I say this about the Firewalla app with sincere respect of course):

    So on the FWG when creating a source device to destination device rule across VLAN’s, I have to remind myself:

    • Think of the ‘Target’ parameter as the ‘Destination/To’ device
    • Think of the ‘Apply To’ parameter as the ‘Source/From’ device


    In contrast, nearly all of the visual interfaces for firewall rule creation that I’ve seen on other networking gear is structured in largely reversed order and with field names:

    Rule Name:
    From/Source: {network(s), IP address(es), MAC address(es), All/Any, SSID(s), predefined network & user lists, etc}
    From/Source Port(s): {fill in list, All/Any, etc}
    Protocol: {dropdown list items including, All/Any, etc. }
    To/Destination: {network(s), IP address(es), MAC address(es), All/Any,SSID(s), predefined network & user lists, etc}
    To/Destination Port(s): {fill in list, All/Any, etc}

    (and other options like enable/disable, logging)


    This is more intuitive to me, personally, but other users may feel differently, of course.

    If I misunderstand you though, apologies in advance, and:

    • In addition to the Firewalla staff’s answer above this reply, does this support page about rules answer your question?:   https://help.firewalla.com/hc/en-us/articles/360008521833-Manage-Rules
    • If you care to rephrase your question otherwise so I can better understand what problem you’re running into, I can try to help out, I’d be happy to give it a shot.

     

    0
    Comment actions Permalink
  • Avatar
    Richard

    thanks so much for the detailed reply, very much appreciated! and yup, you nailed it, the thing i was expecting to be able to do was select a "target" as a known device to firewalla, and an "apply to" as a known device to firewalla, but the "target" has to be a domain / ip, while the "apply to" can be a known device. This makes sense for setting up rules for devices that apply to external access, but becomes a bit of a work around when setting up x-vlan rules, as one side (that firewalla is aware of all the devices on) has be configured at an IP address level, instead of a device level, which i can make work, it just means I have to reserve the IP address and hunt for it as im setting up the rule. Thinking about it, my feedback is more about the UI than the functionality i guess :) and 100% agree with your reverse approach to it compared to other vendors, not that its bad, but it does need a bit of brain re-wiring.

    0
    Comment actions Permalink
  • Avatar
    Support Team

    @mobius, 

    Thanks a lot for supporting us. 

    Here is something we'd like to clarify, you mentioned in your comment: 

    So on the FWG when creating a source device to destination device rule across VLAN’s, I have to remind myself:

    • Think of the ‘Target’ parameter as the ‘Destination/To’ device
    • Think of the ‘Apply To’ parameter as the ‘Source/From’ device

    It is not exactly the case.

    Most of the rules on Firewalla are designed to be bi-directional. So if you set a rule, say, to block target IP Address A, apply to Device B, it will block the connection between A and B. It basically means you've created two traditional firewall rules:

    From/Source: Device B,
    From/Source Port(s): Any
    Protocol: Any
    To/Destination: IP Address A
    To/Destination Port(s): Any
    From/Source:  IP Address A,
    From/Source Port(s): Any
    Protocol: Any
    To/Destination: Device B
    To/Destination Port(s): Any

    Distinctively, in router mode, Firewalla supports choosing direction when the target is "Local network" and "Internet". If you set a rule to block "Traffic from LAN A", apply to "LAN B", or block "Traffic to LAN B", apply to "LAN A", it will only block traffic from A to B, but not vice versa. 

    Sorry for the confusion. We'll keep improving the UI to make it more intuitive. 

     

    @Richard, 

    If you'd like to allow Device A to access Device B, then you're doing it correctly. If your devices have served IPs, both rules below will serve the same purpose: 

    • Allow, Target: IP address of Device A, Apply to Device B. 
    • Allow, Target: IP address of Device B, Apply to Device A, 

    Please be aware that when the rule is set, Device B will be able to access Device A as well. 

    In addition, to be able to set "device" as the target is already on our to-do list. Thanks for the feedback. 

    0
    Comment actions Permalink
  • Avatar
    Chris Thomas

    @Firewalla Support Team

      Wait, why are you (firewalla) creating bi-directional rules by default?  If I allow my laptop to a server, I don't automatically want the server to have access to my laptop. 

    1
    Comment actions Permalink
  • Avatar
    Chris Thomas

    @Firewall Support Team,

      Is this use of 'bi-directional' rules documented?  I do not recall reading about this..  

     

    Results of my testing;

    1) Network level 'Permit to LAN' rules do not appear to be bi-directional
    2) Device or Group level rules without a port appear to be bi-directional
    3) Device or Group level rules with a port defined, do not appear to be bi-directional

     

    Setup

    server resides in SERVER_NET
    workstation resides in WORKSTATION_NET

    SERVER_NET has rule to 'Block traffic to all local networks'
    WORKSTATION_NET has rule to 'Allow traffic to all local networks'


    ===========================================================

    Scenario #1 - Add rule to permit workstation to server by fqdn


    RULE ENABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:15 Eastern Daylight Time
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.0029s latency).
    Not shown: 997 filtered tcp ports (no-response)
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 5.44 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:15 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0036s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 18.61 seconds


    RULE DISABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:18 Eastern Daylight Time
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.0097s latency).
    Not shown: 999 closed tcp ports (reset)
    PORT STATE SERVICE
    53/tcp open domain

    Nmap done: 1 IP address (1 host up) scanned in 2.17 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:18 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0044s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 18.48 seconds


    ===========================================================

    Scenario #2 - Add rule to permit workstation to server by fqdn+port (443) -- unused port


    RULE ENABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:21 Eastern Daylight Time
    Stats: 0:00:02 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
    SYN Stealth Scan Timing: About 53.75% done; ETC: 17:21 (0:00:02 remaining)
    Stats: 0:00:02 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
    SYN Stealth Scan Timing: About 53.83% done; ETC: 17:21 (0:00:02 remaining)
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.017s latency).
    Not shown: 999 closed tcp ports (reset)
    PORT STATE SERVICE
    53/tcp open domain

    Nmap done: 1 IP address (1 host up) scanned in 2.71 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:21 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0054s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 18.51 seconds


    RULE DISABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:23 Eastern Daylight Time
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.026s latency).
    Not shown: 999 closed tcp ports (reset)
    PORT STATE SERVICE
    53/tcp open domain

    Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:24 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0046s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server




    ===========================================================

    Scenario #3 - Add rule to permit workstation to server by fqdn+port (3389) -- used port


    RULE ENABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:27 Eastern Daylight Time
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.019s latency).
    Not shown: 999 closed tcp ports (reset)
    PORT STATE SERVICE
    53/tcp open domain

    Nmap done: 1 IP address (1 host up) scanned in 1.89 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:27 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0034s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 18.47 seconds


    RULE DISABLED

    user@server>nmap 192.168.26.169
    Starting Nmap 7.92 ( https://nmap.org ) at 2021-09-13 17:29 Eastern Daylight Time
    Nmap scan report for workstation (192.168.26.169)
    Host is up (0.034s latency).
    Not shown: 999 closed tcp ports (reset)
    PORT STATE SERVICE
    53/tcp open domain

    Nmap done: 1 IP address (1 host up) scanned in 1.77 seconds


    user@workstation>nmap 192.168.25.144
    Starting Nmap 7.80 ( https://nmap.org ) at 2021-09-13 17:30 Eastern Daylight Time
    Nmap scan report for server (192.168.25.144)
    Host is up (0.0051s latency).
    Not shown: 995 filtered ports
    PORT STATE SERVICE
    53/tcp open domain
    135/tcp open msrpc
    139/tcp open netbios-ssn
    445/tcp open microsoft-ds
    3389/tcp open ms-wbt-server

    Nmap done: 1 IP address (1 host up) scanned in 18.64 seconds




    ===========================================================

    Result;

    1) Network level 'Permit to LAN' rules to not appear to be bi-directional
    2) Device or Group level rules without a port appear to be bi-directional
    3) Device or Group level rules with a port defined, do not appear to be bi-directional

     

    This needs more testing... 

    If I write Device/Group level rule to a domain and leave off the port, Firewalla is creating a bi-directional firewall rule?!? 

    Does this override the 'Default Block' for WAN Interface?

    for IPv4, without a NAT this not as catastrophic, but with IPv6.... 

    Is Firewalla allowing traffic sourced from that domain (or resolved IPs?) to my IPv6 address on all ports?

     

     

    1
    Comment actions Permalink
  • Avatar
    Chris Thomas

    Yes, it does override the default block from Internet

     

    Port scan my laptop's IPv6 address from ipv6scanner.com

     

    If I write a rule to permit my laptop to domain ipv6scanner.com (no port) ... 

     

    This appears to also be true if you use matching 'IP Address' or 'Target Lists' with an IP Address or Domain.. (Adding port appears to make it unidirectional)

    2
    Comment actions Permalink
  • Avatar
    mobius strip

    @Support Team Firewalla

    Most of the rules on Firewalla are designed to be bi-directional. So if you set a rule, say, to block target IP Address A, apply to Device B, it will block the connection between A and B. It basically means you've created two traditional firewall rules:


    Respectful observation & suggestion:

    Observation
    While personally I’m a little surprised and I would very very much rather have the more granular control with explicitly stated directionality like in traditional firewall rules, in the greater context of the general discussion here on how to create firewall rules on the FWG that match the user’s intended effect, it seems like automatically modifying most user-defined firewall rules to be inherently bi-directional may be a case of a simplifying UI design choice(s) unfortunately having the unintended and opposite effect of introducing greater complexity?

    This is said in respectful recognition of the fact that designing a UI that works intuitively for such a broad base of users, including those all of those who have little to no previous exposure with anything related to networking at all must pose an ever-present set of challenging design considerations for your team, in that many of these considerations are trade-offs between user accessibility and granular user options.


    2 Suggestions as possible solution in UI when creating a firewall rule (if the bi- directional nature of rules is going to remain in place)

    • A toggle on/off option so one can choose to not automatically create a complementary rule that would make the user-defined rule bi-directional
    • User clicks/taps on ‘Advanced Mode’ to show more granular options, including something like the toggle above

     

    Common use case:

    • A designated device or IP address or Mac address corresponding to a computer on VLAN 10 should be able to contact a printer on another VLAN 11 by its IP, but in  accordance with the basic concept of least privilege, the printer does not need to and there should not be able to initiate connection to any device on VLAN 10. The automatic bi-directional rule creation Will override an existing currently possible 1-way blocking rule from VLAN 11 to VLAN 10 (one may also want to customize for situations as well in order to be able to use mDNS forwarding or reflecting for AirPrint capability as an exception to a 1-way blocking rule from VLAN 11 to VLAN 10 should bi-directionality will be optionally user-disabled in the futur… unless these rules don’t block this multicast IPv6 traffic )
    • A designated device or IP address or Mac address corresponding to a computer A on VLAN 10 should be able to contact a another computer on VLAN 12 by its IP in order to remote desktop, ssh, etc into it (E.g. from your laptop computer A in the living room to your desktop computer B in the home office), but computer B on VLAN 12 does not need to, and therefore should not be able to, initiate connection to computer A on VLAN 10.

    If I understand correctly in your response above, the only typical LAN-LAN One way firewall rule is when you create a rule from one network to another network?

    Sorry for the confusion. We'll keep improving the UI to make it more intuitive. 

    Development progress has been at quite an admirable rapid pace! 
    E.g. lots of advanced features such as wireguard, Sd-wan, your mdns forwarding javascript-based/non-Avahi implementation, and many more things work well and successfully designed as very easy to use  :)

     

    1
    Comment actions Permalink
  • Avatar
    A M
    Yes, it does override the default block from Internet

     

    Am I reading this correctly that if I create a rule for a device that says a device can reach a specific website (say MusicService.com), the FW will open up and expose a port rather than just allowing the outbound connection and inbound replies to the established connection?

    0
    Comment actions Permalink
  • Avatar
    Support Team

    @A M,

    When creating a rule to allow a site, both inbound and outbound connections with this site will be allowed by firewall, and no port forwardings are created by the rule.

    1. For IPv4, because there is NAT, inbound connections will still fail if there is no port forwarding created beforehand. And if a port forwarding is created (as a separated action in app), the site will be able to access the mapped device only via the port.

    2. For IPv6, there is no NAT by default, so inbound connections will be able to reach the device when the rule is created.

    0
    Comment actions Permalink
  • Avatar
    Richard

    wow. this started as what i though was a UI annoyance, and turned into a security hole? how have you guys not made this ABUNDANTLY CLEAR, that by creating an outbound rule you are also mirroring it as an inbound rule? If you've switched off IPv6 its less of hole but if you've not turned if off then wow... you just unwittingly opened up your network to the domain you created the outbound rule for? Doing this between VLANs quietly is a terrible idea, but doing it to the internet? Not \making this front and center in big bold flashing text in your docs is a massive miss and I have no idea why anyone thought this was ever a good idea for a.... firewall device... 

    0
    Comment actions Permalink
  • Avatar
    Firewalla

    @richard, are you talking about the "allowed rules"? the allow rules are exceptions, they are given to the site / IP / category, so they are bi-directional. In general, we do not recommend using many of the allowed rules, since they can be pretty broad. I think this is documented somewhere, I just need to dig for it.

    Chris was nice enough to create a ticket, and I think someone promised to look into his request. I have forwarded your concern as well to our developers. 

    I will escalate this to our development team tomorrow and see if they can implement directional allow feature in the next release. (should have something within 30 days to get early access). If I do not report back, consider it approved. 

    1
    Comment actions Permalink
  • Avatar
    Richard

    Thanks, but the fact you need to dig for it is the point, and that you create silent inbound rules is honestly amazingly bad practice for a security product, regardless of whether you recommend creating allow rules or not. There should be some big "Are you sure you want to do this, you are about to expose device X to the internet from domain / IP if you are running IPv6" warning. Its baffling to me. Can you imagine someone like Cisco, Juniper, Palo Alto silently creating inbound rules when someone created an outbound rule? I know you're in the consumer / prosumer space but there is no excuse I can think of where doing this, without so much as a warning, would be a reasonable thing to do... I guess the question is what was the logic you had in mind where this was ok? what scenario were you trying to make work that didn't have the quite obvious downside of quietly exposing the devices we have paid you to protect to the internet? I'm super disappointed because I love your stuff, i backed your Blue on kickstarter... but the whole premise of a firewall is that you trust it.... and "if you don't hear back were going to fix it" approach really doesn't feel ok to me, or the probably thousands of people that are unknowingly exposing goodness knows what with heck knows who...

    0
    Comment actions Permalink
  • Avatar
    Firewalla

    Well, when we designed the allow feature, we did ask a few users and see if they understand the meaning of it. If they don't see any directional verbs, will they consider that ingress or egress ... or both. 

    Anyway, what you all raised is a valid feature request, and likely useful, as I said, I am going to push for a directional allow feature and hopefully, we can early access it in 30 days.

    1
    Comment actions Permalink
  • Avatar
    Andy

    As others have stated here, this is a big security hole!

    I had noticed I was getting alerts for something scanning a device that has internet access, but the thought of having a rule to block incoming would block that traffic was wrong.

    I know you stated the hope this will be fixed within 30 days, and the Firewalla team is very receptive to changes, but this one is a big deal.

    1
    Comment actions Permalink
  • Avatar
    A M

    @Firewalla and everyone else, thanks for helping me begin understanding the underlying logic of this firewall.

    That said, I do need to echo the concerns being brought up. As someone looking to purchase this product (vs finishing setting up OPNSense, which I'm very much procrastinating on), in no uncertain terms, I think addressing this should now be your number one priority. Like pants on fire priority. Like why are you asking a user to put in a feature request rather than calling an all hands on deck meeting? 

    While I very much understand the case for "keeping it simple", the FWG is supposed to be a firewall. Sure it does many other things but one core function is to be a firewall. Automatically, without warning, explanation or option to not do so, opening both ends of a a relationship between a source and a destination egregiously goes against what a firewall is supposed to do. Sadly, this introduces uncertainty in a product I'm supposed to feel really good about (it's supposed to be a "security" product). Like what other design choices have been made that create unnecessary exposure/risks (aside from unintentional bugs and stuff that does happen)?

    Your number two priority should be to create an advanced user page (or something like that) where you explain in exhaustive detail how the firewall rules work, disclose any behind the scenes / automatic functions, etc. and explain implications of design/automation choices. These two items will help restore confidence in the product.

    Anyway, I hope I'm not sounding too harsh but I REALLY want to buy the FWG. Pleeeeease, fix this and take my money!

     

     

     

     

    1
    Comment actions Permalink
  • Avatar
    Firewalla

    @AM @Andy Let me forward your concerns as well. And see if we can get the "directional allow" to early access in 7 days. Our team is customer-driven, so thank you for the feedback. 

     

     

     

    2
    Comment actions Permalink
  • Avatar
    1980cyber

    Maybe it is just me, I have no problems understanding the current user interface is two-way. some user interfaces do identify direction with from and to, which is also clear. 

    But, having allow feature to tag with direction is definitely a good thing to do. Maybe you can do it like allow both, and allow to the internet. 

    And thank you for listening! Love you guys!

    0
    Comment actions Permalink
  • Avatar
    Richard

    and my advice to all current owners until this is fixed would be to check your rules and remove any that aren't absolutely necessary / you 100% trust the "target", then turn off iPv6 on your "WAN Connection" (Network / Your ISP network / Edit / Toggle IPv6 to off), and then check your NAT settings (Also in the Network page) and if there is anything in Port Forwarding make sure you know what it is and are happy that it is there (oh and while you are in the Port Forwarding page, unless you very intentionally turned UPnP on, turn it off / check it is switched off)

    1
    Comment actions Permalink
  • Avatar
    Firewalla

    If you are doing port forwarding, you can also lock it down this way 

    https://help.firewalla.com/hc/en-us/articles/1500009502622-How-to-limit-access-to-open-port-or-port-forwarded-

     

    0
    Comment actions Permalink
  • Avatar
    A M

    @Firewalla - all the positive comments on forums regarding your customer engagement and responsiveness are well deserved. In light of your response above, I just put my money where my mouth is and ordered a FWG. Looking forward to being part of the community.

    1
    Comment actions Permalink
  • Avatar
    A M

    @1980cyber - Now that I have read the instruction pages and many posts that provide additional context, yes I get how this works; I agree that this is disclosed. Speaking for myself, my confusion stemmed from the fact that this is not a behavior I have seen in other firewalls I've played with. My mind simply had a hard time reconciling how the current rule structure was able to have a desired effect (allow only "one way traffic" - well, they can't). Also, for me, the high-ish level instructions also created more questions. I do still feel that an in-depth discussion of what happens automatically for each type of allow/block rule (like for region, VLAN to VLAN, device to VLAN, etc.) would be desirable. Again, I love the simplification but that also seems to have carried some non-standard or unexpected behaviors that should be explained by more than what amounts to a foot note.

    0
    Comment actions Permalink
  • Avatar
    Chris Thomas

    I agree that it was 'disclosed' ..  but only barely, three simple words in a set of brackets, on a 10-page article.  I completely missed it reviewing the documentation, and didn't run across it during my initial testing because I only validated the efficacy of the blocks between my major networks.  I did not perform bi-directional testing on individual flows as I began to open more specific rules.  (Obviously the outbound flow was working correctly).

    That said, stateless firewalls haven't really been used in over two decades, and Firewalla being a statefull firewall, has no need to open bi-directional rules by default, or even support them.  Individuals should have to specifically create an inbound rule on WAN Interface to allow traffic into their network.

    I still see organizations who have language for bi-directional firewall rules in their firewall change request processes, or have vendors tell me that their application needs the following ports opened 'bi-directionally', which is almost NEVER the case.  The term 'bi-directional firewall rule' should stricken from use as ninety-nine percent of the time, it's inaccurate and introduces unnecessary risk and confusion.

     

    Regarding the current situation.  Simply updating your 'IP Address' or 'Domain' rule to include a port appears to result in Firewalla creating a unidirectional rule.

    i.e.

    Change

    action ALLOW matching DOMAIN "ipv6scanner.com" on DEVICE "Laptop" schedule ALWAYS 

    to

    action ALLOW matching DOMAIN "ipv6scanner.com:443" on DEVICE "Laptop" schedule ALWAYS 

     

    You'll want to update TARGET LISTS as well.

     

    1
    Comment actions Permalink
  • Avatar
    Chris Thomas

    https://help.firewalla.com/hc/en-us/community/posts/4405028934931

    There is already a Feature Request opened regarding the bi-directional rules; UP VOTE!

    1
    Comment actions Permalink
  • Avatar
    mobius strip

    There is already a Feature Request opened regarding the bi-directional rules; UP VOTE!

    @Firewalla Support Team

    Does this request cover the ability to choose the direction of a firewall rules between 2 different VLANs?

    I get an intuition that adding to the confusion here is The following which can be cleared up, please do correct me if I’m wrong:

    1. A typical firewall is a stateful firewall for traffic between LAN(s) and WAN(s).
    2. A ttypical firewall can be thought of as stateless for traffic between any LAN/VLAN and another VLAN, so these rules are inherently one-way (Some comments here and at the link in the reply directly above mine suggest that firewalls between local networks are stateful, which as I understand it is rarely the case.). (Edit: technically actually it is stateful and ACL rules are stateless in nature, but for most practical purposes/simplicity one can think of it as stateless firewall rules between local networks)


    With respect to the community request, I’d like to double check to make sure that it’s clear that 
    For (1.):

    • The community request here is to no longer create a reverse inbound allow rule from WAN to LAN (if true) because such an inbound rule is rarely required by user, unless the user is posting a web server or something like that.
    • The user may commonly want to have a default block all outbound traffic For his IOT devices on VLAN 20, and create and allow exception for say, all stateful traffic/traffic requested by the device from wemo.com or whatever in order to allow those devices to get updates. Creating such an allowed role should not automatically allow all unsolicited traffic back in without the user explicitly asking for such a rule be created, and the need for this should be pretty rare.

    For (2.):

    • The community request here is to no longer automatically create a reverse allow rule from destination IP on VLAN X to source IP (if true) on VLAN Y or to allow user to opt out of it.
    • Users should be encouraged to not create such a reverse bi-directional rule for their own good security unless they know they need one or if having previously created a one way rule doesn’t end up working for them.
    • While this may require the user to understand in the first place when traffic in the reverse direction is needed, tutorials on the website can help for when the user may ever encounter any problems with traffic between VLANs.

    User should be notified very clearly when an automatic creation of a two-way rule is proposed in the Firewalla app…especially when it involves traffic coming from the Internet (regardless of NAT in the case of IPV4 traffic.

     

    Thank you for listening to and caring about your users, being flexible, and  always striving for  improvement. That’s awesome :)

     

    0
    Comment actions Permalink
  • Avatar
    Chris Thomas

    @mobius strip,

      I would disagree with the statement that 'a typical firewall is stateless for lan-to-lan' traffic flows.  A Stateful Firewall, is a Statefull Firewall.

      A lot of companies use a 'routed core' or 'layer-3' design, and thus any networks (SVIs) directly attached to the core/distribution/access layer(s), would not have any restrictions between directly attached networks, unless someone specifically created access control lists (ACLs) to restrict these flows.  These ACLs, which would have to be implemented on the router(s) or switch(es), would be stateless rules.

      All of this is moot though; we don't want Firewalla creating bi-directional rules, period.  If I want both sides to be able initiate connections, I'll write two rules to allow those flows.

    ...ct

    0
    Comment actions Permalink
  • Avatar
    Firewalla

    We just released the firewalla app 1.47.1 version to "early access mode", which is a minor maintenance release after 1.47, and our developers were able to add the directional allow rule to the mix! (@cyber, yes they went through full testing cycle!)

    1.47.1 is currently in early access, you can join this by send help@firewalla.com with email subject version 1.47.1 [ios/android] and your iTunes or play email address. 

    The warning is a good idea, we will add that to 1.48

    The directional allow will work with WAN or LAN 

    1
    Comment actions Permalink
  • Avatar
    Andy

    Have not seen the update in Test Flight yet, has it already been published?

    0
    Comment actions Permalink
  • Avatar
    A M

    I’m pretty sure 1.47.1 was there yesterday before I received my FWG. Today after firing up the app with the FWG, 1.47.1 does not appear to be available. I thought it was because I needed to enable the “beta test” function on the FWG but that did not change anything.

    0
    Comment actions Permalink
  • Avatar
    Andy

    Received the latest app early access, and I like the option now for bi-directional or outbound only! Also, I like the description of the rule now stating the direction of traffic, good job on getting something done so quickly!

    0
    Comment actions Permalink

Please sign in to leave a comment.