*RANT* Why pfsense is popular
-
other ideas (without commands sorry as I been up all night).best to try these step by step one at a time, and retest in each step.
Disable energy efficient ethernet.
Disable (at least temporarily checksum offloading on the NIC).
Reduce network queues to 1, this to make sure no packet ordering issues causing problems or driver bugs.
Disable TSO/RSO if enabled.
Disable interrupt moderation on NIC if enabled.
If powerd is enabled set to the performance mode or disable it.Its unlikely to be a widescale pfsense issue, there would be many complaints if it was, its either a bug that only kicks in a specific scenario which you hitting or a compatibility issue whether it be hardware or isp config.
WOW has a known issue where if nagle is enabled (Delayed acks) it will show high lag because it uses tcp not udp for the game packets. But pfsense as the router doesnt control nagle for client LAN devices, however just in case you can disable nagle on pfsense side via this shell command.
'sysctl net.inet.tcp.delayed_ack=0'
-
What does http://us-looking-glass.battle.net/ show from realm your on to the your IP?
Lets see a sniff of this problem.
So put pfsense behind your GF device in a double nat.. Do you have the problem then vs replacement and the vlan tagging your doing..
Lets see your looking glass traces with your GF and Pfsense and then your untangle - the one thing that would be most likely changing would be your IP.. Are you on the same netblock when you swap out devices.. Your routing could be completely different based upon network your on with google..
if your saying untangle does not have the problem - lets see sniff on untangle wan with it working good, and then sniff on pfsense wan with it bad..
-
What does http://us-looking-glass.battle.net/ show from realm your on to the your IP?
Lets see a sniff of this problem.
So put pfsense behind your GF device in a double nat.. Do you have the problem then vs replacement and the vlan tagging your doing..
Lets see your looking glass traces with your GF and Pfsense and then your untangle - the one thing that would be most likely changing would be your IP.. Are you on the same netblock when you swap out devices.. Your routing could be completely different based upon network your on with google..
if your saying untangle does not have the problem - lets see sniff on untangle wan with it working good, and then sniff on pfsense wan with it bad..
I was going to try untangled but I can't set the priority bit so had to bypass that set of testing….
Here is the Looking Glass out put and it doesn't look good....
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3001ms23/12/2017 15:25:10 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3002ms23/12/2017 15:25:10 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 24.105.30.2 (24.105.30.2) 0.562 ms 1.036 ms 1.056 ms
2 * * *
3 137.221.66.2 (137.221.66.2) 1.382 ms 1.441 ms 1.505 ms
4 137.221.68.66 (137.221.68.66) 1.315 ms 1.344 ms 1.387 ms
5 137.221.68.32 (137.221.68.32) 0.838 ms 1.052 ms 1.066 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *23/12/2017 15:25:10 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 24.105.30.2 (24.105.30.2) 1.408 ms 1.414 ms 1.429 ms
2 * * *
3 137.221.66.2 (137.221.66.2) 1.288 ms 1.345 ms 2.723 ms
4 137.221.68.66 (137.221.68.66) 1.308 ms 1.331 ms 1.356 ms
5 137.221.68.32 (137.221.68.32) 0.869 ms 0.906 ms 1.060 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *23/12/2017 15:25:10 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 Blizzard (Blizzard) 0.739 ms 0.757 ms 0.803 ms
2 * * *
3 137.221.66.8 (137.221.66.8) 2.093 ms 2.147 ms 2.226 ms
4 137.221.69.70 (137.221.69.70) 2.042 ms 2.064 ms 2.090 ms
5 137.221.69.34 (137.221.69.34) 1.720 ms 1.810 ms 1.820 ms
6 * * *
7 * * *
8 * * *
9 192-119-18-202.mci.googlefiber.net (192.119.18.202) 31.579 ms 31.618 ms 31.682 ms
10 192-119-18-184.mci.googlefiber.net (192.119.18.184) 32.038 ms 32.012 ms 32.041 ms
11 ae7.ar02.mci102.googlefiber.net (192.119.17.69) 32.005 ms 31.962 ms 31.975 ms
12 23-255-225-17.mci.googlefiber.net (23.255.225.17) 32.105 ms 32.099 ms 31.998 ms
13 23-255-225-19.mci.googlefiber.net (23.255.225.19) 32.483 ms 32.531 ms 32.534 ms
14 * * *
15 * * *23/12/2017 15:25:15 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2998ms23/12/2017 15:25:16 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 Blizzard (Blizzard) 0.953 ms 0.990 ms 1.068 ms
2 * * *
3 137.221.66.8 (137.221.66.8) 1.935 ms 2.028 ms 2.073 ms
4 137.221.69.70 (137.221.69.70) 1.863 ms 1.971 ms 1.992 ms
5 137.221.69.34 (137.221.69.34) 1.717 ms 1.729 ms 1.733 ms
6 * * *
7 * * *
8 * * *
9 192-119-18-202.mci.googlefiber.net (192.119.18.202) 31.793 ms 31.835 ms 31.935 ms
10 192-119-18-184.mci.googlefiber.net (192.119.18.184) 33.210 ms 32.071 ms 32.099 ms
11 ae7.ar02.mci102.googlefiber.net (192.119.17.69) 32.061 ms 31.990 ms 31.974 ms
12 23-255-225-17.mci.googlefiber.net (23.255.225.17) 32.255 ms 32.265 ms 32.005 ms
13 23-255-225-19.mci.googlefiber.net (23.255.225.19) 32.461 ms 32.673 ms 32.565 ms
14 * * *
15 * * *23/12/2017 15:25:20 UTC
MTR:
Start: Sat Dec 23 15:25:10 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- 24.105.30.2 0.0% 10 0.6 0.7 0.5 0.8 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.2 0.0% 10 1.3 1.4 1.3 1.5 0.0
4.|-- 137.221.68.66 0.0% 10 1.2 1.3 1.2 1.3 0.0
5.|-- 137.221.68.32 0.0% 10 1.0 2.8 0.9 11.5 3.9
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 15:25:10 UTC
MTR:
Start: Sat Dec 23 15:25:10 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- 24.105.30.2 0.0% 10 0.6 0.7 0.5 1.3 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.2 0.0% 10 1.4 1.3 1.2 1.4 0.0
4.|-- 137.221.68.66 0.0% 10 1.1 1.3 1.1 1.4 0.0
5.|-- 137.221.68.32 0.0% 10 1.0 4.5 1.0 35.6 10.9
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 15:25:10 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms23/12/2017 15:25:21 UTC
MTR:
Start: Sat Dec 23 15:25:15 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- Blizzard 0.0% 10 2.4 2.7 0.5 7.9 2.8
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.8 0.0% 10 2.1 2.1 2.1 2.2 0.0
4.|-- 137.221.69.70 0.0% 10 2.0 2.6 1.9 7.2 1.5
5.|-- 137.221.69.34 0.0% 10 41.3 6.6 1.7 41.3 12.4
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 192-119-18-202.mci.googlefiber.net 0.0% 10 31.5 31.6 31.5 31.7 0.0
10.|-- 192-119-18-184.mci.googlefiber.net 0.0% 10 32.3 32.2 32.0 33.0 0.0
11.|-- ae7.ar02.mci102.googlefiber.net 0.0% 10 32.0 32.1 32.0 32.1 0.0
12.|-- 23-255-225-17.mci.googlefiber.net 0.0% 10 32.1 32.1 32.0 32.2 0.0
13.|-- 23-255-225-19.mci.googlefiber.net 0.0% 10 32.6 32.5 32.5 32.6 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 15:25:15 UTC
MTR:
Start: Sat Dec 23 15:25:16 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- Blizzard 0.0% 10 0.8 0.6 0.6 0.8 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.8 0.0% 10 2.1 2.0 1.9 2.2 0.0
4.|-- 137.221.69.70 0.0% 10 1.9 2.6 1.9 7.5 1.7
5.|-- 137.221.69.34 0.0% 10 9.8 3.6 1.7 9.8 3.2
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 192-119-18-202.mci.googlefiber.net 0.0% 10 31.6 31.9 31.5 33.5 0.6
10.|-- 192-119-18-184.mci.googlefiber.net 0.0% 10 32.2 32.5 32.1 33.9 0.5
11.|-- ae7.ar02.mci102.googlefiber.net 0.0% 10 32.1 32.1 32.0 32.2 0.0
12.|-- 23-255-225-17.mci.googlefiber.net 0.0% 10 32.1 32.1 32.1 32.2 0.0
13.|-- 23-255-225-19.mci.googlefiber.net 0.0% 10 32.5 32.5 32.5 32.5 0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 15:25:16 UTC
-
So what is the perceived issue there?
If you want your WAN port to respond to pings you have to enable a firewall rule on WAN passing ICMP source any dest WAN address.
All unsolicited inbound traffic is blocked by default. Even pings.
-
So what is the perceived issue there?
If you want your WAN port to respond to pings you have to enable a firewall rule on WAN passing ICMP source any dest WAN address.
All unsolicited inbound traffic is blocked by default. Even pings.
Ok I had forgotten about that…..
Why do the first couple pings/tracert bottom out and the last few complete as normal????
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms23/12/2017 20:06:53 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.--- MYEXTIP ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms23/12/2017 20:06:53 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 24.105.30.2 (24.105.30.2) 1.277 ms 1.879 ms 1.896 ms
2 * * *
3 137.221.66.2 (137.221.66.2) 1.372 ms 1.432 ms 1.502 ms
4 137.221.68.66 (137.221.68.66) 1.236 ms 1.259 ms 1.288 ms
5 137.221.68.32 (137.221.68.32) 0.955 ms 0.974 ms 0.978 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *23/12/2017 20:06:53 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 24.105.30.2 (24.105.30.2) 1.390 ms 1.501 ms 1.520 ms
2 * * *
3 137.221.66.2 (137.221.66.2) 1.234 ms 1.299 ms 1.365 ms
4 137.221.68.66 (137.221.68.66) 1.104 ms 1.200 ms 1.305 ms
5 137.221.68.32 (137.221.68.32) 1.022 ms 1.049 ms 1.058 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *23/12/2017 20:06:53 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 Blizzard (Blizzard) 0.535 ms 0.597 ms 0.706 ms
2 * * *
3 137.221.66.8 (137.221.66.8) 2.048 ms 2.163 ms 2.208 ms
4 137.221.69.70 (137.221.69.70) 1.980 ms 2.014 ms 2.036 ms
5 137.221.69.34 (137.221.69.34) 2.021 ms 2.028 ms 2.037 ms
6 * * *
7 * * *
8 * * *
9 192-119-18-202.mci.googlefiber.net (192.119.18.202) 31.584 ms 31.615 ms 31.620 ms
10 192-119-18-186.mci.googlefiber.net (192.119.18.186) 32.917 ms 32.072 ms 32.102 ms
11 ae7.ar02.mci102.googlefiber.net (192.119.17.69) 31.954 ms 31.887 ms 32.099 ms
12 23-255-225-17.mci.googlefiber.net (23.255.225.17) 32.098 ms 32.108 ms 32.009 ms
13 23-255-225-19.mci.googlefiber.net (23.255.225.19) 32.469 ms 32.482 ms 32.513 ms
14 MYEXTIP (MYEXTIP) 33.482 ms 33.679 ms 33.665 ms23/12/2017 20:06:59 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.
64 bytes from MYEXTIP: icmp_seq=1 ttl=48 time=33.5 ms
64 bytes from MYEXTIP: icmp_seq=2 ttl=48 time=33.6 ms
64 bytes from MYEXTIP: icmp_seq=3 ttl=48 time=33.5 ms
64 bytes from MYEXTIP: icmp_seq=4 ttl=48 time=33.6 ms--- MYEXTIP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 33.537/33.593/33.660/0.049 ms23/12/2017 20:06:59 UTC
TRACEROUTE:
traceroute to MYEXTIP (MYEXTIP), 15 hops max, 60 byte packets
1 Blizzard (Blizzard) 0.746 ms 0.808 ms 0.930 ms
2 * * *
3 137.221.66.8 (137.221.66.8) 2.060 ms 2.141 ms 2.220 ms
4 137.221.69.70 (137.221.69.70) 1.963 ms 1.989 ms 2.014 ms
5 137.221.69.34 (137.221.69.34) 1.690 ms 2.297 ms 2.310 ms
6 * * *
7 * * *
8 * * *
9 192-119-18-202.mci.googlefiber.net (192.119.18.202) 31.505 ms 31.493 ms 31.482 ms
10 192-119-18-186.mci.googlefiber.net (192.119.18.186) 32.280 ms 31.942 ms 31.965 ms
11 ae7.ar02.mci102.googlefiber.net (192.119.17.69) 31.920 ms 31.906 ms 31.952 ms
12 23-255-225-17.mci.googlefiber.net (23.255.225.17) 31.980 ms 31.952 ms 32.224 ms
13 23-255-225-19.mci.googlefiber.net (23.255.225.19) 32.474 ms 32.494 ms 32.464 ms
14 MYEXTIP (MYEXTIP) 33.655 ms 33.520 ms 33.520 ms23/12/2017 20:07:01 UTC
PING:
PING MYEXTIP (MYEXTIP) 56(84) bytes of data.
64 bytes from MYEXTIP: icmp_seq=1 ttl=48 time=33.5 ms
64 bytes from MYEXTIP: icmp_seq=2 ttl=48 time=33.6 ms
64 bytes from MYEXTIP: icmp_seq=3 ttl=48 time=33.5 ms
64 bytes from MYEXTIP: icmp_seq=4 ttl=48 time=33.7 ms--- MYEXTIP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 33.519/33.611/33.713/0.081 ms23/12/2017 20:07:03 UTC
MTR:
Start: Sat Dec 23 20:06:53 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- 24.105.30.2 0.0% 10 10.1 1.8 0.4 10.1 3.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.2 0.0% 10 1.2 1.3 1.1 1.4 0.0
4.|-- 137.221.68.66 0.0% 10 1.4 1.3 1.2 1.4 0.0
5.|-- 137.221.68.32 0.0% 10 1.0 4.9 0.9 29.9 9.4
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 20:06:53 UTC
MTR:
Start: Sat Dec 23 20:06:53 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- 24.105.30.2 0.0% 10 0.8 0.8 0.5 1.8 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.2 0.0% 10 1.1 1.3 1.1 1.4 0.0
4.|-- 137.221.68.66 0.0% 10 1.4 1.6 1.2 4.1 0.7
5.|-- 137.221.68.32 0.0% 10 1.0 1.4 0.9 5.4 1.3
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.023/12/2017 20:06:53 UTC
MTR:
Start: Sat Dec 23 20:06:59 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- Blizzard 0.0% 10 0.5 0.6 0.4 0.8 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.8 0.0% 10 2.0 2.0 1.9 2.2 0.0
4.|-- 137.221.69.70 0.0% 10 2.0 1.9 1.9 2.1 0.0
5.|-- 137.221.69.34 0.0% 10 1.7 2.9 1.7 12.8 3.4
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 192-119-18-202.mci.googlefiber.net 0.0% 10 31.6 31.6 31.5 31.7 0.0
10.|-- 192-119-18-186.mci.googlefiber.net 0.0% 10 32.1 32.1 31.9 32.7 0.0
11.|-- ae7.ar02.mci102.googlefiber.net 0.0% 10 32.0 32.0 31.9 32.3 0.0
12.|-- 23-255-225-17.mci.googlefiber.net 0.0% 10 32.0 32.1 32.0 32.2 0.0
13.|-- 23-255-225-19.mci.googlefiber.net 0.0% 10 32.4 32.5 32.4 32.5 0.0
14.|-- MYEXTIP 0.0% 10 33.7 33.6 33.0 33.8 0.023/12/2017 20:06:58 UTC
MTR:
Start: Sat Dec 23 20:07:00 2017
HOST: Blizzard Loss% Snt Last Avg Best Wrst StDev
1.|-- Blizzard 0.0% 10 0.5 0.6 0.4 0.7 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- 137.221.66.8 0.0% 10 2.1 2.1 2.0 2.2 0.0
4.|-- 137.221.69.70 0.0% 10 2.0 2.0 1.9 2.2 0.0
5.|-- 137.221.69.34 0.0% 10 1.9 1.8 1.7 2.0 0.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 192-119-18-202.mci.googlefiber.net 0.0% 10 31.6 31.6 31.5 31.6 0.0
10.|-- 192-119-18-186.mci.googlefiber.net 0.0% 10 32.0 32.1 32.0 32.3 0.0
11.|-- ae7.ar02.mci102.googlefiber.net 0.0% 10 32.0 32.0 32.0 32.1 0.0
12.|-- 23-255-225-17.mci.googlefiber.net 0.0% 10 32.1 32.1 32.0 32.7 0.0
13.|-- 23-255-225-19.mci.googlefiber.net 0.0% 10 32.5 32.5 32.4 32.5 0.0
14.|-- MYEXTIP 0.0% 10 33.8 33.6 33.5 33.8 0.023/12/2017 20:07:00 UTC
-
Because not every device will respond to traceroute.
Probably more than you want to know about traceroute: https://en.wikipedia.org/wiki/Traceroute
(I still don't see any issues there.)
-
If you want pfsense to show up on a udp traceroute then you have to reject the UDP ports used…. But with Derelict here.. Sure doesn't look like any sort of problem.. 30 something ms looks way lower than that 300-1500 you were stating..
Where are you seeing these numbers... Post a screenshot of these numbers so user here that run wow can help you... I would be more than happy to fire up a trial to just test the latency numbers, etc.
If I knew exactly how your seeing these numbers so I could try and duplicate them so we have apples to apples.. While not on google fiber.. I wish I am using pfsense and have been for really since it came out.. There is nothing that would cause such latency to be added.. Pfsense can not tell packet from your game from packet to websites, or a video packet or a voip packet - they are all just packets that is allows or doesn't allow, etc. It sure doesn't say you know what - let me hold these for 300ms to piss of the game player..
Do a simple sniff on lan and wan at same time via tcpdump - check delay pfsense adds to the packets.. its going to be in the micro seconds..
Here did a simple ping to 8.8.8.8 from lan and sniff on lan and wan at same time.. You can see when my ping hit pfsense lan at 46.907733 and when it left wan at 46.907822 or 89 micro seconds later.. And then you see the answer come back to my host.. .923618 or 15.885 ms later which my ping shows that first ping was 16ms..
The return packet latency was only 0.000035 from the time it hit pfsense wan, to when it was sent out lan to client.. that is 35 micro seconds…
So let us see this sort of sniff with your game traffic going through pfsense and how much latency pfsense ads to this traffic..
-
I to was curious about forwarding latency. This is with NAT and HFSC+Codel
timeout 5 tcpdump -i igb0 -n host 23.255.225.19
timeout 5 tcpdump -i igb1 -n host 23.255.225.19igb1 12:13:22.078057 IP 192.168.1.2 > 23.255.225.19: ICMP echo request, id 33991, seq 1175, length 40
igb0 12:13:22.078071 IP 192.168.101.2 > 23.255.225.19: ICMP echo request, id 25512, seq 1175, length 40 <– 14usigb0 12:13:22.121213 IP 23.255.225.19 > 192.168.101.2: ICMP echo reply, id 25512, seq 1175, length 40
igb1 12:13:22.121226 IP 23.255.225.19 > 192.168.1.2: ICMP echo reply, id 33991, seq 1175, length 40 <-- 13usWhen pinging the LAN interface
HFSC enabled with shaping to 150Mb, my standard
12:38:49.415947 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18212, length 40
12:38:49.415956 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18212, length 40 <-- 9us
12:38:49.415963 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18213, length 40
12:38:49.415972 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18213, length 40 <-- 9us
12:38:49.416269 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18214, length 40
12:38:49.416280 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18214, length 40 <-- 11us
12:38:49.416311 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18215, length 40
12:38:49.416320 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18215, length 40 <-- 9us
12:38:49.416322 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18216, length 40
12:38:49.416332 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18216, length 40 <-- 10us
12:38:49.416334 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18217, length 40
12:38:49.416343 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27900, seq 18217, length 40 <-- 9us
12:38:49.416368 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27900, seq 18218, length 40No shaping enabled on LAN
12:46:40.253820 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34858, length 40
12:46:40.253827 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34858, length 40 <-- 7us
12:46:40.253844 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34859, length 40
12:46:40.253851 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34859, length 40 <-- 7us
12:46:40.253852 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34860, length 40
12:46:40.253859 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34860, length 40 <-- 7us
12:46:40.254158 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34861, length 40
12:46:40.254165 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34861, length 40 <-- 7us
12:46:40.254170 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34862, length 40
12:46:40.254177 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34862, length 40 <-- 7us
12:46:40.254182 IP 192.168.1.2 > 192.168.1.1: ICMP echo request, id 27897, seq 34863, length 40
12:46:40.254189 IP 192.168.1.1 > 192.168.1.2: ICMP echo reply, id 27897, seq 34863, length 40 <-- 7usI should mention that my HP-1810-24G claims 2.3us forwarding latency, so this is within the range of my switch.
P.S. Before you criticize my version number: Uptime 220 Days 16 Hours 11 Minutes 52 Seconds
-
PEBCAK?
-
Just waiting to see OP show us these 300+ms delay Pfsense is adding to the packets as it sends them on..
-
If you want pfsense to show up on a udp traceroute then you have to reject the UDP ports used…. But with Derelict here.. Sure doesn't look like any sort of problem.. 30 something ms looks way lower than that 300-1500 you were stating..
Where are you seeing these numbers... Post a screenshot of these numbers so user here that run wow can help you... I would be more than happy to fire up a trial to just test the latency numbers, etc.
If I knew exactly how your seeing these numbers so I could try and duplicate them so we have apples to apples.. While not on google fiber.. I wish I am using pfsense and have been for really since it came out.. There is nothing that would cause such latency to be added.. Pfsense can not tell packet from your game from packet to websites, or a video packet or a voip packet - they are all just packets that is allows or doesn't allow, etc. It sure doesn't say you know what - let me hold these for 300ms to piss of the game player..
Do a simple sniff on lan and wan at same time via tcpdump - check delay pfsense adds to the packets.. its going to be in the micro seconds..
Here did a simple ping to 8.8.8.8 from lan and sniff on lan and wan at same time.. You can see when my ping hit pfsense lan at 46.907733 and when it left wan at 46.907822 or 89 micro seconds later.. And then you see the answer come back to my host.. .923618 or 15.885 ms later which my ping shows that first ping was 16ms..
The return packet latency was only 0.000035 from the time it hit pfsense wan, to when it was sent out lan to client.. that is 35 micro seconds…
So let us see this sort of sniff with your game traffic going through pfsense and how much latency pfsense ads to this traffic..
And this might be an issue with Gfiber that you might not see, but the Latency I see is in World Of Warcraft….. https://us.battle.net/account/download/ I know you can play for free up to like level 20 but there is an in game latency tracker (ie network status) and for the record currently I'm sitting at 78 ms and I am good with that, but It may change over night for no particular reason.
-
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=13ms TTL=55
Reply from 8.8.8.8: bytes=32 time=13ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=13ms TTL=55Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms[2.4.2-RELEASE][root@AMDRouter.localdomain]/root: tcpdump -i igb1 -n host 8.8.8.8
16:22:38.256111 IP 192.168.1.121 > 8.8.8.8: ICMP echo request, id 1, seq 655, length 40
16:22:38.268953 IP 8.8.8.8 > 192.168.1.121: ICMP echo reply, id 1, seq 655, length 40
16:22:39.257887 IP 192.168.1.121 > 8.8.8.8: ICMP echo request, id 1, seq 656, length 40
16:22:39.270690 IP 8.8.8.8 > 192.168.1.121: ICMP echo reply, id 1, seq 656, length 40
16:22:40.259797 IP 192.168.1.121 > 8.8.8.8: ICMP echo request, id 1, seq 657, length 40
16:22:40.272697 IP 8.8.8.8 > 192.168.1.121: ICMP echo reply, id 1, seq 657, length 40
16:22:41.261709 IP 192.168.1.121 > 8.8.8.8: ICMP echo request, id 1, seq 658, length 40
16:22:41.274687 IP 8.8.8.8 > 192.168.1.121: ICMP echo reply, id 1, seq 658, length 40[2.4.2-RELEASE][root@AMDRouter.localdomain]/root: tcpdump -i igb0.2 -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
16:25:37.069105 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 54453, seq 668, length 64
16:25:37.069432 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 15638, seq 600, length 64
16:25:37.081751 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 54453, seq 668, length 64
16:25:37.081807 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 15638, seq 600, length 64
16:25:38.070788 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 54453, seq 669, length 64
16:25:38.070805 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 15638, seq 601, length 64
16:25:38.083629 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 54453, seq 669, length 64
16:25:38.083710 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 15638, seq 601, length 64
16:25:39.079806 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 15638, seq 602, length 64
16:25:39.087694 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 54453, seq 670, length 64
16:25:39.092626 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 15638, seq 602, length 64
16:25:39.100392 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 54453, seq 670, length 64
16:25:40.094898 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 15638, seq 603, length 64
16:25:40.103248 IP 136.56.55.36 > 8.8.8.8: ICMP echo request, id 54453, seq 671, length 64
16:25:40.107628 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 15638, seq 603, length 64
16:25:40.116073 IP 8.8.8.8 > 136.56.55.36: ICMP echo reply, id 54453, seq 671, length 64 -
And?
-
Now I did some more lloking and some people are putting an Ubiquiti Edge router off the fiber jack then using a switch behind that and here is a bit of code you have to update the POE version with to work with GFiber.
https://github.com/stevejenkins/UBNT-EdgeRouter-Example-Configs/blob/master/Google-Fiber/config.boot.poe
I did look through the code and while I can read it and it is logical in that it has rules being set up for the various ports, not sure I would be able to translate it into pfsense.
-
And?
And there in lies the the issue, I know all the network traffic looks normal, I get it. And currently in games and my latency is sitting at 78 ms which is right where is should be. This is the maddening part. Hence why this started out as a RANT, I needed to scream into the ether and figure why this was happening.
-
https://flyovercountry.org/2014/02/google-fiber-gigabit-speeds-your-router-part-1-vlans/
Looks like those guys have done most of your research for you.
pfSense can NOT set DSCP bits. It can only match on them. You will likely need to do that in a switch between your fiber and the WAN interface as outlined in that blog.
Your RANT against pfSense is misplaced.
ETA:
You might be able to get closer tagging VLAN 2 with VLAN Priority 3 set. https://forum.pfsense.org/index.php?topic=71806.msg619859#msg619859
-
https://flyovercountry.org/2014/02/google-fiber-gigabit-speeds-your-router-part-1-vlans/
Looks like those guys have done most of your research for you.
pfSense can NOT set DSCP bits. It can only match on them. You will likely need to do that in a switch between your fiber and the WAN interface as outlined in that blog.
Your RANT against pfSense is misplaced.
ETA:
You might be able to get closer tagging VLAN 2 with VLAN Priority 3 set. https://forum.pfsense.org/index.php?topic=71806.msg619859#msg619859
Which btw is exactly how I have it set up. I might be a pfsense newb, just not networking technology hardware know just a little bit what i'm talking about newb. Which is why I had explained before that my speed test were normal, sinse with out the VLAN 2 and the VLAN 802.1p bit set to 3, i would get exactly ZILCH.
RANT still firmly in place.
-
Must be you. And your RANT would be better directed at google fiber - you know, the entity you are actually PAYING - for demanding you use their device with zero documentation regarding using others.
Merry Christmas.
-
So are you saying you don't have the switch in front of pfsense like the article Derelict linked to setting the dscp?
-
Merry Christmas!
First, some of this is over my head… but...
Please don't forget - did OP ever provide the sniff of where pfSense injects the additional 300ms packets as requested by Johnpoz (post #27)? Why not?
Derelict IMHO is correct, you need to direct your RANT elsewhere and away form pfSense. You won't as you think it's a pfSense issue. It's not. What about the "other firewall/router x64 solutions", did you RANT at them like you have at pfSense? So far you've indicated the issues are with GFiber and/or the switch you currently have in place.
OP - I think it could have greatly help everyone trying to help you if you indicated your setting of DSCP bits in your original post rather than waiting until post #34. Why now vs the very beginning?
If you want to rant/bitch/complain/whatever, great, but do it with all facts presented vs presenting half facts (waiting until #34 to state DSCP setting).
If you want to flame me - do it, I don't care and won't care for the following reasons:
1. Until you honor Johnpoz's request for info requested in post 27 request. If you ever do.
2. You are now a moving target. The people trying to help you make request, maybe you provide info, maybe not. The when VERY convenient to you, you inform everyone this is how I have it set up - post #34. Where was that detail prior?
3. Did you get on ALL the other boards for the "other firewall/router x64 solutions" (post #1) indicating your RANT with them for the same reasons you gave about pfSense? Again, where was that ever mentioned?
4. Most of my questions are rhetorical as if you truly wanted to help yourself you would have provided info to get to a resolution rather than wait to cherry pick responses or provide (additional) info.
5. Accept the blame yourself as it falls squarely on your shoulders.Personally, I can't take you seriously until ALL the information requested of you IS provided by you. Now just to be sure, don't forget to add the part about - no need now as you have resolved the problem OR how you believe pfSense just doesn't measure up blah blah blah, as now it's convenient time to do so.
-
He seem to attempt to show the latency of pfsense pinging 8.8.8.8 but he did not run the sniffs at the same time, and it seems he has something else pinging 8.8.8.8 as well… But his sniffs the time nor the seq numbers clearly show they were not sniffed at the same time... So from those its not even possible to calc what latency is being added by pfsense for the routing and natting and evaluation of the firewall rules.
-
Must be you. And your RANT would be better directed at google fiber - you know, the entity you are actually PAYING - for demanding you use their device with zero documentation regarding using others.
Merry Christmas.
Never ever did I say I might not be them, I just hadn't gotten to calling local cable company and signing up for a month and remove that possible variable.
Merry Christmas
-
So are you saying you don't have the switch in front of pfsense like the article Derelict linked to setting the dscp?
No i do not have the managed switch sitting in front of the router like the articale from flyovercountry, I have the setup like the KingViper has in the pfsense forum post ( https://forum.pfsense.org/index.php?topic=71806.msg619859#msg619859 ) .
-
Merry Christmas!
First, some of this is over my head… but...
Please don't forget - did OP ever provide the sniff of where pfSense injects the additional 300ms packets as requested by Johnpoz (post #27)? Why not?
Derelict IMHO is correct, you need to direct your RANT elsewhere and away form pfSense. You won't as you think it's a pfSense issue. It's not. What about the "other firewall/router x64 solutions", did you RANT at them like you have at pfSense? So far you've indicated the issues are with GFiber and/or the switch you currently have in place.
OP - I think it could have greatly help everyone trying to help you if you indicated your setting of DSCP bits in your original post rather than waiting until post #34. Why now vs the very beginning?
If you want to rant/bitch/complain/whatever, great, but do it with all facts presented vs presenting half facts (waiting until #34 to state DSCP setting).
If you want to flame me - do it, I don't care and won't care for the following reasons:
1. Until you honor Johnpoz's request for info requested in post 27 request. If you ever do.
2. You are now a moving target. The people trying to help you make request, maybe you provide info, maybe not. The when VERY convenient to you, you inform everyone this is how I have it set up - post #34. Where was that detail prior?
3. Did you get on ALL the other boards for the "other firewall/router x64 solutions" (post #1) indicating your RANT with them for the same reasons you gave about pfSense? Again, where was that ever mentioned?
4. Most of my questions are rhetorical as if you truly wanted to help yourself you would have provided info to get to a resolution rather than wait to cherry pick responses or provide (additional) info.
5. Accept the blame yourself as it falls squarely on your shoulders.Personally, I can't take you seriously until ALL the information requested of you IS provided by you. Now just to be sure, don't forget to add the part about - no need now as you have resolved the problem OR how you believe pfSense just doesn't measure up blah blah blah, as now it's convenient time to do so.
First off dude whatever you are smoking, stop its screwing with your brain. LITERALLY the first paragraph of the first post:
"In my quest to increase my networking knowledge and to have control of my own equipment, I had decided to remove my Google Fiber network box from my network and decided with a single box solution. Yes you can guy a managed switch like the edge router and stick a consumer router behind it (this is a need of having GFiber as you have to set your WAN to VLAN 2 with a 802.11q bit of 3) and be done with it. But after reading and watching many many youtube videos about rolling your own router and most of them were about pfsense, I then focused my video watching to pfsense related videos. "
Yes I realize that I mistype the 802.1p part, but its still in the first part.
Secondly, I honestly have not gotten to the sniff as my weekends are more hectic then a normal work week.
Thrid, my normal access flows just fine, streaming works, live tv works, speed tests are 850-950 Mbps which is normal using the GFiber network box. The ONLY noticeable effect is in game latency in World of Warcraft which can be 300-2500ms, which a normal range of 300-650ms . That being said I have seen it at 50 ms latency in game.
One curious thing, IF i start the game using the GFiber box, then move the cable to the pfsense box my latency in game stays right at 70-80 ms until i log out of the game and come back to play later.
Again please stop smoking whatever dope you are on, since once again you have completely missed the fact I have tried other router software solutions and they do not offer the ability to set the 802.1p bit at all. And yes I have had a conversation with one of the engineering techs and he has submitted a feature request to the coders to add the ability to set that bit. Whether that happens is beyond my control but it is something I've tried to do to remove pfsense as the variable, there just isn't anything I have found that will do that. And sticking a managed switch in the front of pfsense box does NOT remove that variable, just highlights the fact pfsense may not be processing the switch properly.
5. Accept the blame yourself as it falls squarely on your shoulders.
WTF are you smoking.
-
He seem to attempt to show the latency of pfsense pinging 8.8.8.8 but he did not run the sniffs at the same time, and it seems he has something else pinging 8.8.8.8 as well… But his sniffs the time nor the seq numbers clearly show they were not sniffed at the same time... So from those its not even possible to calc what latency is being added by pfsense for the routing and natting and evaluation of the firewall rules.
Holy hell I simply used the same commands that where provided in the examples you all posted in the forum, nothing more nothing less.
-
And sticking a managed switch in the front of pfsense box does NOT remove that variable, just highlights the fact pfsense may not be processing the switch properly.
A packet capture can quickly determine if those bits are set on your traffic.
-
Contrary to some misguided beliefs you all have I really want pfsense to work, the GFiber box is garage for doing any advanced networking in the form of AV and VPN at the router level. I have done what I could before coming to the forums as I knew there would be fan boys of pfsense that would be upset that I challenged the functionality of pfsense. I was merely looking for ideas as to why there would be that much of a difference in in game latency.
I wholeheartedly accept the fact I have done something wrong, I know next to nothing about pfense. Can you say the same about yourselves and pfsense, there is a reason that the current version is 2.4.2-RELEASE-p1 cuz they fk'd up 2.4.2.
I'm trying to create a "general" profile that any GFiber/WOW user can load into pfsense and it just works.
-
And sticking a managed switch in the front of pfsense box does NOT remove that variable, just highlights the fact pfsense may not be processing the switch properly.
A packet capture can quickly determine if those bits are set on your traffic.
From the few help sections I have read there are a couple of ways to do it in pfsense, is there a method you would prefer to see?
-
Diagnostics > Packet Capture
WAN
Generate some traffic.
See if the proper priority is set.
If so, call google. If not, open a bug report.
-
https://flyovercountry.org/2014/02/google-fiber-gigabit-speeds-your-router-part-1-vlans/
Looks like those guys have done most of your research for you.
pfSense can NOT set DSCP bits. It can only match on them. You will likely need to do that in a switch between your fiber and the WAN interface as outlined in that blog.
Your RANT against pfSense is misplaced.
ETA:
You might be able to get closer tagging VLAN 2 with VLAN Priority 3 set. https://forum.pfsense.org/index.php?topic=71806.msg619859#msg619859
I think what he's getting at is he's ranting about the situation and seeing if someone may have some ideas, not so much him being critical.
-
https://flyovercountry.org/2014/02/google-fiber-gigabit-speeds-your-router-part-1-vlans/
Looks like those guys have done most of your research for you.
pfSense can NOT set DSCP bits. It can only match on them. You will likely need to do that in a switch between your fiber and the WAN interface as outlined in that blog.
Your RANT against pfSense is misplaced.
ETA:
You might be able to get closer tagging VLAN 2 with VLAN Priority 3 set. https://forum.pfsense.org/index.php?topic=71806.msg619859#msg619859
I think what he's getting at is he's ranting about the situation and seeing if someone may have some ideas, not so much him being critical.
Thank you Harvey for undestanding
-
I suddenly remembered that WoW measures latency as an aggregate sliding window and the RTT is measured as the time it takes to get a response over TCP. This is a high level "ping". I've seen it report as high as 9,000ms latency, when I knew I had maybe 100ms, but high packet loss. Your latency spikes may not actually be delayed packets, but dropped packets and TCP taking time to resend.
Are you doing any traffic shaping? I ask because pfSense defaults to 50 packet queues when you enable shaping, and 50 may be too small and may cause lost packets under certain loads.
-
deleted because of personal insults
-
Please back off the hostility and profanity.
-
"Holy hell I simply used the same commands that where provided in the examples you all posted in the forum, nothing more nothing less."
I understand that - but you have to run them at the same time ;) Open 2 ssh sessions to pfsense, and run the commands at the same time.. Then ping 8.8.8.8 from a client behind pfsense..
Are you using 8.8.8.8 as a monitor IP for one of your gateways?
If you provide the actual sniff we can see if any dscp is set.. But from the info linked to.. if your not setting dscp then your upload is limited to 10mbps.. Or in other terms watching paint dry.. So yeah if anything else is going on at the time your playing games.. Your upload pipe could get full and latency increase..
You need to set the dscp that your isp requires if you want to remove your isp device.. This has ZERO to do with pfsense.. And no p1 is not because they f'd up 2.4.2.. Such a statement really is not something that will help you get help with your problem.. Is sp1 because they f'd up windows 7? what about sp2 is that because they 'f''d up 7 and sp1 release?
-
I would let this guy figure it out himself (or not).
-
That is one option.. More worried about the next guy coming across the forum and thinking there is something actually wrong, etc. Google for shit and taking shit out of context and next thing you know FUD starts popping up that pfsense is adding 300ms latency, etc.
From that article linked to, which is a bit dated says that upload would be limited to 10mbps.. I would assume that would be easy to see in speedtest, which also something else he never posted just saying it was fine, etc. If I had GF and the upload was not freaking close to gig I would be pretty disappointed ;)
Funny how somehow he is fine with it now at 78ms latency in the game… But how that can change whenever and think its pfsense fault if working fine now, and then doesn't etc.. If working now, and not working later then something is happening at that later time.. Like maybe his upload pipe getting full because no dscp settings and GF is throttling him, etc.
-
I can pretty much promise you this guy isn't here for help. He is here to make a fuss and amuse himself. Evey one who matters knows pfsense doesn't add latency like that.
-
@ kejianshi You are a special kind of stupid. Its morons like you that turn ppl off to new ideas you are nothing more than a troll in the truest sense of the word.
Sorry but I took time off for the holidays and got it resolved, though I have no idea how.
I decided to try and remove one of the 2 final variables. Since I could not try another software option due to GFiber requirements, I decided to get cable internet. Long story short, Once I configured the pfsense router for dual wan and had cable as my primary and GF as the failover, my latency was stable at 70-80 ms. I then switched the roles of primary and secondary wan and latency stayed stable at 70-80 ms. I just disconnected the the cable connection and rebooted the router and still has stable 70-80 ms latency. So whatever happened in setting up the dual WAN interfaces fixed the issue, going on 7 days straight.
My Setup:
A10-8750K
8gb DDR3 ram
60gb ssd
4 port GB intel nic ( 5GB ports total)
LGS 318Pdual port LAG between the router and switch
Dual WAN with failover (doubt I could saturate the GF connection to the point that pfsense would load balance anyway)As a side note to anyone find this forum posting. I see nothing wrong with pfsense or Google Fiber, its was a strange combination between pfsense + GFiber +WOW that was the issue. Still not sure what fixed it, but it works just fine. Too my knowledge none of the ppl replying to this have GFiber and thus don't have all the information noe the setup to test anything. Cable networking and Fiber networking are different. With cable the modem you use its basically in bridge mode and all you have to do is connect a cheap consumer wireless router and off you go. You can't do that with Fiber you have to use the supplied network box of find a solution to replicate the require WAN protocols. Most of the replies were helpful, and you can see who the moron(s) were.
-
You would probably get more eyes on your problem if you would have posted it in one of the many support forums instead of this General Discussion forum. Just state your problem and people will try to help. If you start off by negging pfSense to try and shame people into helping you in order to defend pfSense's honour, you're going to get some salty replies.