A problem with the hard drive or possibly the disk controller itself on the motherboard (where the drive is plugged in) I'm not sure if proxmox is smart enough to generate an NMI on its own for things like that, so it may be passed through from the actual hardware. There is a chance it's something in proxmox or the host itself, but someone more familiar with proxmox would have to chime in and answer that part.

It depends on what is causing the outage. It's definitely not normal to see that, but a couple different things could be to blame. For example, if one of your gateways is marked down and you have the option to kill states on gateway failure active, then each filter reload will kill all states, resulting in an interruption.

"Jumbo Frames configured on all switches, and devices." So your phones (wired and or wifi) and other wifi devices are doing jumbo frames?  What about your TV or your DVR?  What about your thermostat or your toaster? While jumbo frames might be of some use on a SAN, or other layer 2 where traffic is not routed and takes advantage of the large MTU say vmotion or FCoE and the already mentioned iSCSI.  Other than that I am with SoulChild on it being pretty pointless on the rest of your network. Your printers support jumbo do they? Have you actually benchmarked your applications using a standard mtu of 1500 and with jumbo.  Many applications are never sending full data packets anyway.  Lots of little packets on the wire, where jumbo doesn't do anything. To your trunking traffic to a lagg.  So hairpin, and you do understand that when 2 devices talk they are going to use only 1 connection in the lag.  So a hairpin that /2 the bandwidth the available bandwidth on the physical interface for that conversation.  So you think your jumbo is any real value here for moving large amounts of data? Lagg, Port channel, etherchannel, etc. what ever you want to call it 1gig + 1gig does not = 2gig.  It equals 2 1gig connections. If you your looking for performance for intervlan traffic I sure wouldn't trunk the connection. You should put each vlan on its own uplink so that you don't hairpin.  This prob going to give you way more bang for the buck then any jumbo frames. If you need more than 1 gig, then have a bigger uplink.  10gig for example.  Lagg to be honest is nice for mitigation of failed port or switch you set it up correctly.  But as to giving you a fatter pipe not so much.  And then you just hairpin anyway?  Trunking and putting more than 1 vlan on the same connection is ok when the vlans on that connection don't want to talk to each other and only talk to other vlans on other uplinks, etc.  But when devices going through the same uplink to where they can be routed to the other vlan on the same uplink you just /2 your possible bandwidth because of the hairpin.

If the traffic lends itself to it it can be done.

@rolandk, The symptoms you are describing is exactly what occurred at one of our customers. What version PFSense were you running? Our customer site was running 2.2.6

Here are some more characteristics rrom this problem. The WAN connectivity doesn't actually stop. What is actually stopping is the e-mail manager program, such as Thunderbird and Outlook, and only for certain machines. Thunderbird, for example, stops at the SMTP connectivity process. Whenever the e-mail managers aren't working, the firewall machine won't answer to ping requests. The Internet  is always fine though. Reconnecting the network cable fixes the problem (ping and e-mail managers) for some time, but then it comes back. Changing the IP does the same thing. Any clues?

@ha11oga11o: @JeGr: But mine PfSense goes into 1Gbit switch, so no lan traffic actually goes via LAN interface…. or yes? Its PC with two nic, one is wan other is lan, and then 24 port switch. What do you mean by "no LAN traffic goes via LAN interface"!? That make no sense at all. You have built a router with two NICs and put the faster one on the WAN side on a modem link, that is no faster than 40MBit/s as you write and put the slow 100MBit/s link to a GIGABIT Switch!? That's nonsense in my opinion. Why would you do that? Put the slow 100Mbps NIC on your WAN and modem side as your modem link won't be faster that 40 anyway and put the Gigabit Interface onto your Gbps Switch where it belongs! Why artificially limit your LAN connection if you don't have to? Also one NIC or the other may connect worse with auto sensing. Perhaps your Gigabit Switch doesn't like your slow interface that much? I'd sort that out first and double check all connections if the auto negotiation is going bonkers somewhere. Also what dotdash said, the NICs aren't known for stellar performance. What you said about chane sides of NIC it make sense. But i have gigabit speen in my LAN environment, so i thought it does not matter. I will change that and revert with results. Also, ill try to find intel based nics, that would be much better. Thanks. I reverted sides with NICs… had same issue. I simply reinstalled fresh and seems it works for now. Something somewhere it was wrong, thats for sure. But seems its easier to reinstall it and do settings from zero. Thanks for guidance.

It's been pretty stable for me running a PC Engines APU2.

I did some experimenting and tried different combinations of using the onboard Realtek network ports and the addon Intel PCI Network card.  The best speed results came from having my WAN attached to one of the Realtek ports and my LAN attached to one of the Intel ports.  I got speeds over 500Mbps down and over 700Mbps up.  I think the primary limitation is the bus on the motherboard.  PCI is just not enough for gigabit Internet.  Unfortunately, I have turned off the pfSense router and am using the Netgear R6300v2 that Cox provided which gets speeds over 900Mbps down and up.  Until I can build a beefier pfSense system, this will have to do.  :(

@ishtiaqaj: thats y i am probabing may b sonething in configuration i can do some setting to avoid bootloop.. Yeah there is, it's called a UPS. No computer responds well to a sudden power loss regardless of "settings". If it's that important to you protect it with a UPS.

That sort of issue would be better fixed with a local host override or just turning off rebind protection for the plex.direct domain.  If your having issues you prob have issue with rebind protection.  Because the url you could use to access would be something like https://192-168-9-8.11b1ea3fe<snipped>92c7b8.plex.direct:32400 Where that would be some random token.  You can find that in your xml.. go to https://plex.tv/pms/resources.xml?includeHttps=1 You can set plex.direct to not use rebind protection so when you query for that name you get back your private IP.  Out of the box pfsense would block getting back rfc1918 for a query and you get back nothing.  So you see when I do a query for that fqdn get back no answers. I then add in the unbound advanced custom box to turn off rebind protection for plex.direct and then I get an answer back of my local IP. https://doc.pfsense.org/index.php/DNS_Rebinding_Protections private-domain: "plex.direct" See the rebinding section on the plex support site for https as well https://support.plex.tv/hc/en-us/articles/206225077-How-to-Use-Secure-Server-Connections [image: rebind.jpg] [image: rebind.jpg_thumb]</snipped>

@SoulChild: Sure, it's possible You indeed need a vlan-capable switch. Prices of this range from several thousand bucks to 20 something. I have personal experience at home with these: http://www.ebuyer.com/641041-tp-link-tl-sg108e-8-port-gigabit-easy-smart-network-switch-tl-sg108e?mkwid=s1HfC5rWZ_dc&pcrid=51482425979&pkw=&pmt=&gclid=Cj0KEQjwmri_BRCZpaHkuIH75_IBEiQAIG0rIT5tBk3xx6BSTrX8HzKbXoMKydTRzeB4DU1q0HfRVBcaAmla8P8HAQ Sure, the gui is confusing and pedantic, but once you got it working, it works fine. You can't expect everything for 20 bucks :) For a bit more, you can have 24 ports, even. For simple(!) vlan setups like yours, this will work fine. But be aware that setting this up can be painfull unless you're really sure what you're doing. But then again: you only learn by trying :) Thanks! im going to do a little research on those switches, i was thinking on the "Tl-sg2008" its a little better i think and i found it at good price.

fredie380 may be lacking actual content, but I'm also trying to track down a problem with my machine needed reboots at least once a week, sometimes hanging. Symptom 1: I lose the lan connections randomly.  It seemed to be every 7 days.  We tracked this down to a network surveying software that was scheduled to run every 7 days.  This is a symptom though, not a cure. Symptom 2: Firewall would spike to 100% and require hard reboot.  All interfaces were offline at this time.  Reading an forum post on 2.3.x and a bug track on SMT, IPSEC, and UDP, I disabled SMP on the firewall, running it down to single thread to see if it would resolve. So far firewall is stable, but this isn't a cure it's a band aid. So fredie380, if you're seeing similar symptoms you may want to try the above and report back. If it's not the same, please give more information.

Well, interface might be misleading of even wrong. Difference between RFC 2307 and 2307bis is mainly how members are described within group. Basically RFC 2307 bis will store members as "uniquemember" (containing member's DN) while RFC 2307 will look at memberuid storing… uid This is quite different and has real impact on the way one look at group memebership. This said, I don't understand your ldap filter as you search, within same filter, for "uid=something" (this searches for user's LDAP entry, if I'm not wrong) and cn=somethingelse + objectclass = posixgroup, which targets group. This works only with your groups contain uid attribute describing members, which would be odd. I'm not discussing here other differences between 2307 and 2307bis about structural vs. auxiliary  ;)

Yep, something stupid. A reboot of the machine fixed it.

@johnpoz: " I am coming from another subnet further down the 192.168.0.0/24, the pfsense would need a gateway on the LAN interface and I am not very clear on pfSense different gateways especially when one is pointing at the upstream through the WAN and the other one is pointing as the downstream infra through the LAN interface." You would not connect a downstream router via the "lan" you run into asymmetrical routing that way.  If you need to connect downstream router to pfsense then that would be via a transit network.  You don't put hosts on a transit.  If you do everyone of those hosts would need to have host routing to tell them which gateway to use to get to which network, etc.  Its a logistic nightmare which is why you use transit networks to connect routers. Isolation of what interface you use to management pfsense very simple.  Create a new network and use that network as your management be it you use a whole physical interface for this or a vlan is up to you.  Generally speaking if you want an isolated managment network use of the "lan" would be good since it has the antilock rules on it.  Then all your other networks connected to pfsense would be on opt interfaces or vlans running on lan or opt interfaces.  But again when connecting another router be it downstream or even stream of pfsense it would and should be via a transit network. Thanks ! I am not entirely sure I got your point except that it's likely to be messy which I know well ;-) I will keep it simple for now and just add a route to my few networks in my out-of-band management network.

You're right, but it just feels a bit weird implementing a virtual firewall on your openstack to access your virtual IP's But god knows, openstack is the wild west so far as best practices are concerned, so don't let me tell you otherwise :D