Comments
-
Yes but would be of academic nature. If WatchGuard would not change the behaviour the understanding would not be of any help. Maybe they will if they were aware of the fact. I assume that the "Denied (send reset)" was implemented to address timeout problems on the client side which is not the case. Would also be…
-
Just for the records: I made some tests with Putty - same results. Against a server I get an immediate "connection refused" - with Firebox there is a 15 seconds delay.
-
@Bruce_Briggs Thanks for sharing you findings. What seems strange to me is that we tested with Telnet and saw different behaviour for Firebox on the one and IP-tables or direct server connection on the other side. So as client is the same the difference must be on the Firebox and server / IP-tables side. Just thought that…
-
We now have it working here with FW 12.6.4.
-
OK I will do this THX again for you help.
-
What I found out so far. We have customers where it is working and customers where it is not working. The only difference between those two is the way the internet connection is realized. Not working: External interface is connected to carrier router and the Firebox is assigned a static public IP on the external interface.…
-
Just to be sure, there is no way to get it work with IPSEC? Cheers.
-
THX for confirmation, before locking out myself when trying in production environment.
-
Hi Bruce. Thanks for pointing that out.
-
The document you posted indeed also works for the Report Server. However the path to do the modifications is "C:\ProgramData\WatchGuard\wsserver" as I suspected previously. This can be verified by the "Listen" directive of the apache conf file which is "4130". "wrserver" is the instance which listens on Port "4122". One of…
-
Indeed today morning the reports for yesterday are available. To sum it up: When a schedule is executed it creates the daily report with the data from the day before 00:00 AM to 11:59 PM. So for the first schedule to run you have to wait at least until midnight. Thanks a lot for pushing me into the right direction. Cheers.
-
I will wait, check and report back. THX a lot for your help
-
While reading your post I thought it may be a good time to rethink my assumption on the scheduling logic. What is considered a daily report (what data is included). From 0:00 AM to 11:59 PM? or From schedule time of previous day to schedule time of day of schedule?
-
I setup a new server and cause I wanted to see if it works I set the schedule **day **to yesterday and the schedule **time **to 5 minutes in the future. Then I waited until the schedule finished.
-
AFAIK these are the log messages from the Report Server itself? I set this to see if the Report Server is executing the schedule which it does. I think I was not precise enough, sorry for that. I have a Firebox which send it's logs to the Log Server. This works. I can see the Firebox device and also the log messages from…
-
WatchGuard Server Center -> Report Server -> Logging -> File path -> Set a log level. We do not have a "Management Server" setup. Only "Log Server" and "Report Server"
-
Any news on the release date for the new version?
-
Hi James, thanks for your efforts. Cheers.
-
No the carrier requires ID 7 in all packets, untagged packets are not accepted. As you can mark which VLANs are assigned to which physical interface I would suspect it should be possible (at least for external interfaces). So for me it looks more that development did not have this use case in mind and added this check to…
-
Thanks for confirmation. Hopefully it will get into a release soon.
-
Hi Daniel. Just for the record. We are not sure if the Swyx itself is the problem. It could also be the telephone carrier or a combination of both. Most important thing if you try to get the SIP-ALG running is that you disable STUN on the PBX as it interferes with SIP-ALG.
-
H. Bruces. I verified this and you are right. You can connect via MUVPN with the credentials of a Firebox-DB user even if he does not belong to a MUVPN group. Cheers.
-
Ok we will open an incident. However everyone should be careful. If you have IP addresses in your normal rules that are part of the virtual address pool for a MUVPN group those rules grant access nevertheless the user is in that AD group or not. Currently we are operating about 70 Fireboxes for our customers an we checked…
-
I did not understand what you mean? If I put a rule in the normal firewall rules tab like "Any | 10.10.0.0/16 -> Any Trusted" and "10.10.100.0/24" is the virtual address pool for the MUVPN group "MUAdmins" then anyone able to authenticate against AD is able to access all resources on the subnet "10.10.0.0/16" independently…
-
Hi Daniel, as I can see we are in the same boat. We also had to setup a Swyx behind a Firebox. After spending endless hours in trying to get the SIP-ALG running without problem, we dropped it altogether and used packet filters instead. Sometimes it worked and sometimes voice was missing in one direction.
-
Another question. Does it work similar for Firebox user authentication now as it does for AD? I suspect not. What I mean is can all users in the Firebox DB connect via IPSEC VPN client regardless if they are part of a MUVPN group and only traffic is blocked for those who do not belong to such groups? The change how it…
-
Hi James, the OU solution is not an option as it would break the whole AD design of the customer (having about 2000 users). I really have no idea why WG does it this way. There is no reason to let people connect which are not allowed to in the first place. However THX for the suggestion.
-
Hi James, THX for your fast response. IMHO this is rather bad design. We have situations where we have ADs with a lot of users and only a few are allowed to connect via VPN. Users which are allowed to connect via VPN are automatically assigned a password policy which enforces strong passwords. With this design it is…