Can't log into firebox WebUI over the web anymore?
Is this in the right section?
I used to be able to type a fqdn:8080 from my house and get into a watchguard at a client.
Now, I can't.
Looking at traffic monitor, there's 3 green allow entries from my public IP:
2022-06-01 14:50:28 Allow 173.70.xxx.yyy 75.127.xxx.yyy webcache/tcp 13507 8080 External Firebox Allowed 48 115 (WatchGuard Web UI-00) proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_src_match="house.mydomain.com" tcp_info="offset 7 S 2604036426 win 64240"
2022-06-01 14:50:28 Allow 173.70.xxx.yyy 75.127.xxx.yyy webcache/tcp 13506 8080 External Firebox Allowed 48 115 (WatchGuard Web UI-00) proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_src_match="house.mydomain.com" tcp_info="offset 7 S 2044777481 win 64240"
2022-06-01 14:50:28 Allow 173.70.xxx.yyy 75.127.xxx.yyy webcache/tcp 13508 8080 External Firebox Allowed 48 115 (WatchGuard Web UI-00) proc_id="firewall" rc="100" msg_id="3000-0148" fqdn_src_match="house.mydomain.com" tcp_info="offset 7 S 1829557927 win 64240"
I do also see these deny messages - not sure if this is related. These are coming from a unifi wireless access point on the LAN, reporting back into the unifi controller at my home.
2022-06-01 14:51:26 Deny 192.168.1.129 173.70.xxx.yyy tproxy/tcp 52344 8081 Internal Firebox tcp invalid connection state 52 64 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 AF 3953276401 win 980"
I was getting deny messages
Internal Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead).
from that same LAN IP where people said to turn off 'Enable TCP SYN packet and connection state verification' in global settings on the firebox.
I tried geting to the webUI from 2 different PCs at my house and same thing.
Connecting into server on LAN with splashtop, I CAN get to the webUI.
I CAN use WSM to get into the firebox.
It's the middle of the day so I don't want to reboot the firebox.
Any suggestions?
Is a reboot a reasonable solution or is that 'cheating'?
Any recommendations on troubleshooting why I can get to the webui from the LAN, but even though it looks like I am getting through the watchguard, I don't get the web ui from outside the LAN?
And you think I can ignore those deny messages? The unifi controller seems up to date with info from the unifi access point.
Comments
For the record, what Fireware version are you running?
Hopefully you only allow this access (Web UI & WSM) for very limited IP addrs... because of the cyclops blink issue.
If you can access the Web UI internally, then I would not expect a reboot to resolve the issue.
Could there be wi-fi issues at your house which is causing spotty connection to your firewall?
Who wants to bet the OP got a new IP and is no longer able to connect due to the 8080 rule. Best way around that is to have a VPN back door to the box and then you can correct the WebUI policy (and also see if you can use System Manger).
@TestingTester
Well for once, I did something right before posting . The webui policy has trusted alias and only my FQDN for my home network and that checks out... the ip showing in traffic monitor is the same as my home public IP.
a) What's the rule? Anything more than lock down what IPs can get in? Or don't use 8080?
@Bruce_Briggs It's version 12.5.9.B655824. Services have expired. I think this was the highest version available? I read that because of the cyclops issue they were letting boxes upgrade to newest version. it's a T35W - and support said this 12.5.9 was as high as I could get for free?
I am connecting with 2 diff desktops. wifi isn't used.
And the client's watchguard is showing allow in traffic monitor? so that means it's getting to the firebox successfully?
I also tried typing their fqdn with https:// and with http:// in front of it. Same result.
And same failure using chrome and edge on 2 diff PCs at my home (where it WAS working 'previously'.
Test this by taking out your FQDN and putting in your real IP. The two PC's will not matter as they (presumably) have the same external gateway.
@TestingTester
Notice that the allow log messages initially posted show the FQDN, so I don't see that this is a changed IP addr issue.
There should be no difference in using an IP addr in the policy and a FQDN as long as the IP addr associated with the FQDN is correct, which it seems to be from the posted logs.
fqdn_src_match="house.mydomain.com"
@David0
Perhaps somehow this is a MTU issue.
Try setting the MTU on a PC to 1400, and see if that makes a difference here.
The default MTU is 1500.
Some ISP connection types have a MTU of less than 1500, and some web sites don't work well with split packets caused by using too high a MTU for the session.
If MTU is the issue, you can use Alan's PMTU script to change Windows so that it automatically identifies the correct MTU to use for a session.
I have listed that script in this topic:
IKEV2 sound
https://community.watchguard.com/watchguard-community/discussion/comment/5280#Comment_5280
I agree that having a client VPN access is a reasonable alternate choice.
I changed the MTU on 1 of the PCs that are outside the LAN to 1400 and didn't see any change in the situation.
I moved the webui policy to the top of the policy list. Still same - no connection from outside the LAN.
I changed the port of the watchguard WebUI (global settings) from 8080 to 8073.
Cute - the box updated the policy for the webui to 8073.
I got the login screen from outside and inside the LAN
(vs. getting the login screen only from inside the LAN).
Would anyone know what that means? That I get an allow in traffic monitor when trying to connect over 8080 but don't get the login screen of the watchguard.
But when the box's port is changed to 8073, I get the allow in traffic monitor AND get the login screen when connecting from outside.
And inside isn't affected by the port number change - I get in either way.
Has access remote access worked over TCP port 8080 since the upgrade to V12.5.9. U2?
Perhaps this could be a result of Cyclops Blink changes - although this is not listed in the Release Notes.
I believe it has been working. Thinking now, they are getting VoIP phones and someone there just added a policy in the last couple days for the phones to ensure they get out ok. But from what I can see with that, port 8080 isn't listed and it's an outbound rule anyway?
I used advanced port scanner and scanned devices for 8080 being open. it did find a few devices that have port 8080 open. But that shouldn't matter, right? (it would only be an issue if there was a policy / port forwarding /SNAT coming in on 8080 and 8080 could only go to one machine?
again, the fact that I changed the firebox to use 8073, solves things. But what's between the firebox showing allow in traffic monitor for the 8080 data and the WebUI rule using 8080 not getting to the box' Web UI?!
If you have a support contract, consider opening a support case on this.
Most odd, indeed.
Call me jaded...you (or someone) had to have created a rule for 8080...makes no sense. Unless you are the first person with a new thing from a new place in this brave new world.....
A WatchGuard Web UI policy, as shown as the allowing policy in the orig. post, is auto-created by the QuickSetup Wizard
@TestingTester that's what I would think - there's another rule for 8080. Well, actually, you say rule... that's a policy, right?
I got the config report, searched for 8080 and found it in the WebUI policy and spamblocker uses 8080. And the global setting of the port for webui.
but nowhere else.
this box doesn't have an active feature key, so spamblocker isn't enabled.
Anywhere else to look? I guess I should have enough sense to just change it to 8073 again and move on. But I like to figure this out after wasting all this time on it.