Inline responses… 

On Mar 20, 2014, at 3:02 PM, Ryan Dunlop <ryan.c.dunlop at gmail.com> wrote:

> In the Alix documentation for that device it mentions that EHCI driver
> could cause issues and panic conditions in FreeBSD.  Maybe you want to
> randomly toggle that off?  Doesn't seem like anything to do with
> anything, but neither does the rest of this situation…
Not sure how to (easily) do that with the board without going via RS232. I’ll look into it.

> No outbound rules defined besides allow all?
There were but I eliminated them.

> LAN address for pfSense static?
Dynamic. Easier that way - assigned  by the CenturyLink DSL modem

> Gateway defined for WAN?
DHCP.
> Is the gateway (modem/switch in between) experiencing even short
> glitches of being down?
Not that I’ve seen. I can talk to the firewall constantly remotely (DMZ’d).

> There are a couple of settings in Advanced,
> Miscellaneous for schedule states and gateway monitoring if your
> connection is at all glitchy it may be killing all states for good
> with these options and not coming back until a full reboot.  Mine are
> both unchecked.
> Under Interfaces, LAN are you blocking private networks?
No, because of the double-NAT.

> All cables in the bar good, no kinks, proper terminations, not mixed wiring?
Yes, new cables, pre-fab, all tested.

> I know these are all very basic setup options, but being that neither
> this list, nor the pfSense list can figure anything out, I want to
> rule out a simple check box situation before the hardware is suspect.
> 
> Where does your RAM usage sit?  I don't use much more (512MB) but 
> between 256MB and a 500Mhz proc, I am wondering if you are simply
> pushing that hardware?
I thought that, too. It’s working now after swapping the hardware out (again - third time). 54% utilization, 2% on states (459/23000), 22% of the disk in use.

> It should be fine for your bandwidth in a
> simple setup but the 3 VLANS may be the issue when their bandwidth is
> combined on the hardware.  Mine is virtualized so although my RAM is
> at that level it is also able to use a Xeon E5 2440.  States aren't
> being eaten up?
My E5 VM at home is plugging away without issues…  but it was built from the 2.0 image and upgraded to 2.1-RELEASE.
> 
> This is crazy...wish I could be more help!

Heh, me too. I cannot possibly think of a reason. I was using a different power supply than was provided but I just put it to the right one today (12V 1A instead of 15V 1.5A I think it was shipped with).
> 
> 
> 
> 
> On Thu, Mar 20, 2014 at 2:09 PM, Ryan Coleman <ryanjcole at me.com> wrote:
>> They load the first few lines but once it needs another site (say yahoo's CDN on their homepage) it stalls. Google loads but it's all inclusive - no CSS or JS files.
>> 
>> Email is blocked 90% of the time.
>> 
>> --
>> Ryan Coleman
>> ryanjcole at me.com
>> m. 651.373.5015
>> o. 612.568.2749
>> 
>>> On Mar 20, 2014, at 14:06, Ryan Dunlop <ryan.c.dunlop at gmail.com> wrote:
>>> 
>>> So are you actually not getting to these pages at all, or are these
>>> just showing in the log?  I ask because pfSense does this a lot.  Here
>>> is a look at my situation:
>>> 
>>> Mar 20 13:53:32 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:53:32 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:53:13 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:53:13 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:53:02 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:53:02 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:56 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:56 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:54 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:54 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:53 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:53 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:53 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:53 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FPA
>>> Mar 20 13:52:53 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:FA
>>> Mar 20 13:52:53 LAN 10.0.0.84:38737 74.125.225.6:80 TCP:PA
>>> Mar 20 13:52:53 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:FA
>>> Mar 20 13:52:53 LAN 10.0.0.84:44553 74.125.225.6:80 TCP:PA
>>> 
>>> These are all "blocked".  Yet in reality we got to these pages, it's
>>> simply this: https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
>>> 
>>> Although the article talks about it being late arriving FIN packets,
>>> it does happen to ACK too...  Just need to clarify if you are actually
>>> getting fully rejected from getting anywhere, or if it's a log thing
>>> you are seeing.  I'll look back through your pfsense mailing list
>>> postings too.
>>> 
>>> Ryan
>>> 
>>>> On Thu, Mar 20, 2014 at 11:46 AM, Ryan Coleman <ryanjcole at me.com> wrote:
>>>> I have an open issue that after about 20-24 hours the firewall stops routing internal data out (I can remote in, I can ping from internal networks, but many simple requests are getting blocked by the default rules).
>>>> 
>>>> I think I might be pushing my luck with the 3 routed VLANs (4, if you count VLAN1) on the hardware (ALIX 2D13) but I am otherwise completely at a loss for ideas.
>>>> 
>>>> 
>>>> --
>>>> Ryan
>>>> 
>>>> 
>>>> _______________________________________________
>>>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
>>>> tclug-list at mn-linux.org
>>>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>>> _______________________________________________
>>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
>>> tclug-list at mn-linux.org
>>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>> _______________________________________________
>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
>> tclug-list at mn-linux.org
>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140320/82bed895/attachment.html>