Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Harvy66

Pages: [1] 2 3 4 5 ... 155
Firewalling / Re: Google QUIC protocol issues
« on: Today at 12:12:46 pm »
QUIC is a layer 4 protocol that works around poor TCP implementations by streaming over UDP and handling congestion control itself. I assume BBR or something similar will replace this once TCP congestion control algorithms stabilize. A few main goals. Reduce buffer bloat, don't be so sensitive to loss because wifi is lossy, be sensitive to congestion based loss, quickly maximize bandwidth, packet pacing.

HTTP2/SPDY are layer 7 protocols. One of the main benefits is asynchronous multiplexing over a single stream, which allows browsers to stop creating tons of connections due to head-of-queue blocking in HTTP1.1. Lots of TCP connections are bad. Not only eat up more resources, but the have a "thundering herd" problem due to natural synchronization that occurs, and effectively a scaling factor on top of "slow start", making slow start less slow resulting in larger bursts that over congest links.

General Questions / Re: Auto UFS or ZFS?
« on: Today at 12:06:16 pm »
ZFS is new to pfSense and doesn't not have a lot of support about its many features that UFS never had, but overall ZFS is quite bullet proof. When browsing this forum, I saw someone saying they got stuck in a boot loop after a blackout. Probably due to UFS getting corrupted from power loss, something that ZFS wouldn't do.

Traffic Shaping / Re: Multi-WAN and traffic shaping
« on: February 17, 2018, 11:00:01 pm »
The wizard is pretty bad. Other than the default floating rules, I ditched the wizard and did everything myself.

If possible, I'd just use Limiters and setup fq_Codel, which is pain right now but should be a simple check-box soon(tm). Limiters have the benefit of being able to shape ingress, allowing for easy multi-WAN shaping, and fq_Codel is turn-key for nearly every situation with no config other than setting the bandwidth.

Traffic Shaping / Re: floating rule not matching queue
« on: February 17, 2018, 10:56:20 pm »
The destination wasn't Steam, it was the proxy.

Hardware / Re: FTTH setups - connect fiber directly to pfSense
« on: February 17, 2018, 10:54:31 pm »
GPON is a standard line protocol, but there is no standard when it comes to the management features. I doubt your ISP will let you plug in any GPON end-point. A lot of literature from device manufactures is about proprietary and patented features that require both the head device and client to support.

There is no reason why you can't double NAT if you can setup port forwarding.  My ISP allows bridge mode, but I've had them mess it up at least one where they switched me back to "residential gateway" mode. Instead of dealing with them making the mistake again, I just placed pfSense in the DMZ and double NAT. Zero issues.

General Questions / Re: Issue about gateway Latency trouble on Backup CARP
« on: February 15, 2018, 12:51:02 pm »
Looks like buffer bloat. I would recommend the Traffic Shaping forum. You could try enabling FairQ on your WAN interface and check the box on the child queue to enable Codel. This works well enough for most people. For now it gets more complicated quickly beyond this, but soon(tm) it may be as easy as a few check boxes to fix buffer bloat.

Traffic Shaping / Re: Netflix bypassing traffic limiters?
« on: February 15, 2018, 12:48:23 pm »
I'm not saying this is the reason why you're having issue, just saying it's a common reason.

Depends on your latency. Some people are connected to Netflix via an ISP level CDN. While ADSL may have low bandwidth, like 4Mb, your ping may be ultra low relative to your bandwidth. TCP does respond to loss by reducing the send window, but this window has a minimum size of 2 segments. TCP does not manage bandwidth, it manages segments in flight. How this related to bandwidth is Bandwidth=(Window Size)/(RTT delay).  TCP can manipulate the bandwidth indirectly by manipulating the window size, but the RTT is defined by your route. If you have a really low RTT, this makes TCP have a floor on bandwidth that may be too large for your pipe.

Traffic Shaping / Re: Prioritizing instead of Limiting
« on: February 15, 2018, 08:58:54 am »
LIMITING won't be so limiting (punt intended) if it allows % of total bandwidth, rather than a fixed number.

But I disagree with above, Pfsense KNOWS how much bandwidth you got, Traffic Shaper MAKE you to tell it doesn't it?  So OK, SOHO have no guaranteed BW, but since Pfsense makes you input something, at least there is something to go by.

"So OK, SOHO have no guaranteed BW" exactly the problem. Just because you know your car can go 100mph doesn't mean you can do that during rush hour.

Traffic Shaping / Re: Auto Throttle on 2nd WAN
« on: February 15, 2018, 08:57:51 am »
Unstable Internet during saturation is symptom, not a cause. I let Bittorrent consume 99% of my bandwidth with no ill effects.

I recommend trying to enable FairQ on your WAN interfaces, set your bandwidth to some value less than 100%, start with 80%, and enable Codel on the child queue. Just a few check boxes and like 2 minutes to setup. If that isn't good enough for you, look into fq_Codel limiters.

Hardware / Re: [1Gbs WAN users] Tell us your specs and speeds
« on: February 14, 2018, 12:13:59 pm »

What process is using all that CPU? It shouldn't be doing anything special for basic port-to-port traffic.

So after searching a bit, it seems that LAGG in LACP can cause this.
My LACP is using ports igb2 and igb3.

Print in attachment.

From this view it seems that the NIC is causing most of the CPU load, but I wonder why.

I will try to install the driver from Intel tomorow.

Yeah, don't run iperf from pfSense. It's vastly different than running iperf through pfSense.

Traffic Shaping / Re: [FIXED] Traffic Shaping Issues
« on: February 11, 2018, 08:43:35 pm »
For floating rules, catch all should be at the top. For normal rules, catch all should be at the bottom.

Traffic Shaping / Re: Prioritizing instead of Limiting
« on: February 09, 2018, 12:38:57 pm »
You may want to create your own thread for your own situation, but my personal recommendation is to try using Limiters+fq_codel on your WAN interface(s) and see if that solves the issues you're actually having, and not issues you're worried about happening. fq_codel is a great virtually zero-config turn-key solution to most people's woes. It is not turn-key to enable in pfSense yet, but it is technically slated to be completed in 2.4.3, assuming it doesn't get bumped.

Traffic Shaping / Re: QoS VOIP Fluctuating WAN
« on: February 05, 2018, 06:38:35 pm »
You can use limiters and shape on the WAN for ingress.

Hardware / Re: PfSense w/Squid: SSD still ill-advised?
« on: February 05, 2018, 12:26:46 pm »
You really need to know your use case. Many are saying squid gives less than a 1% hit rate for the modern internet. Places where it could really help is caching updates, but these kinds of issues may work better using a special purpose cache. like WSUS for Windows Updates.

Traffic Shaping / Re: QoS VOIP Fluctuating WAN
« on: February 05, 2018, 12:18:24 pm »
There is no reliable way to properly QoS if you don't know how much bandwidth you have. That's like asking someone to plan their expenses without knowing how much money they have.

There are sketchy work-arounds that some people have done in other projects where they ping a known remote target, and if the latency goes up, they reduce the provisioned bandwidth. While this works, it takes time to react. Also, the ping is only correlated with "not enough bandwidth", and it can be difficult to tell if the lack of bandwidth is in regards to ingress or egress.

pfSense has little to no support for this due to the enterprise nature of most users, but I could see this as a useful feature for someone to create a package for. It's a "lesser of two evils" situation.

Pages: [1] 2 3 4 5 ... 155