Which is the best way to know if traffic is blocked by pfSense?

Daniel1972

Hi.
Iam having a little problem with my firewall.

Suddenly docs.google.com can't be reached from my LAN network. but not entire site, only when DNS return an specific IP address (172.217.172.110)

I have workaround this forcing traffic to another docs.google.com Ip address just to gain some time, but I wanna know why & where my traffic is blocked.

I have searched in Firewall logs. But I didn't find any clue there. There was no entry in this logs for the blocked IP.

I know that the problem is somewhere inside pfSense because I can reach 172.217.172.110 from another LAN network behind the same pfSense.

I dont know if there is another place/section/log to look for answers.

Any hint are welcome.

Thanks.

bmeeks

Are you running any packages on your firewall? Any of these three packages can result in blocks of traffic: Snort, Suricata or pfBlockerNG. Are you running any one of these packages?

Daniel1972

Hi.

pfBlockerNG is installed but disabled.

Snort is running, but we disable the blocking option just to try to solve this issue, without success yet.

Thanks for your answer.

Raffi_

@Daniel1972 said in Which is the best way to know if traffic is blocked by pfSense?:

Hi.

pfBlockerNG is installed but disabled.

Snort is running, but we disable the blocking option just to try to solve this issue, without success yet.

Thanks for your answer.

When you disable blocking in Snort, it does not automatically remove any addresses currently being blocked. Make sure you clear the blocks tab.

Daniel1972

Thanks @Raffi_

I have checked that. there is only 3 IP blocked address none of them are of my interest.

I have done some other tests:

1.- Disable snort in the WAN internet access NIC.
2.- Execute some tracert commands.
3.- try to surf to http://172.217.172.110

the tracert command just get stucked at my LAN DG (pfSense address)

Web Browser just show the typical "ERR_CONNECTION_TIMED_OUT" page.

I think there is some rule somewhere in pfSense.

bmeeks

@Daniel1972 said in Which is the best way to know if traffic is blocked by pfSense?:

Thanks @Raffi_

I have checked that. there is only 3 IP blocked address none of them are of my interest.

I have done some other tests:

1.- Disable snort in the WAN internet access NIC.
2.- Execute some tracert commands.
3.- try to surf to http://172.217.172.110

the tracert command just get stucked at my LAN DG (pfSense address)

Web Browser just show the typical "ERR_CONNECTION_TIMED_OUT" page.

I think there is some rule somewhere in pfSense.

To actually attempt a connection to that network you should probably use HTTPS instead of HTTP. Almost everything web-related today (especially Google things) are SSL encrypted and thus URLs will typically start with HTTPS.

I can connect to that IP using Chrome with the URL https://172.217.172.110. However, a site security warning is received as it probably wants a domain name in the URL instead of an IP.

Just to make sure you fully understand. Simply disabling Snort will NOT remove any pre-existing blocks. Any blocks inserted by Snort will remain in place until you manually clear them by going to the BLOCKS tab in Snort and clicking the "Clear" button in the upper right corner of the page.

If you want to be sure neither Snort nor pfBlockerNG is causing the problem, disable both packages (or simply remove them) and then reboot the firewall. See if you can connect then.

Daniel1972

@bmeeks Thanks.

Yes you are right. I had used https instead of http.

But I have a new hint.

I checked this option "Log packets matched from the default pass rules put in the ruleset" in Manage Firewall log to get more visibility.

I have found that the traffic to 172.217.172.110 is sending to internet using a secondary WAN access not configured to outbound traffic.

And if I try to navigate to www.google.com (172.217.172.68) from the same PC the traffic leaves my network using the Default Gateway.

So, I have something ( a fw rule?) routing traffic to different WAN access.

I know WHAT the problem is now! but not WHERE it's located.

Thanks for your help & support.

Iam gonna keep searching.

Daniel1972

@Daniel1972

Well, I guess I solve it. But Iam not happy with the solution.

This second internet access was configured, and after unchecked, to use 172.217.172.110 has Monitor IP address.

I have remove that IP address and then the packages start to route ok again.

Iam not happy because this behavior appears only in one of my LANs behind pfSense. Let's say LAN1.

But in the other LAN, let's say LAN2 this behavior didn't happend.

And then, why one of my LANs try to route through this seconday WAN access and the other don't?

I don't understand why.

Anyway I solved.

Thanks!

bmeeks

@Daniel1972 said in Which is the best way to know if traffic is blocked by pfSense?:

@Daniel1972

Well, I guess I solve it. But Iam not happy with the solution.

This second internet access was configured, and after unchecked, to use 172.217.172.110 has Monitor IP address.

I have remove that IP address and then the packages start to route ok again.

Iam not happy because this behavior appears only in one of my LANs behind pfSense. Let's say LAN1.

But in the other LAN, let's say LAN2 this behavior didn't happend.

And then, why one of my LANs try to route through this seconday WAN access and the other don't?

I don't understand why.

Anyway I solved.

Thanks!

Why did you not state up front that you had multiple WANs defined? That's far from a typical installation. You need to study multi-WAN setups in the official pfSense documentation available here: https://docs.netgate.com/pfsense/en/latest/multiwan/index.html.

Daniel1972

@bmeeks Iam sorry. I didn't think the problem was there.

We have three WAN access, but only one is used to access the internet.
The others are just used for incoming traffic, not outgoing.

Ok. Iam gonna read about multi-WAN access.

Thanks.

awebster

The reason the problem happened in the first place is because of the monitor address that you used.
pfSense will install a static /32 route for the IP address of the gateway monitor into the routing table, thus forcing all the traffic going to that IP into that link.
You should perhaps use the IP address on the other side of the link as the monitoring address (usually the gateway).