Best Of
Re: Lumen NaaS setup
As long as you're on version 12.8 or higher (when the feature was introduced), you create a VLAN of type External (set a VLAN ID accordingly), then set the desired physical interface as a VLAN trunk, and configure it to use the VLAN you just created, assuming it needs to be a tagged VLAN.
Re: configurare SD-WAN
On Link Monitor, you specify a target for checking for the WAN.
It is recommended to select something upstream from your firewall default gateway.
I use a public DNS server such as Google DNS server IP addr - 8.8.8.8 or 8.8.4.4; or another public DNS server 1.1.1.1
That Link Monitor selection will be reflected on the SD-WAN action(s).
The option(s) selected will determine when a failover to the other interface(s) in the SD-WAN action.
Loss Rate, Latency, and/or Jitter are SD-WAN action optional selections.
If you don't select any of the 3, failover will happen when Fireware marks the primary SD-WAN interface as down, which will happen based on the Link Monitor settings for that interface.
Re: iPadOS18 IKEv2 Mobile VPN + Authpoint
Hi,
I ran into the same issue (payload ID size too small) in a slightly different setup (IKEv2, Radius, iOS18) and found that the client profile for the IKEv2 Mobile VPN does not contain a LocalID, which seems to bother iOS at least on the iPhone.
My solution/workaround/whatever you call it was:
- download the client profile from the WG Appliance
- extract, dive into the MacOS_iOS-Folder
- edit the xxx.mobileconfig with your favourite text editor
- find the <key>LocalIdentifier</key> tag, which should be followed by an empty <string /> tag
- insert an identifier into that string-tag, a UFQDN like user@vpn.internal should suffice, it seems not to be verified anywhere (though I did not run any IKE message tracing)
the segment should then look like
<key>LocalIdentifier</key>
<string>user@vpn.internal</string>save, then airdrop/push the .mobileconfig to the iOS-device and install.
worked for me.
Have a good day.
stefanbo
Re: Tracert results oddity
One possible reason is that Pings are being denied from the source IP addr.
Re: Block source IPs for brute-force login attacks
There is a new option in V12.10.4 to block brute force login attempts, and includes a setting for the number of hours for the IP addr to be blocked..
See the "Configure Block Failed Logins Settings" section, here:
Set Global Firewall Authentication Values
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/global_auth_settings_c.html
Re: SSLVPN Access Attempts
FYI - V12.10.4 adds this feature - from the Release Notes:
. You can now block the source IP address of consecutive authentication failures to the Firebox. [FBX-9333, FBX-19172]
See the What's New for V12.10.4 for details:
https://www.watchguard.com/help/docs/fireware/12/en-US/whats-new_Fireware_v12-10-4.pptx
This includes access attempts for SSLVPN
Re: I can't manage firebox via WEB UI & WSM policy manager.
Also, after a quick check appears that the xml overhead is smaller (still large) for additions to the Blocked Site list than to the Alias list
Re: I can't manage firebox via WEB UI & WSM policy manager.
Seems like a limited available memory issue with your firewall since you added the quite big Alias list.
The Web UI certainly needs a fair amount of firewall memory to be run.
Not sure of the available memory needs for WSM/FSM.
Perhaps WSM can connect after a firewall reboot.
In any case, try a smaller size for your imported list and see if that helps.
You can save the current config file to disk, and see what the size is with the current imported Alias file and compare it to a previous one.
The config is in xml format, so an imported file adds many times more to the config size than the size of the text file being imported.
Re: Help changing public IP address from ISP
Hi @Fire_Smith
If your isp is delivering via a VLAN, you can in theory set your external interfaces as VLANs on the same interface. They would need to be using different VLAN IDs, and they would both need to be tagged for this to work.
Otherwise, if you wish to maintain connectivity for a bit with both IPs, your method sounds like the best way to do this.
Block source IPs for brute-force login attacks
Hello, since a couple of monthy I regularly see brute-force attacks on our SSLVPN port. While this cannot work (we have 2FA in place and no indicator of password compromise), it generates a lot of alerts and in practice this can be continued endlessly, so there is a small risk that easy-to-guess usernames and passwords could be compromised by brute-force.
Many devices that I know have a possibility to block a source IP after a certain number of wrong password requests for some minutes, e.g. 10 minutes after 3 wrong passwords. As far as I see, the WG Firboxes do not have such a feature, which would make brute-force attacks much harder. And blocking the source IPs by hand is a tedious job as they change all the time.
What das WG support say?
I know and read the KB article 000024807 "Unknown authentication attempts against Mobile VPN with SSL from a user named "test" or other random users", but the actions described there are limited to detecting such attacks and applying geolocation. In our cose this does not help as the attacks come from countries we cannot easily block. The suggested connection rate limits would not help either as these attempts are 1 every 5 minutes or so. And we have AuthPoint 2FA, but this does not prevent the login attempt. So a feature to block such requests after some false logins would improve security a lot.
ovwg