I am attempting to use a Watchguard SSL VPN client to connect remotely. Clarification: I am using a computer behind a OPNsense firewall connecting to a computer behind a Watchguard firewall. I didn't get a clean copy before I upgraded to 27.7.7_4. The vpn client worked before the latest upgrade. As I read the online instructions, I found the "rid" link on the "detailed rule info" screen should point to the rule of why my vpn connection is being blocked. On a rule that "worked" (unrelated to this issue), I click on the rid link and it brings be Firewall:Rules:Advance screen. I don't see why I go to this screen since there are no rules. In my case, I click on the rid link, OPNsense opens a new window (like the one that works), but then immediately closes the window.
Here is a copy of the rule info screen:
__timestamp__ 2025-11-20T21:54:22-06:00
ack 897488549
action [block]
anchorname
datalen 0
dir [in]
dst external IP
dsthostname
dstport 443
ecn
id 48471
interface vtnet0
ipflags DF
ipversion 4
label Default deny / state violation rule
length 40
offset 0
protoname tcp
protonum 6
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
rulenr 11
seq 431912277
src internal IP
srchostname
srcport 64022
status 2
subrulenr
tcpflags RA
tcpopts
tos 0x0
ttl 128
urp 0
I think I sanitized the screenshot. I first thought the rulenr was the rule number, but the rules that allow access show a value of 94, but I don't think I have that many rules, unless they are counting all rules for all interfaces. As far as I can tell, going to other HTTPS sites are working as expected.
Will someone explain how to read this page to see what rule is causing the vpn to fail?
Thanks.
Quote from: TJL on November 21, 2025, 05:48:34 PM[...]I click on the rid link, OPNsense opens a new window [...], but then immediately closes the window[...]
Sounds like an automatic rule. Those don't have configuration pages.
As for the rule info, that's the automatic default deny ("label Default deny / state violation rule"). It looks rather like you don't have an appropriate pass rule on vtnet0 ("interface vtnet0") for HTTPS ("dstport 443"), but the TCP flags ("tcpflags RA") indicate a reset/reject (TCP term/firewall term, respectively), from the client (not the server, where it might be the Watchguard). If in fact you have an appropriate pass rule for HTTPS on vtnet0, this indicates a TCP RA packet outside of an established session; if you do not, it's an odd client behavior, as you can't start a session with a reset. Circumstances where you normally see this include multiple network paths (where at least one bypasses the firewall), junk from the Internet (not normally in this direction), or when the firewall state table is cleared. I suppose if you used the client HTTPS request to set up the tunnel, delay and/or packet loss could upset the client, and a reset might appear to the firewall to be outside of an established session. This circumstance should be temporary. I haven't actually set up a tunnel in about 15 years (and never on OPNsense), so I'm a bit behind the times.
By the way, you can locate the rules by rid under "Firewall: Diagnostics: Statistics" -> "rules" -> "filter rules" (the "label" field, not the same as the text label/Description).