Put in a country block but not seeing anything in the blocked logs

[road hazard]

Was thinking about coming back to Untangle but had a question about geo blocking. On my OPNsense firewall, I got connection attempts all day, every day from mainly Russia, China and Belarus. I could look at the live log in OPNsense and these would scroll by non-stop.

I created the following rule in Untangle:



...and when looking at the Firewall Blocked Events log, I don't see any foreign IPs. The only reason you see that 54.170.120.91 address is I was desperate to see anything popping in there as I wasn't sure if blocked events were even being captured. I added ALLLLLLLL countries except the United States and XL and that finally gave me those 54.170.120.91 IPs.


So the big question is, OPNsense was showing non-stop blocks for IPs from those 3 countries all the time WITHOUT having any geo blocking rules implemented in OPNsense. They were just being intercepted and dropped.

.....It's just weird to me that after months and months of seeing those dropped connections from Russia, China, etc.... after creating that rule, nothing. Unless all the hackers in Russia, China and Belarus gave up a few hours after testing out Untangle?

[sky-knight]

Client Country means connections coming FROM those nations are blocked. So you'd only see blocks in the logs if and only if you have a port forward or bridged connection allowing Internet traffic to impact a service inside your network.

If you're trying to prevent users from connecting to those nations, you need to use Server Country instead.

Note, I don't recommend GeoBlocking at all, it's security theater and simply doesn't provide the protection people think it does. But if you insist, you have it.

But I cannot wait to see how you react when you realize there is no geoip blocking possible with ipv6, which most of the nations in the list you're using use actively.

[road hazard]

Client Country means connections coming FROM those nations are blocked. So you'd only see blocks in the logs if and only if you have a port forward or bridged connection allowing Internet traffic to impact a service inside your network.

If you're trying to prevent users from connecting to those nations, you need to use Server Country instead.

Note, I don't recommend GeoBlocking at all, it's security theater and simply doesn't provide the protection people think it does. But if you insist, you have it.

But I cannot wait to see how you react when you realize there is no geoip blocking possible with ipv6, which most of the nations in the list you're using use actively.

Thank you so much for the reply!!

Yes, I do have a Plex server that forwards port 32400 into my network. The blocks I was seeing in OPNsense were for every port imaginable from these countries.

Well with the Threat Prevention module enabled, I only see a single block in there from when I was testing the eicar site. I just figured that I'd go into the logs and like I saw in OPNsense, I'd see random connections being blocked from these places all over the place.

I had some difficulties when installing Untangle this morning. I think it was user error on my part with getting the network sorted out but once I got it up and running, every time I went into the 'apps' and clicked on ....Web Filter or Bandwidth Control or any of them, I got an "Oops, this isn't here" error (forget the exact wording). So I was able to click on 'install apps' and installed the virus lite one and THEN all of the built in apps started working. I'm just worried that something is broken internally and events aren't getting logged correctly.

And WOW, didn't realize geo blocking with IPv6 wasn't very feasible. Did some quick Googling and you're right. Hmmm.... maybe I'll skip it? Although, I'd like to keep it on for the dumb script kiddies still using IPv4 in Russia. lol ..... or maybe not. I'll think about it.

EDIT: If you don't mind, can you look in your Firewall/Blocked Events report and see if it's also empty or has lots of things in there. With the nature of the internet, and scanners everywhere, it's just weird that I don't see any blocked events

[gravenscroft]

NG Firewall can't process IPv6 traffic through the applications anyway; if something is IPv6-only and has no corresponding IPv4 address, it's functionally bypassed.

Also, Intrusion Prevention runs before anything else in the application stack and if it blocks some inbound traffic, then the Firewall app never sees it anyway.

[road hazard]

NG Firewall can't process IPv6 traffic through the applications anyway; if something is IPv6-only and has no corresponding IPv4 address, it's functionally bypassed.

Also, Intrusion Prevention runs before anything else in the application stack and if it blocks some inbound traffic, then the Firewall app never sees it anyway.

I just realized you responded to my other post too .....thanks! It really means a lot to have employees in here answering questions!

I tested out Untangle before, and paid for a yearly home plan, but let it lapse due to some odd problems I was having with Untangle. I -LOVE- the reporting in Untangle and decided to give it another go and am still 'kicking the tires' on it.

IPS dumping packets before they make it to the firewall (and not showing up in the logs there) makes sense but when I go into the Intrusion Detection logging area, I don't see hardly anything in there. Over a 24 hour period, other than some tests I carried out, I didn't see any logs for dropped traffic in the Intrusion Detection logs. It's like nobody is scanning my IP address, which I doubt because in OPNsense, it's non-stop activity like this:



Just wondering why I don't see non-stop denies for this traffic anywhere in Untangle.

[gravenscroft]

I just realized you responded to my other post too .....thanks! It really means a lot to have employees in here answering questions!

You're quite welcome. There are a few of us who sort of patrol the place, making sure things are going smoothly.

Just wondering why I don't see non-stop denies for this traffic anywhere in Untangle.

The way the internet is today, anything that has a public-facing IP address is constantly being scanned, poked, prodded, &c. By default, NG Firewall doesn't log anything that's blocked by layer-3 policy, which includes Filter Rules, Access Rules, and the general NATting-firewall-ness of the device itself; that kind of logging generates a ton of events which are largely meaningless. (I worked in Support for a time and if I'm honest, enabling that part of the logs only served to make people paranoid once they saw the sheer volume of scans and things like that.)

If you really want to see them, the option lives in Config > Network > Advanced > Options, at the very bottom: 'log blocked sessions'. I don't recommend enabling that at all, but if you do, note that it creates a lot of Reporting and will consume hard drive space pretty quickly.

[sky-knight]

road hazard My Firewall App does have some geo-blocking rules in it defending my RMM. I don't expect it to actually increase security, it just cleans up some logs and makes investigations a little more concise. But before all that, Threat Prevention really eats most of the traffic. And yes, it does stop things, but nowhere near to the degree that Treat Prevention does.

Gravenscroft is also correct in the way NGFW works, we have this multi-layered approach of traffic analysis that goes off all at once, and there's no master log of all things because it'd be incomprehensible.

So layer 1 is the Linux Kernel itself, IPTables being configured to do something. That is your general routing, all your NAT work, and so forth. So if a hostile connection impacts NGFW's WAN interface, and is dropped because the kernel has nothing to do with it, it won't be logged anywhere. This cuts down on a TON of your logging relative to what you're used to on the PFSense side.

Layer 2 is the UVM (Untangle Virtual Machine). This is the huge Java application that is NGFW's heart. This is where all your Untangle apps live. Now within these apps you have two classis of applications, which I'm going to define as other layers.

Layer 3 is the Service Apps, these applications are one per NGFW install and they tend to get at the traffic first. Intrusion Prevention is special here because it has an actual configuration that lets you define if it gets the traffic first, or last and by default it's first.

Layer 4 is the Apps, these are per policy applications and they tend to get at the traffic last. This is where your firewall app lives, and even among them they are HIGHLY competitive. Whichever app says NO to the traffic first is the one that logs the termination, the rest won't.

It helps if you also consider each app as its own separate server monitoring your traffic for different things. Each one has to OK it before it's passed, so figuring out which one nuked it is usually the hardest part of figuring out why a given session was blocked.

[road hazard]

You're quite welcome. There are a few of us who sort of patrol the place, making sure things are going smoothly.



The way the internet is today, anything that has a public-facing IP address is constantly being scanned, poked, prodded, &c. By default, NG Firewall doesn't log anything that's blocked by layer-3 policy, which includes Filter Rules, Access Rules, and the general NATting-firewall-ness of the device itself; that kind of logging generates a ton of events which are largely meaningless. (I worked in Support for a time and if I'm honest, enabling that part of the logs only served to make people paranoid once they saw the sheer volume of scans and things like that.)

If you really want to see them, the option lives in Config > Network > Advanced > Options, at the very bottom: 'log blocked sessions'. I don't recommend enabling that at all, but if you do, note that it creates a lot of Reporting and will consume hard drive space pretty quickly.

Thank you very much for this info! I'll put Untangle back in-line today or Saturday morning and keep on testing.

road hazard My Firewall App does have some geo-blocking rules in it defending my RMM. I don't expect it to actually increase security, it just cleans up some logs and makes investigations a little more concise. But before all that, Threat Prevention really eats most of the traffic. And yes, it does stop things, but nowhere near to the degree that Treat Prevention does.

Gravenscroft is also correct in the way NGFW works, we have this multi-layered approach of traffic analysis that goes off all at once, and there's no master log of all things because it'd be incomprehensible.

So layer 1 is the Linux Kernel itself, IPTables being configured to do something. That is your general routing, all your NAT work, and so forth. So if a hostile connection impacts NGFW's WAN interface, and is dropped because the kernel has nothing to do with it, it won't be logged anywhere. This cuts down on a TON of your logging relative to what you're used to on the PFSense side.

Layer 2 is the UVM (Untangle Virtual Machine). This is the huge Java application that is NGFW's heart. This is where all your Untangle apps live. Now within these apps you have two classis of applications, which I'm going to define as other layers.

Layer 3 is the Service Apps, these applications are one per NGFW install and they tend to get at the traffic first. Intrusion Prevention is special here because it has an actual configuration that lets you define if it gets the traffic first, or last and by default it's first.

Layer 4 is the Apps, these are per policy applications and they tend to get at the traffic last. This is where your firewall app lives, and even among them they are HIGHLY competitive. Whichever app says NO to the traffic first is the one that logs the termination, the rest won't.

It helps if you also consider each app as its own separate server monitoring your traffic for different things. Each one has to OK it before it's passed, so figuring out which one nuked it is usually the hardest part of figuring out why a given session was blocked.

Thanks for the extra details, really helps a lot!! I just got so use to taking periodic looks at the blocked traffic in OPNsense, looking for anything suspicious (which I never found ) that I assumed every NGFW would provide the same level of ultra-detail.

I think I have one last question for either of you..... I made this post https://forums.edge.arista.com/forum...tten-correctly and just wanted somebody to verify I did it right. Multiplayer is working perfectly on the Switch now, just want to make sure I have it locked down as tightly as possible.

Thank you both!!!

[gravenscroft]

Layer 4 is the Apps, these are per policy applications and they tend to get at the traffic last. This is where your firewall app lives, and even among them they are HIGHLY competitive. Whichever app says NO to the traffic first is the one that logs the termination, the rest won't.

It helps if you also consider each app as its own separate server monitoring your traffic for different things. Each one has to OK it before it's passed, so figuring out which one nuked it is usually the hardest part of figuring out why a given session was blocked.

This is an extremely good description of the general flow of traffic through NG Firewall. As sky-knight mentions, your NG Firewall is basically two pieces: the layer-3 IPtables/routing stuff and the UVM. Traffic enters NGFW at layer 3, then gets 'passed up' to the UVM: this is where the apps all have their say. If any app blocks traffic, then it's blocked in this roiling chaos of the UVM; it never makes it back out the other side, as it were. Anything that passes inspection in the UVM gets returned 'down' to layer 3, where it continues on to wherever it was going. You can think of it sort of like airport security: you enter the airport, then you're inspected for contraband (like adult websites or connections to rogue nations), and only after you're approved can you proceed to your aircraft.

[road hazard]

This is an extremely good description of the general flow of traffic through NG Firewall. As sky-knight mentions, your NG Firewall is basically two pieces: the layer-3 IPtables/routing stuff and the UVM. Traffic enters NGFW at layer 3, then gets 'passed up' to the UVM: this is where the apps all have their say. If any app blocks traffic, then it's blocked in this roiling chaos of the UVM; it never makes it back out the other side, as it were. Anything that passes inspection in the UVM gets returned 'down' to layer 3, where it continues on to wherever it was going. You can think of it sort of like airport security: you enter the airport, then you're inspected for contraband (like adult websites or connections to rogue nations), and only after you're approved can you proceed to your aircraft.

Makes it even easier to understand, thanks!

Crazy question.... lets say I set up an app to listen on port 8000 and forgot to create a firewall port forward rule for it. Will that traffic show up in the blocked firewall events or be screened out at the front door and not even logged? In other words, how does Untangle know if incoming traffic is 'safe' to pass on up the chain so it can show up in a log as being legitimately blocked or if it's malicious or background garbage that isn't worth the time of day?

And if you have time before you call it a day, I made a post over in the 'Reports' section. I think I broke something.

[gravenscroft]

…how does Untangle know if incoming traffic is 'safe' to pass on up the chain so it can show up in a log as being legitimately blocked or if it's malicious or background garbage that isn't worth the time of day?

All incoming traffic is blocked by default at layer 3, which would appear in Reports > Network reports if you've enabled blocked sessions in Config > Network > Advanced > Options. If you haven't, those events aren't logged at all; they're just blocked silently.

The only way incoming traffic would ever be scanned by the applications is if you've created a Port Forward Rule for that traffic. In that case, anything that wasn't also bypassed would be evaluated by the apps.

[road hazard]

All incoming traffic is blocked by default at layer 3, which would appear in Reports > Network reports if you've enabled blocked sessions in Config > Network > Advanced > Options. If you haven't, those events aren't logged at all; they're just blocked silently.

The only way incoming traffic would ever be scanned by the applications is if you've created a Port Forward Rule for that traffic. In that case, anything that wasn't also bypassed would be evaluated by the apps.

I think the puzzle in my brain is finally complete ..... the information you and sky-knight have provided brought it all together. Sky-knight's detailed explanation and your comments about how incoming traffic would be scanned "if a port forward was created" made everything click. I was worried that if I -did- create a port forward for application X on say.... tcp/23000.... Untangle would never log it because it wasn't...."worthy" of being logged. But now that I know it's as easy as just ticking on 'log blocked sessions' and creating the port forward rule, I'm good to go.

Thank you both for the information!

[JBHorner]

But I cannot wait to see how you react when you realize there is no geoip blocking possible with ipv6, which most of the nations in the list you're using use actively.

Do you mean on NGFW? ipv6 geoip blocking does work? Provided the GeoIP database is somewhat accurate, other solutions (OPNSense, pfSense) do block IPV6 traffic to blocked countries.. (The flaw with IPV6, and in some cased IPV4 as well is the accuracy of the GeoIP databases.)

Also, the use case for having outbound GeoIP blocking is to bring awareness through logging, as well as blocking. The value against the two is based on the security posture of the organization. If one has internal devices accessing hosts in a blocked country, it brings awareness in such a way that it can be investigated further if necessary. (Blocking is an added benefit.) On my own personal network, I have a device that was attempting to access a host in China. It was probably innocuous, but it might not have been. If there has been some type of malware that is on a device that is "phoning home," and home happens to be in a country that is blocked/logged, at a minimum it can be evaluated. Blocking/logging access to Tor network nodes and known VPN hosts adds more safety.

Is this perfect? No way. I think that's the point that was made. But it is a level of risk mitigation. The sad reality is that there is no perfect solution...just a bunch of cobbled together solutions that change the odds favorably.

[sky-knight]

Do you mean on NGFW? ipv6 geoip blocking does work? Provided the GeoIP database is somewhat accurate, other solutions (OPNSense, pfSense) do block IPV6 traffic to blocked countries.. (The flaw with IPV6, and in some cased IPV4 as well is the accuracy of the GeoIP databases.)

As far as I know none of the apps in NGFW process v6 at all. The platform can route and bridge v6 packets, but the apps won't process it. This includes the firewall app.

As for the rest, you're right. GeoIP has value in logging, because it brings an element to the reporting on traffic. But blocking based on source or destination nation rarely makes sense.