Best Of
Re: WireGuard vpn
Hi @rgloor @Norman
While you're welcome to add your voices here, I'd suggest creating a support case (mention FBX-19543 somewhere in the case) and the tech assigned the case can set it up to watch that request for you.
The project management team uses cases open under specific requests as a metric to see how much interest there is in a specific feature.
Re: Google login issue
I've found in the past that QUIC through the firewalls caused all sorts of issues with our Google Workspace. I have a custom policy defined for UDP 80 and UDP 443, which is used to block QUIC access from the internal and optional networks out to the external interfaces. This rule has been in place since around 2015 and we have not had any further Workspace issues caused by the firewalls.
JMH
Re: Missing feature keys
Include pics of the model & serial numbers of your firewalls.
Ask to have these devices registered to your account.
You should get Feature Keys as a result of this process.
How to inject "classic" IPSec VPN routes into OSPF
Apologies if this is already a well know thing, but I failed to find info about it when I was researching it.
I was looking how a firebox could inject "classic" IPSec routes into OSPF, so that the rest of our network could use the routes, rather than having to declare them as static routes on internal routers behind the firebox. This is easy for BOVPN virtual interfaces, but appears not to be a supported option for "classic" VPNs, as the remote end of the VPN isn't seen as a connected network for inclusion in the OSPF calculations.
The Status Report section of System Manager shows the network at the far end of the VPN in the "Run-time IPSec Routes" section, with the "Out Interface" being the physical interface of the external connection.
Static routes on the firebox can be injected into the OSPF table using the "redistribute static" command in the OSPF configuration.
On the firebox, I configured a static route to the far end of the VPN via the default gateway of the external interface. This did not affect the routing down the VPN within the firebox, and the traffic for the remote end of the VPN continued being sent down the IPSec tunnel.
The result is a static route to the VPN destination that can be injected into OSPF which doesn't affect how the Firebox handles the VPN traffic. (I used a route map to control which static routes get redistributed, but this isn't necessary if all your static routes should be injected into OSPF.)
The internal routers now see the "classic" VPN destinations in the OSPF tables and there is no longer the need to configure the static routes within the internal network. The route seen in OSPF isn't via the external default gateway, but via the firebox itself. (The routes you see on the routers connected to the firebox will show via the firebox, and for the routers behind the routers connected to the firebox, you will see the route via the connected router, etc.)
How useful this is depends on your network, but for ours, this ability to have the routes in the OSPF tables has been extremely helpful.
Hopefully this info will be useful for someone else.
James
JMH
Re: Google login issue
You can set up email notifications for port scans, which could help get Google site access back quicker.
Re: Google login issue
Well support suggested that it was our gateway AV reading packets that may have been causing the issue, and also suggested restarting the server if we hadn't already.
We messed with the gateway AV some, ultimately toggling off the "When a scan error occurs -> drop" setting. After this our issues seemingly vanished.
Until today that is, now after this post I am assuming it was not the Gateway AV change that solved our issue but the restart.
Re: Google login issue
For others, what did you change which did not end up helping at your site?
Google login issue
We are having an issue where users cannot log into Google, both personal and Workspace accounts. If I bypass the firewall, a user can connect. If I restart the firewall, users can connect again but by the next day the issue is back. We first had an issue with downloads from Google on the 23rd. The problem cleared up on its own, while I was troubleshooting the issue. I went ahead and updated the firewall to 12.11.8 anyways. Yesterday the login issue appeared. It doesn't matter what computer or browser we use. I've tried having the NAT connection go out of different IP addresses, I've tried switching from a proxy rule to just a packet filter rule.
MeOMy
Re: VoIP dropping calls (go silent on both ends, but still look connected)
No one uses SIP-ALG, no one. In general you need a packet filter for the needed ports to the IP's or FQDN of the IPT vendor (or system).
A common one...
TCP and UDP 5060->9
UDP - 10,000-30,0000
UDP - 5222
And depending on other things, well, other things. 80 and 443 are already handled in theory.
I also create an alias for my handsets (in general PolyCom) so that I can easily apply rules to the handsets on their subnet.
As a note - "Any" never seems to work. I have to create packet filters with the needed ports to the needed (external) IP's and things work very well. There are a few options for the handsets (option 150 or 66).
