@stephenw10 said in Trying to Understand Traffic Graphs:

The GUI will become laggy when it has no upstream connectivity. That can be significantly worse on the dashboard where you may have several widgets that try to resolve DNS and check external sources. The update check, support status check, package update check, dyndns entries for example all have to time-out.
However it should not take 3 minutes. That seems more likely all the cpu cycles were being used for some process that could not complete.

Steve

Thank you for explaining the lagging experience Steve! My 3 minutes was a guess estimate...I thought it checked for update when first launching Dashboard though. Dashboard was already opened.

@jasonsmith said in help me out too.:

Below is the output of Pfsense when network fails

This may have been omitted, let's see it.

You can disable MSIX for just em devices so that other PCI devices can still use it.
Add to /boot/loader.conf.local
hw.em.msix=0

If your NIC doesn't support MSIX though it won't be using that anyway.

Steve

@MrSassinak said in No matter what I do, through pfSense I'm getting between 190-200Mb down, and between 400-600Mb up..:

1f418086

That's an Avoton device ID. Are you sure that's not a C2000 CPU? Otherwise it's a C2000 based add on card, which is possible.
It should still pass 1Gb either way unless it's like C2350 without turbo mode.

I just did this and noticed no packet loss pinging the pfSense interface on another VLAN on the same lag. 0% loss pinging at 0.5 second intervals.

192.168.223.1 is the pfSense interface address on lagg0.223

Throughout this ping I created VLAN 1501 on lagg0, OPT17 on lagg0.1501, and enabled/numbered/applied OPT17.

--- 192.168.223.1 ping statistics --- 444 packets transmitted, 444 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.169/0.664/159.686/7.556 ms

At what point does the loss occur?

When you add the VLAN?
When you create the new interface using that VLAN?
When you enable, number, and apply the new interface?

What does the system log show when you add an interface?
Does your switch log show anything interesting?

ETA: No loss pinging through the firewall on removal of the same.

Start with a Multi-WAN configuration. No I don't know of a guide for that specific set of circumstances. It's pretty uncommon.

I would start by just getting the two WANs and the PtP working between the sites, then work on using that PtP as a backup WAN for each side.

If the local router gives you a private IP from it's own DHCP server you can just set the WAN DHCP client to refuse leases from that server.
But you can only do that if the DHCP server that hands you a public lease is not that same IP. Otherwise you've refused all leases 😉
https://docs.netgate.com/pfsense/en/latest/book/interfaces/ipv4-wan-types.html#dhcp

Steve

You should start a new thread for this and detail exactly what you're seeing and what you have done.
There are numerous reason you could be seeing less throughput that you expect. The chances you are hitting the same issue as the OP in this thread are low.

Steve

@stephenw10

Yeah i have been searching for that too, haven't found it yet...

@stephenw10
Good idea, I'll take a look in Wireshark at the result, that might give some clues.

I removed the hardset 1492 MTU from the config and let PPP negotiate the MTU. It still came up 1492 as expected.

Its odd that it only happens in bursts, the first about an hour after resetting the link. I haven't seen anything since.

I've also asked the ISP if there is anything happening at their end just in case.

regards
Tim

Your ISP is not isolating customers on the same subnet. Or they are sending it themselves...

Continuous 1.5Mbps seems extreme.

You can add a firewall rule on WAN to block and not log that which will remove load from the firewall but won't help traffic conditions on your WAN.

I would call the ISP if the source IP there is just some other customer of theirs.

Steve

@glenthenerd said in interface speed:

Rogers is being a pill.

The default ID is "cusadmin" and the password is "password". If the modem is in gateway mode, you use the gateway address. If in bridge mode, use 192.168.100.1.

IIRC, they do have access. When I had some IPv6 problems, earlier this year, the tech put another password on my modem, which I didn't know and I had to call them to reset it.

If first level support can't help, ask for 2nd level. I often do that as I find I'm wasting my time talking to 1st level.

Not beyond send notifications or don't in the current package.

Steve

You could also use 'fetch' which is included for future reference.

@marco-jaeger said in Firewall Rules with Alias only works after rebooting the pfSense:

Check this redmine ticket: https://redmine.pfsense.org/issues/9296

Still, the issue seems far less then 6 month ago - I tend to say : for me : no more issues.

@marco-jaeger said in Firewall Rules with Alias only works after rebooting the pfSense:

our pfSense (Version 2.4.4_P1)

@marco-jaeger : what about simply updating to p3 ? The problem will be probably be less - and don't forget the other problem : less other issues which some are security related.
The issue could not be 'filterdns' related, but more 'ipfw' - and this is based out of FreeBSD....

( I think I saw flying @bmeeks other palm now ^^ )

This has been going on for a few months now and is very likely a SYN-ACK flood, as opposed to a SYN flood.

The source IPs in the SYN packets are forged. Using forged IPs, the attackers can select any set of source (victim) addresses they want. Those victims are flooded with SYN-ACK packets.

Blocking the traffic will only be effective until they choose another victim, which they seem to do regularly.

Sadly, there really isn't much you can do. Search for "Anatomy of a SYN ACK attack". I'd post the link but Akismet is stopping me.

I expect a steam download will cause carnage.

I consider that the ultimate test, steam downloads (uncapped in client) are almost like DDOS'ing your own line 30+ download threads.

Basically when a line is saturated you will get packet loss, there has to be, TCP flow is controlled by the fact packets get dropped. However the issue is which packets are getting dropped and the amount been dropped.

Ingress shaping that prioritises small packets e.g. if working perfect would ensure these pings make it through on the monitoring, so presenting a loss free line, and "all" the dropped packets would be from the TCP downloads having practically no impact on throughput. That's the ideal world scenario.

It is a mystery why some people don't see this issue at all, some see it but can fix it via ingress shaping, others see it but cannot fix it at all (without a massive downstream throttle to prevent it). My theory remains a driver/nic issue been possible, but also hard to rule out the intermediate modem.

If possible the first test would be to swap out pfSense for something else temporarily, and if the behaviour is the same, then it suggests an issue either with modem or ISP side queuing. Certainly I think on the modern internet ingress is far more difficult to manage than egress, egress for me has only ever really compromised QoS in the days when it was tiny like on ADSL. Even then it tended to just skyrocket latency rather than cause significant packet loss. Buffer bloat is bad, but its a lesser evil than a mass of indiscriminate dropped packets.

There is always another option. :)

@stephenw10 Thanks