Comments
-
@pacificadmin It´s not related to the GRE incapsulation. I just changed one of my virtual bovpn tunnels to a non firebox type removing the GRE option and the ESP packets is marked with the DSCP value, i have assigned on the firewall policy.
-
My bovpn remote end is set to Firebox, so yes, the tunnel are using GRE.
-
Odd, if i test with a virtual bovpn interface and capture ESP packets on the fysical outgoing interface the DSCP value is set. Differentiated Services Field: 0x30 (DSCP: AF12, ECN: Not-ECT) 0011 00.. = Differentiated Services Codepoint: Assured Forwarding 12 (12) .... ..00 = Explicit Congestion Notification: Not…
-
I have opened a case today. Let´s see what they say.
-
Seems you are right. I just tested it on a bovpn with fireware 12.7.2 Tcpdump on ESP at the outgoing interface shows default tos 0x0 Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) I have enabled QoS and set the dscp value to other than 0 on a test policy. Is this a bug?
-
The remote ip is allowed - and if i choose to set the policy source as the ip address instead of the authenticated AD user, it works, so it´s not policy issue.
-
Is it enough to enable TOS for Ipsec? https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/global_vpn_settings_about_c.html VPN -> VPN settings
-
@"james.carson" @greggmh123 Thank you both.
-
@"james.carson" I noticed, it only happens on some devices and must likely only when it is added to the WSM server as a fully managed device. DVCP logs: Reapplying templates works and i see no issues, so i guess it´s a minor issue first time added a device a as fully managed device. /Robert
-
@toscanatlc And what i wrote was, i do not have that issue.
-
@toscanatlc more odd. Searching for any of the words DNS_PROBE_FINISHED_NXDOMAIN in dimension the last 24 hours from my clusters do not show any of these events and i have selected ALL in search options.
-
@drnet What subdomains?
-
odd, i had some minor issues upgrading to 12.7.2 but both my clusters and single units are running without issues (as far as i know).
-
@"james.carson" I just got it confirmed by Michael Ditmann. It is because AD rejects ntlm authentication and require kerberos. Ldap data error code 52f: 49 52f 1327 ERROR_ACCOUNT_RESTRICTION
-
@"james.carson" https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group No, i mean the issue is as soon as a user becomes member of Protected Users group authentication stops working. I suspect is it because fireware do not support kerberos, and only…
-
Thnak you.
-
I think this would be a question for WG support.
-
So annoying when the support person only reads half of the provided text :(
-
If the M270 devices is connected directly to each other, i would suspect a hardware failure on one of the devices, maybe a NIC issue. Have you checked the NIC status on each device? Do you have other equitment running in the same lan with the same vrrp address?
-
And this, i believe, has nothing to do with our technical skills, but rather a bad designed GUI interface.
-
I opened a case. They have no clue.
-
Non supported KVM maybe?
-
That usual helps to get packets forwarded :)
-
ikeV2 can native run vpn behind NAT
-
With legal ip, do you mean public ip?
-
@Bruce_Briggs Well, i glad it did not have the same problem on one of the M370 clusters i upgraded to 12.7.2. But i will hold of my upgrades to 12.7.2 for now.
-
FYI It is working again.
-
As a side note, i did try to rekey the tunnels from the remote side, but same problem.
-
Well, if it should block all incomming traffic, then reply packets from the inside initiated sessions would not get through and nothing would work. A simpel 3 way handshake would not work.
-
Because the incomming traffic is initiated from the inside interface and not the external.