I am SOOO grateful to find this group. I've been having serious issues with the
latest firmware, and despite having 10 units deployed in various places around
the world I've been completely unable to get access to the support portal. A
customer rep is working on that, but hopefully I can get some help in the
meantime.

Environment:
SG565 firmware v.4.0.2
2 WAN ports, one as default gateway, and one hosting specific services in the
DMZ. No load-balancing, just fail-over.

1 LAN Bridge between A1 and Wireless
1 DMZ
1 Guest

We did NOT upgrade the config, we reset to factory and rebuilt by hand using the
new interface (which took a couple hours)

So, here are the major issues we've encountered:

1) Bridging doesn't actually work between a LAN (switch) port and the wireless.
The interface creates the bridge and displays it as functional, but it's not
actually bridging. It appears to me that iptables entries that should be
pointing to the bridge "br0" are instead created in duplicate referencing the
physical interfaces using "PHYSDEV match" commands. In order to make the bridge
work in the short term, I've had to create a packet filter rule, "Accept -
Forward (Bridge 0) (Bridge 0) Any Any Any". This isn't a true bridge, since
this is happening at the IP level, but it's enough for us.

2) PPTP Server crashes the entire box under logon load. This can be
demonstrated by a single user repeatedly logging in and out of the box. It came
to our attention when a new user was having trouble remembering her password. As
a result, she tried it over and over again within a few minutes. On our end, the
SG565 just stopped responding. The VPN light went out completely, and despite
there being traffic showing on the interface lights, no traffic was being passed
through the box. Both Web GUI and SSH were completely unresponsive, and the only
fix was a reboot. We've had to disable PPTP access until we can resolve this
issue.


3) I've got a "ghost" of a problem that I can't seem to get a handle on. I'm
seeing a lot of dropped packets on the status meter (up to 7% at one
observation), which may or may not line up with a bunch of "nf_ct_tcp: invalid
packet ignored" and "Invalid - dropped:" messages in the log. Most of the
dropped or ignored packets seem to be valid web traffic initiated internally and
destined for external web servers. None of these packets are being caught by
drop rules written by me (all of which log their rule name).

4) We've also had the IPSEC.secrets issue related to not using the default
gateway. However, this has already been documented here.

5) The horizontal scroll bar on the log page is enough to make you crazy, but
everybody here already knew that.

6) Surprisingly, the default rules (the hidden ones that you can only see as raw
iptables) seem to be significantly different than in 3.1.5u4 (which we upgraded
from). I had to write 3 or 4 additional Packet Filtering rules in the new
firmware just to duplicate the behaviour of the 3.1.5u4 firmware.

7) DNSMasq issues. I understand some of the new capabilities that DNSMasq
provides, but I must admit that had me SERIOUSLY confused for a while. Because
DNSMasq is configured to load-balance between all known DNS servers, I've had to
seriously reconfigure my usage of it.

From a DNSMasq FAQ online, "By default, dnsmasq treats all the nameservers it
knows about as equal: it picks the one to use using an algorithm designed to
avoid nameservers which aren't responding. To make dnsmasq use the servers in
order, give it the -o flag. If you want some queries sent to a special server,
think about using the -S flag to give the IP address of that server, and telling
dnsmasq exactly which domains to use the server for."

We have an internal DNS server on the LAN serving private IP's for many of our
LAN and DMZ-based services. The "old" behaviour allowed us to simply list this
DNS server first in the SG565, and then list public DNS servers as fail-over.
This allowed us to use the DNS proxy from both LAN and DMZ quite elegantly and
gave us an automatic fail-over if our internal machine was down for maintenance.
However, since the "new" behaviour auto-load-balances, you can no longer
consistently get DNS resolution of internal machines from the proxy unless the
ONLY DNS server that DNSMasq knows about is the internal one. It would be VERY
useful to me to be able to enable the -o and/or the -S command from the SnapGear
configuration (command line would work, but GUI would be ideal).

We've been using SnapGear units for many years now (under SnapGear, CyberGuard,
and Secure Computing), and this is the first time that we've had a problem with
a firmware upgrade. Frankly, I'm more than a little concerned after this
experience, especially with the problems I've had getting support (which seems
to be purely administrative, but still significant).

Thanks for any help you can give. Do we have an ETA on 4.0.3, and would it
address any of these issues?

Josh