1000x WAN Traffic increase

MindfulCoyote

Also, I added a rule in my firewall, and it doesn't seem to work.
I added the ip
23.67.253.163, .167, .168 to the "Spammer_Hacker" alias
23.57.253.0/24 to the "Spammer_Network" alias
But it doesn't seem to block the traffic.
Attached are my rulesets and my current traffic graph

It's probably still in the state table. Try: Menu; Diagnostics; Show States; Reset States; "Reset"

MindfulCoyote

[quote]
I'm assuming the "(Bad address)" is when I disabled it.
clog: ERROR: could not write output (Bad address)

[/quote]

My bad, I should have said "cat /var/log/havp/havp.log"

Ok, that log seems reasonable enough. Maybe it's clamav, try:

cat /var/log/clamav/clamav.log

newburns

Resetting the states seems to have done it.
However, it appears that HAVP really isn't doing too much of anything
With my workflow being:
Internet >> Snort >> pfBlocker >> Squidguard >> Squid >> Client
I'm thinking it may be best to uninstall HAVP. There seems to be a lot of issues with it from people on the forums.
I don't believe there are any alternatives

newburns

clamav.log is empty.
Does it need to be running in order for it to generate logs, or are the old logs saved ?

MindfulCoyote

@newburns:

Resetting the states seems to have done it.

Bear in mind that blocking that IP address was only as a temporary diagnostic and will likely prevent HAVP from functioning correctly once, er, it is, er, functioning correctly…

@newburns:

clamav.log is empty.
Does it need to be running in order for it to generate logs, or are the old logs saved ?

Yes, it needs to be running. And to properly diagnose it's error the temporary block(s) should be removed. There may also be additional logs in each directory:

ls /var/log/havp

and

ls /var/log/clamav

stephenw10

Hmm, curiouser and curiouser. ;)

Putting a firewall rules on the WAN interface will not block any traffic that is initiated by HAVP. Firewall rules on WAN only block new incoming connections. If you want to block new outgoing connection, like this, you need to use a floating rule.

Just to be perfectly clear you didn't respond to my question about other interfaces you have. How many interfaces do you have? Have you check the RRD graphs for those interfaces to make sure it's traffic from there?

Steve

newburns

Sorry. I checked the RRD Graph for those interfaces, and none of them were causing the Traffic

You can disregard the WAN2DHCP interface. I was trying to create a Gateway Group for all of my traffic. I have Comcast with a static IP, but apparently the DHCP IP still works as well. Which gives me (2) outbound connections. I was trying to set both as a shared outbound connection for all traffic, giving priority for WANGW, but the deployment did not work out very well. I don't have a good grasp on the workflow.

firewall_summary_1.jpg_thumb

firewall_summary_2.jpg_thumb

firewall_summary_3.jpg_thumb

MindfulCoyote

@stephenw10:

Putting a firewall rules on the WAN interface will not block any traffic that is initiated by HAVP. Firewall rules on WAN only block new incoming connections.

You're not saying that pfSense would allow a two-way connection to be established despite the WAN entry blocking traffic from that IP? That seems counter-intuitive to me. I would have expected the firewall to permit the outbound packets to be sent to the blocked IP but then to block any response coming from the blocked IP. i.e. one-way traffic only. I'd better hit the man pages again…

kpa

@MindfulCoyote:

@stephenw10:

Putting a firewall rules on the WAN interface will not block any traffic that is initiated by HAVP. Firewall rules on WAN only block new incoming connections.

You're not saying that pfSense would allow a two-way connection to be established despite the WAN entry blocking traffic from that IP? That seems counter-intuitive to me. I would have expected the firewall to permit the outbound packets to be sent to the blocked IP but then to block any response coming from the blocked IP. i.e. one-way traffic only. I'd better hit the man pages again…

That's not how stateful tracking works. Pass decisions are made when the first "new" packet is seen. In TCP connections is the initial SYN packet and in UDP or other IP protocols it's the first packet that does not match any existing state. Block rules apply to any packets that are seen but they won't match packets that match an existing state. PfSense allows all outbound connections (as seen from the point of the interface) by default unless you restrict them with floating rules.

MindfulCoyote

@kpa:

@MindfulCoyote:

@stephenw10:

Putting a firewall rules on the WAN interface will not block any traffic that is initiated by HAVP. Firewall rules on WAN only block new incoming connections.

You're not saying that pfSense would allow a two-way connection to be established despite the WAN entry blocking traffic from that IP? That seems counter-intuitive to me. I would have expected the firewall to permit the outbound packets to be sent to the blocked IP but then to block any response coming from the blocked IP. i.e. one-way traffic only. I'd better hit the man pages again…

That's not how stateful tracking works. Pass decisions are made when the first "new" packet is seen. In TCP connections is the initial SYN packet and in UDP or other IP protocols it's the first packet that does not match any existing state. Block rules apply to any packets that are seen but they won't match packets that match an existing state. PfSense allows all outbound connections (as seen from the point of the interface) by default unless you restrict them with floating rules.

I knew firewalls were hard! So it's true that "It ain't ignorance causes so much trouble; it's folks knowing so much that ain't so." I feel quite humbled for misunderstanding such a fundamental attribute of pfSense.

So my instructions to the OP to enter a temporary diagnostic rule should have been:
"Add two floating rules, one to block traffic destined for 23.67.253.161 and one to block traffic originating from 23.67.253.161. Place them at the top of the list, and reset the state table." They would have been processed before any of his whitelists and ensured that internal processes (as well as LAN clients) didn't set up [rule bypassing] states to that destination.

Of course now that I look for the rule vs. state processing order, it appears everywhere:

"When a rule creates state, the first packet matching the rule creates a "state" between the sender and receiver. Now, not only do packets going from the sender to receiver match the state entry and bypass ruleset evaluation, but so do the reply packets from receiver to sender.
http://www.openbsd.org/faq/pf/filter.html

"Keeping state information allows return traffic for all connections we have initiated to pass back to us."
http://home.nuug.no/~peter/pf/en/long-firewall.html

"This state information allows return traffic for those connections to pass back […]"
http://www.freebsd.org/doc/handbook/firewalls-pf.html

"The reply traffic to connections initiated inside your network is automatically allowed back into your
network by the state table."
The Book https://www.pfsense.org/get-support/index.html#gold-membership

"Once traffic is passed on the interface it enters, an entry in the state table is created, which allows through subsequent packets that are part of that connection. "
https://doc.pfsense.org/index.php/Firewall_Rule_Basics

Those statements are absolutes. I had always been mentally completing them with the phrase "… as long as no rules explicitly block the traffic." when in fact the states are processed ahead of all the rules by default. So... now I will proceed to review all my pfSense rules to see if they are actually doing what I thought they were doing.

stephenw10

Yep, stateful firewall. ;)
That's the reason you have to put block rules on ther LAN side to prevent access from clients. Using floating rules you can do a whole lot more but you can also very easily get it wrong! ::) I don't use floating rules unless it's the only way to achieve something.

Steve

newburns

That's the reason you have to put block rules on ther LAN side to prevent access from clients

So if I have a separate vlan network already setup and functioning, say DEVELOPER. But I didn't want it to have access to the LAN, I would have to add the firewall rule to the LAN or to the DEVELOPER?
I have been adding rules to the originating network, so to create a sort of separate DMZ type of VLAN, I added rules to that network blocking all access to other networks, then adding a pass all filter at the bottom to allow internet access.
Your statement reads to me that I would need to add a block filter on each of the networks for that DMZ network, is that true?

stephenw10

You would add it to the DEVELOPER interface.
All firewall rules (except floating) act on traffic going into the pfSense box. All traffic coming out of the pfSense box is allowed by default.
Looks to me like you're doing it right. Easy enough to lest the rules though, which I assume you're already doing. ;)

Steve

newburns

Is it beneficial to continue troubleshooting the HVAP issue?
I have turned it off and removed the custom rules from Squid Proxy.
It seems that there has been many issues with HAVP, and any new development and/or bug reports will not be fixed in the package.
I can replace the Squid Proxy custom rules and turn it back on to try and generate the logs, but if it will not help, I don't think that it benefits anyone. Also, how do I even know that it is working and scanning all downloaded images and exe like it states. There isn't any verbosity except when a virus is downloaded. And I'm not sure how to even test that.
Anytime I download something that is blocked, it is usually SNORT that blocks it, although I am presented with an HVAP error page. HVAP has not blocked anything before, or blocked anything and logged it to me.

MindfulCoyote

@newburns:

Is it beneficial to continue troubleshooting the HVAP issue?

Well, I'm thinking that your initial concern is now resolved - the WAN traffic has been identified and stopped. If you want to keep working on the HVAP issue(s) perhaps start a new topic in the Packages forum? https://forum.pfsense.org/index.php?board=15.0