I just ran vmstat -i while I was running iperf against PFSense, and the interrupt rate was unflinching. A flat 40/core, for a total of 120/sec.

Then you could have an offline copy of pfsense and even the forum using httrack ?

@riahc3: There are graphs in pfSense for quality? Intresting. That's what I wanted to look at in the first place :) Where can I view that? Status->RRD Graphs->Quality Status->System Logs->Gateways

Thank you for the clarification. I think I have mine correct then. There's no need to change the LAN computer's listening port of 80, which I was confused with. However, having my LAN computer's setup like that, I still receive the errors: Browser: No remote browser access to security server on publicWANIP:8061. Remote browser access to security server on publicWANIP:8063. SSH: $ ssh ubuntu@publicWANIP -p 8061 ssh: connect to host publicWANIP port 8061: Connection refused $ ssh ubuntu@publicWANIP -p 8063 ssh_exchange_identification: Connection closed by remote host TeamViewer: TeamViewer to 192.168.1.40 blue, but won’t connect. Now TeamViewer to 192.168.1.40 connects, but 192.168.1.120 turned off? TeamViewered into 192.168.1.120, the remote connection turned off. Traffic analyser: Tested packet capture: LAN computer > pfSense > Diagnostics > Packet Capture > Start > remote computer (I'm on this) > Terminal  > $ssh ubuntu@publicWANIP -p portNumber > Enter > LAN computer > pfSense > Stop. No packets reaching the pfSense WAN. I'm now stuck remotely and will need to physically go to the local computers for access, to try again tomorrow.

@mulder00: Just tried it but unfortunately it didn't work. Didn't have any connection at all with it disabled. If this indicates you tried disabling gateway monitoring already the result doesn't look right. You should have at least the same connectivity as before. Steve

Try the bandwidthd package first: it will give you traffic graphs by client and classify the traffic. Web site tracking is more complicated, I haven't done much of that.  Suricata can do some I believe, but there may be a better package for tracking site usage by client.

@ehuk: Quick question, if we select an Active Directory server as the main authentication server for a pfsense box, what happens if the AD servers is unavailable for whatever reason? Would we be locked out, or would it try and authenticate with the Local Database? It falls back to the Local Database. In fact, the Local Database is always active. If you log in with credentials not valid for the AD, pfSense will retry the same login with a local account instead. Keep the local admin account and give it a strong password. Then you can always log in regardless of AD connectivity. Also, you need a local account to do syncing between firewalls and ssh logins to the firewalls. Lars

No one?

How can I now test the bash script? I have cron installed (using the GUI) with */1 * * * * root /home/wolserver And the code is in wolserver. nothing is happening and I see no logs (do not even know if cron is running the script), am i missing something?

See this thread https://forum.pfsense.org/index.php?topic=71198.msg403630#msg403630. I've made a few changes since… take a look and let me know if you're interested and I can post updates on the old thread...

What version of pfSense are you using?

On the top bar, Status–--->DHCP Leases, this will tell you any device that has a DHCP assigned address OR Again from the top bar, Diagnostics------->Arp Table, this will tell you anything that has had it's address resolved, including interfaces I believe. ARP = Address Resolution Protocol. I'm sure I'm forgetting other nifty things as well

If you have assigned the Fonera device a static IP in it's configuration then it won't be asking for another one from pfSense via DHCP. However you need to make sure that IP is outside the DHCP range pfSense is using on that interface otherwise you may end up with duplicate IPs and the inherent errors that causes. There is usually something in the logs to indicate that though. If it's just one machine at the end of the wireless bridge you could assign that a static IP also. Then it will just not work for the time it takes to establish the bridge but will function fine after that without any intervention. Steve

Hm…sounds like our issues are slightly different...Im definitely getting a connection; For example I'll get a sustained 60Mb/s and then all of a sudden (after 850MB) the connection peeters out and then will restart...peg my throughput, then stop...then start again. Isn't there some setting to allow URL's in URL's? I wish I could track down what log to look at; I've checked Dansguardian logs, squid logs, squidGuard logs...nothing that I can see. I need to figure out a way to insert a tap between my cable modem and pfsense so I can run Wireshark... thx PP

Just saving using real ports on your pfSense. From a performance point of view, pfSense processes all the traffic between sub-networks anyway, whether they are together on a VLAN trunk port, or on real ports. In fact, traffic between 2 sub-networks should be quicker if they have a real port each - if they are both on the same VLAN trunk port then traffic going both ways ends up doubly competing for the real capacity of the VLAN trunk. If you already have 4 physcal ports on pfSense, then you can use them wired-LAN, WiFi-AP(s) network, ISP1, ISP2 and you are done. Of course if you want another separate LAN then you would have to implement VLAN(s).

There was another thread with almost identical symptoms. If I recall it was an IPv6 issue, Android was attempting to use it for some sites. Could have been this: https://forum.pfsense.org/index.php?topic=68764.0 Nope this: https://forum.pfsense.org/index.php?topic=76664.msg453241#msg453241 Steve

It's almost certainly not the fact it's dual WAN, that site isn't replying to/is blocking the source IP you're sending it out from, or maybe a general connectivity issue for that network. A traceroute might be telling. The states you showed prove it's getting sent out no problem, getting NATed as it appears it should be, but gets no reply back at all.