BWC Cybersecurity Overlord ✭✭✭
Reactions
Comments
-
@CRISL I would go for bug, because it does not make sense to unhide the Domains by just cranking up Mobile Connect. But on the other hand it says "Hide Domain list on portal login page" so maybe the developer just did only this :) Excerpt from the Admin Guide "By hiding the domain name, this makes it more difficult for a…
-
@callidus I'am not aware of a viable built-in solution. —Michael@BWC
-
@dfait this scenario asks for pinhole (loopback) NAT. You might search the forum for that, because it got answered a few times. Short story: NAT external IP to internal IP (like you already did) but without specifying any interfaces. Then create an Access Rule for LAN-to-LAN, Source ANY and Destination X1 IP (or whatever…
-
@callidus hopefully that isn't something you need long-term, but I have deployments with Mikrotik Routers installed on each side behind the SNWL and providing an EoIP (Ether-over-IP) tunnel for all needed VLANs. It's a working solution, but I prefer collision free IP addresses on each side. —Michael@BWC
-
@FEDEL did you listed all (custom & default) rules for LAN to WAN and made sure that your deny rule is really where it meant to be? Usually I disable all automatic rules in the zone configuration which means an implicit drop for not explicitely allowed traffic. You also should check LAN to ANY, just in case. —Michael@BWC
-
@DesertSweeper ist there Double NAT involved in this scenario? I'am facing this issue a lot when there is a router in front of the SNWL. I never had the chance to figure out the final reason for that. Sometimes it helps to restart one side, but not always. —Michael@BWC
-
@Angel_Georgiev this setup will work but keep in mind the PPPoE link will go down in case of the failover and needs to be connected again. This may take a few seconds/minutes. Dial-Up in HA isn't a joy, even in stateful scenarios. Best option would be a router in front of the SNWL, but this would introduce double NAT with…
-
Release Notes finally got published. —Michael@BWC
-
@radiman subnet will collide with your other locations, because it'll make an ARP request when it's in your subnet boundaries. It will not even try to route it over your VPN, except all endpoints getting an explicit route, but that's not really good. Best option would be a renumbering of 10.15.23.0/24 to something more…
-
@ChristianK if the medical device is in the 172.17.1.x range, like the backup server was before, NAT gets a little bit tricky because it does not answer any ARP requests and does not handle half open connections. If this is the case you need additional steps to make it work until the technician can alter the address.…
-
@dp8 I changed the TimeZone on a Gen6 with 6.5.4.14 to India and the syslog reflects the change. The first timestamp (CEST) is added by my syslog but the time= value comes from the Firewall. <local0.info>2024-05-15T06:43:28.946338+02:00 shield.bwc.internal id=shield sn=xxxxxxxxx time="2024-05-15 10:13:28"…
-
@DP8 if 192.168.99.236 is a functioning NTP server you should be good. It seems that "Current NTP Server" in the TSR is the last one the appliance tried to connect to. Check again after your interval of 60 Minutes is past. —Michael@BWC
-
@DP8 custom NTP Servers are configured at Manage → Appliance → System Time and enable " Only use custom NTP servers". I deleted all of my custom NTP servers and TSR still shows one. Best way is probably to define a valid NTP server for that location. —Michael@BWC
-
@dp8 why do you have ntp.cais.mp.br in your config if Brazil is blocked? System time on your appliance is correct or already drifted? You should configure a valid NTP server from which you know it's working. I checked my config and local time is properly reported to syslog. —Michael@BWC
-
@DP8 what are your setting at Mange → Appliance → System Time Time Zone is set to your local Zone? Did you enabled "Display UTC in logs (instead of local time)", which what cause what you described. —Michael@BWC