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.

I wanted to say thanks for taking the time in this detailed write-up. I am facing similar issues with a customer's VOIP provider. We replaced an existing SonicWall solution with a pfSense-based appliance (the SonicWall was having horrible problems with the VOIP). The pfSense appliance installed like a dream. Since then, the VOIP issues had been slightly better, but still existed. Your post was detailed enough so I could apply your findings to our setup. We'll see how things improve over time. I'll post back here if I develop useful follow-up.

Thanks charliem! I'm starting to think that USB is the root of the issue. I fired up the apcupsd status panel and got the "could not connect to service" error; according to the system logs apcupsd was not started as the UPS could not be found. I unplugged the UPS, plugged it in again, checked dmesg and got the following: ugen0.2: <unknown>at usbus0 (disconnected) uhub_reattach_port: could not allocate new device ugen0.2: <american power="" conversion="">at usbus0</american></unknown> I went into the apcupsd panel and hit "Save" on the configuration page then clicked over to the "Status" tab and lo and behold, the UPS service had been started and the status was printed out. This was a couple of hours ago; I've just checked the RRD graphs / vmstat and the wired memory has stopped increasing and leveled off, and no funny USB related stuff in dmesg either. I've checked the UPS' USB port on my linux dev machine and all seems just fine, my guess is that there is an issue with the USB driver and the way it is initialising the USB hub which is hung off the controller on the motherboard. I've detached the UPS' USB for the time being, will restart it and see what happens. Incidentally I plan to upgrade the hardware to a more modern Haswell CPU / board in order to save some power so I'll do the same set of experiments once that's up and running in a couple of weeks. Many thanks for your help! If things start to get wierd again I'll append this thread with an update as it does seem there may be an underlying issue with the kernel and this USB configuration.

You can also use "tip" or "cu" which are already included.

Did you ever found out how to do this? I have the same problem.

Your post is useful and knowledge so true.

Where are you testing from? You can't test from the pfSense LAN because of: https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks Steve

Anytime.

don;t know if this can be a bug or it's the way it should work. maybe some of you can reply on this thx

Assuming you've probably tried another network cable, if not, do that. If your ISP is being less than helpful, you could try plugging some other device into your cable modem. See what it ends up with. If it also ends up at 100 half, then there's a good chance the duplex is forced on the modem, or the modem is bad.

Have just taken out the pfSense box and opened up the Wifi for now. I will work on the box tomorrow evening and see what gives. I will report back here to let you all know. Thank you all very much for your help so far. Colm