updated subject: Creating outbound rule silently creates mirrored inbound rule
Updating subject line to reflect comments.
Hi, i think i'm missing something obvious, but is it possible to set up a rule to allow communication between device A on VLAN 1 to device B on VLAN 2 using the device definition in Firewalla? The only way i can figure out how to do it is by using the IP address for device A as the target, and then selecting device B as the "Device".
The context is i want a couple of specific devices on VLAN 1 to be able to print to a printer on VLAN 2 and i've blocked VLAN to VLAN routing.
Im running a gold in router mode.
-
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.
-
@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.
-
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.
-
@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): AnyFrom/Source: IP Address A,
From/Source Port(s): Any
Protocol: Any
To/Destination: Device B
To/Destination Port(s): AnyDistinctively, 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.
-
@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-directionalSetup
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-directionalThis 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?
-
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)
-
@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 :) -
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?
-
@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.
-
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...
-
@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.
-
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...
-
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.
-
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.
-
@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!
-
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!
-
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)
-
If you are doing port forwarding, you can also lock it down this way
-
@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.
-
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.
-
https://help.firewalla.com/hc/en-us/community/posts/4405028934931
There is already a Feature Request opened regarding the bi-directional rules; UP VOTE!
-
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:
- A typical firewall is a stateful firewall for traffic between LAN(s) and WAN(s).
- 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 :)
-
@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
-
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
Please sign in to leave a comment.
Comments
34 comments