Firebox allowing outbound to "private ip addresses"
I thought I discovered a new problem as a result of tweaking policies, but it turned out that the problem existed ever since a Samsung so-called "smart" TV was added to the network.
The only reserved networks configured on my side of the WAN are 172.20.20.x and 192.168.0.x.
But I'm seeing "allowed" traffic from 172.20.20.x to 192.168.1.3 ... at least until I blocked the entire 192.168.1.0/24 network.
The syslogs show that the Firebox category for the HTTP traffic is "Private IP Addresses". I would expect these to get blocked with the exception of those known to my side of the WAN. Here's an example log entry:
http-proxy[1882]: msg_id="1AFF-0021" Allow zzzzzzzz External tcp 172.20.20.x 192.168.1.3 56626 80 msg="ProxyAllow: HTTP Request categories" proxy_act="Default-HTTP-Client" cats="Private IP Addresses" op="GET" dstname="192.168.1.3" arg="/log?message=Start%20Callback&data=undefined" (HTTP-proxy-00)
There will be several of these in succession and the message= portion looks like it is setting up some sort of transactional handshake.
How can I more easily control such activity? Constantly combing through the logs and adding more blocked networks is going to get rather tedious in short order.
Answers
The firewall will route anything that is not a local IP addr out to the firewall's default gateway.
However, your ISP should drop any packets destined to a private IP addr.
So I would not obsess about this.
This might be being caused by an app on your smart TV.
Bruce: I am positive it is being caused by an app on the TV. And yes, I agree wholeheartedly that the ISP should drop packets addressed to private addresses.
However, reading through the individual "arg=" text doesn't give me a warm, fuzzy feeling. Here's one of the shorter "sessions" (9 log entries) with everything redundant stripped out leaving just the "arg=" text. There are more "involved" setups but nothing to indicate a response.
Yesterday (2-Jul), for example, started seeing these messages at 5:00 AM ET (GMT -04:00) and continued through until 21:30 with 2-20 minute breaks in-between.
With the network blocked, I get none of it leaving me to suspect the message is somehow getting through despite the ISP and the seemingly private IP address. It is as if the TV has a tunnel at its disposal that I can thwart by blocking it outright.
These look like log messages, which presumably are trying to be sent to a log server at 192.168.1.3
You won't see reply packets in the logs.
You can do packet captures on the firewall which will show reply packets.
Use TCP Dump for this.
You can set advanced options to specify the IP addr to capture, etc.
FSM:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/fsm/log_message_learn_more_wsm.html
Web UI:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/system_status/stats_diagnostics_tasks_web.html
Examples:
https://danielmiessler.com/study/tcpdump/
Hi ACO,
The firewall will classify anything that's not a trusted, optional, or custom network as External, and send it outbound.
If you're looking to deny that traffic, making a deny policy from Any-Trusted to 192.168.0.0/16 and that would effectively make the firewall drop any traffic destined to any 192.168.x.x in the RFC1918 address space. Like Bruce mentioned, an ISP will simply drop this traffic since there's nowhere to route it.
If you make a rule like this, just remember that it exists, as if you ever make an internal 192.168.x.x network, it'll block traffic to there too.
-James Carson
WatchGuard Customer Support
Note that he does have a 192.168.0.x subnet already.
Filtering my syslogs a bit more, there are actually two sets of packets in a "session." The first is similar to the code in my post above and the second is a timeout. After a few pairs of these will be a consecutive stack of packets uninterrupted by timeouts building the message.
http-proxy[1882]: msg_id="1AFF-0024" Allow zzzzzzz External tcp 172.20.20.x 192.168.1.3 56588 80 msg="HTTP request" proxy_act="Default-HTTP-Client" op="GET" dstname="192.168.1.3" arg="/log?message=initializing%20local%20port%20&data=%22BG_PORT%22" sent_bytes="117" rcvd_bytes="0" elapsed_time="127.321963 sec(s)" reputation="-1" (HTTP-proxy-00) pxy[1882]: 0x10205bd8-58020 connect failed Connection timed out 45: 172.20.20.x:56586 -> 192.168.1.3:80 [A] {B} | 61: 192.168.0.x:56586 -> 192.168.1.3:80 [!B c] {B}[P]"connect failed Connection timed out" - indicates that there is no session to 192.168.1.3, thus just annoying messages in your logs.
Badly coded app on the TV.
[sigh] Yet another cr@p app and entry level programmer loose on the world. I've never let applications like that get out the door "back in the day." Eyeballing logs and error reports is troublesome enough as it is. Having to repeatedly, mentally ignore entries just increases the probability of overlooking something important.
Well, I can at least mostly eliminate the garbage by denying 192.168.1.0/24.
Now I'm off to find some documentation that explains the flags in the "connection timed out" message.
Thanks.
Look up 1AFF0024 in the WatchGuard Log Catalog
https://www.watchguard.com/help/docs/fireware/12/en-US/log_catalog/Log-Catalog_v12_8.pdf
That's not the message I'm looking for. It's the other one. I'm hunting specifically for the flags:
[A] {B} | xxx.xxx.xxx.xxx:pppp -> yyy.yyy.yyy.yyy:pppp [!B c] {B}[P]
It's always the message that has no msg_id that bogs one down.
Hi @ACO
it's the HTTP proxy saying that it can't connect from the firewall to the destination.
A channel is from the originating device to the firewall. B channel is from the firewall to the destination. The proxy is just telling you that it can't make a connection. As long as the client device keeps trying to send via the proxy this will happen. Making a deny packet filter to drop this traffic will stop the proxy message from appearing.
-James Carson
WatchGuard Customer Support
James: Thanks, but I seek a lot more than an explanation of this particular instance.
I seek documentation explaining ALL the various nomenclature used in these "Connection timed out" error messages.
For example, curly braces versus square braces ({} vs []); upper case versus lower case (B vs c); the exclamation mark, bang or screech (!) which I assume is the logic operator NOT; and all the letters used, concatenation versus individual, and their positional meaning.
It's the old story: Hand a man a fish and he'll be back tomorrow for more. Teach a man to fish and his wife will never see him again.
I seek documentation.
@ACO
You can find the full log catalog here, which explanations for most log messages:
https://www.watchguard.com/help/docs/fireware/12/en-US/log_catalog/Log-Catalog_v12_8.pdf
It's update for every major release, meaning a new one will come around for 12.9, etc.
Specific syntax likely comes down to whomever wrote that specific segment of the system, or if an open source library/application is in use, not all flags are necessarily documented (some even include responses from remote servers, which can contain anything.)
In the case of a proxy log like:
2022-01-01 01:00:00 pxy 0x8220e0-5836 connect failed Connection timed out 420: 10.0.0.2:58925 -> 62.109.230.119:443 [A txr] {B } | 421: 203.0.113.1:58925 -> 198.51.100.99:443 [!B c] {B}[P] Debug 2022-01-01 01:00:00 https-proxy 0x8220e0-5836 420: 10.0.0.2:58925 -> 62.109.230.119:443 [A txr] {B } | 421: 203.0.113.1:58925 -> 198.51.100.99:443 [!B fc] {B}[P]: failed to connect B channel DebugThe key bits will be:
0x8220e0-5836= Connection ID. all debug logs about this specific connection will contain this string10.0.0.2:58925 -> 62.109.230.119:443 [A txr] {B }= Connection between the client and firebox.203.0.113.1:58925 -> 198.51.100.99:443 [!B fc] {B}[P]= Connection between the firebox and server.The brackets are connection flags, and for the most part are the same that you'll see in TCPDUMP.
If you're trying to dig further into the actual connection, I'd suggest taking a packet capture of it and looking at it in a program like Wireshark. The information on the full capture will generally be much more useful than the snippit of a log line itself.
-James Carson
WatchGuard Customer Support
The same catalog Bruce_Briggs already provided and it still doesn't contain either the "Connection timed out" error message or an explanation of the syntax used.
I'm not trying to be a butt-head (although some would point out that it seems to be a natural talent of mine) but I find it odd that WatchGuard -- a company that has been in business for at least 30 years -- has yet to standardize code, documentation and syntax.
I fully understand that outside systems may provide an error response. Lack of emulating the WatchGuard standards would be entirely expected. I'd expect WatchGuard to indicate somehow though that the error message is from an outside source.
Software as old as this, even as bits and pieces evolve, doesn't deviate much from its roots which means the developers' message syntax is also likely to not change much. It is manageable. It is something the Technical Writers should be able to keep up with feedback from Technical Support. It adds value and, at least in theory, cuts down on support cases.
Thanks for trying. The bottom line, appropriately placed here at the bottom line, is that what I seek is simply unavailable unless I get access to all the source code.