Comments
-
I got this notion in my head from this statement: Every single interface on the firewall is separated by using VLANs internally. By default, it starts at 2. In SonicOS 7, the default vlan id starts at 3968. If you are configuring/using VLAN sub-interfaces on the switch directly connected to the firewall using the same…
-
I've sorted this out. They were two seperate issues/causes. I incresed the max connections on the receive connector and this has so far eliminated the warning about connection loss. I also discoverd the firewall was attempting to send email alerts but was set to authenticated SMTP. Changing to no authentication cleared…
-
The listening device is connected via switch on the same VLAN as the traffic I intend to capture.
-
I should add that this is using TLS, and I should be able to see a TLS handshake between the ESA and mail server rather than the actual SMTP traffic. I do not see this though.
-
I think this may be a part of the issue. The latest event I've gotten on the exchange server says just that. The maximum number of connections has been reached. This error is on the anonymous relay connector. What I find odd is that based on what I mentioned above is why was I getting the error on the default frontend…
-
@BWC Upon further checking, we do not have SMTP auth configured on the appliance. I'm confused because the original error on the email server was referring to the default frontend end receive connector but this connector is set for anonymous users and why would it be passing credentials for authentication if it's not…
-
@BWC It appears we are using authentication however for unknown reason we have an anonymous relay connector for the ESA specifically as well. The logs show the username for the ESA is what is generating the 2nd error I mentioned above however there's only two of us that have access to make changes and neither have made any…
-
@BWC The option "Auto-generate Access Rules to allow traffic between zones of the same trust level" is the type of thing I'm trying to look out for. I assume that this will create rules that allow traffic to other zones with the same security type?
-
@BWC Thank you. I was just curious why the rule was created since, to myself anyway, it appears to have no obvious purpose.
-
@MitatOnge Yes this is quite common with other "brands" of wireless gear. Additionally, our Sonicwall NSA5600 can show this information.
-
@MitatOnge On station status sub-menu, it gives the quality and signal strength as a percentage. Not actual numbers. It would be a much more clear picture with actual numbers/strength.
-
@MitatOnge I contacted support on this. Turns out this is a potential bug and they are looking into this currently.
-
They both say "regardless" of each other. So which one takes precedence? We shouldn't be trying to put a MAC in both but when that list starts to get large enough, I could see that happening. Is the most restrictive wins situation?
-
Doh! In my ignorance I ignored the fact that the APs(sonicwaves) are acting as the authenticator and not the firewall. Adding the NAT rule obviously allows me to configure a single IP address rather than 20 in my case.
-
A second question regarding this. Since I'm applying the bandwidth object to the access rule Guest>WAN. First applying a rule to limit download seems wrong here as quest>WAN implies upload. However applying the BW object to ingress does appear to limite download and applying to egress limits upload. Can someone break down…