As disabling shortseq hasn't solved the problem, I'd try a lower MRRU (you need to press the 'Advanced Options' button for that setting). The remote end is requesting an MRU of 1460, so I'd start by trying an MRRU of 1454 (which allows for the 6 byte multilink overhead). If that doesn't work, try an even lower MRRU - maybe try 1400. If you find a working MRRU, start increasing MRRU until it fails, then use the highest setting that works. At that point, re-enable shortseq and see if things continue to work. This is likely to involve finding working settings by trial and error unless you can get any hints from the ISP or from the logs of a system that successfully negotiates multilink with your ISP.

https://github.com/pfsense/pfsense/pull/2000 That gets the run-time use of the old "bindlan" out of services.inc It provides some upgrade code, in case there are still configs out there that use the old "bindlan" setting to indicate to bind SNMP to LAN IP. If the config has an old "bindlan" set, but also already has "bindip" specified, then "bindlan" is just unset, so it will forever be gone.

You were asking the same questions back in September. https://forum.pfsense.org/index.php?topic=99277.msg553184#msg553184 The answers are the same as before. And nothing - not even a Mikrotick router - will prevent or mitigate a large DDOS attack. Your best line of defense in that instance is to get your ISP to deal with the problem further up the chain. Both systems do what each of them say on the tin. You just have to decide which one is best for your purposes. And the only authority on that subject is yourself.

Thank you. That I do understand unlike the message that came up on the screen. Hopefully I can take it on from here myself for now at least. Richard.

Got a different message up on the console this morning that doesnt appear in the system logs. Only the TalkTalk tv set top box and a windows 7 pc were plugged in to the switch at the time (both on seperate vlans which cant talk to each other) and the internet connection wasnt plugged into the switch either. The message was: Oct 28 09:35:05 lighttpd[33311]: (connection.c.137) (warning) close: 14 Connection reset by peer.

It'd be better to fix the actual problem rather than trying to band aid it. What Derelict and awebster posted will do what you're looking for, but I'd recommend starting a thread about the routing issue you're having and fixing the actual root cause.

at $499 and respectively $699, I highly doubt so. But with; 1 year of support 3 miniPCIe and a SIM slot Ok if this is not really urgent needed by yours it would be wise to have a look around to get your hands on cheap hardware sorted also with the Intel Atom C2x58 SoC, for sure. It was only a tip of mine because a 60 GB mSATA is often cheaper, a WiFi option is also there and for mobile usage or at a LAN party a solution for LTE is given. Sorry for bugging you!

performance is horrible This is quite right but on top of this (bridging) mostly some other things comes beside likes; packet loss packet drop port flapping There is a golden rules that says Route if oyu can and bridge only if you must.

It just gets better with TalkTalk. Trying to access https://myaccount.talktalk.co.uk/home/dashboard and I get     (92) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)     Handshake with SSL server failed: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure Dig around as I think this is the year old Poodle exploit but cant find the /etc/squid/squid.conf to check if sslv3 is on or not but do find this thread https://forum.pfsense.org/index.php?topic=100167.msg564656#msg564656 Dok sums it up nicely I think and ironically PCI wont find this problem as the link Dok uses doesnt handle sub uri's giving TalkTalk an A pass https://www.ssllabs.com/ssltest/analyze.html?d=myaccount.talktalk.co.uk/home/dashboard So looks like a PCI fail as well. I've attached a screenshot of the youview box attempting to access other vlans when its internet access is killed. Its setup to get its ip setting from the dhcp server, so either pfsense was misconfigured (unlikely considering how hard it is to force a different dns on it) or theres something up with the TalkTalk box. Talk Talk support claim what is seen in the picture is impossible, and I've checked it to make sure there is no left over secondary dns's servers even though its only ever been given one dns in its entire life span of a few years. Is it possible this device has been hacked and being used to explore other devices on the network, yes I'd say it is considering you can watch movies online with it, the tv schedule comes from the internet and other things.  

Okay now I think I get it. The interface that the vlans are assigned to is able to connect to the trunk port on the switch by virtue of having the sames vlan numbers assigned to it as those configured on the switch. Is that what you are saying?

Thanks! Now I need to join github. :)

@AlphaSupreme: Although I limited the log size in the snort package, it had become over 40Gb in size. Deleted all the logs manually, rebooted, restored a config from yesterday, working. :) Going to keep an eye on my disk space from now on. Thnx for the help. could there be some way to keep an eye on such space via snmp ? syslog ?

Possibly havent dont it myself, check out this link as you might need to log into the wifi login page from a computer  behind pfsense before you can get pfsense to connect properly. pfSense would have a wifi dongle/modem on its wan interface. https://doc.pfsense.org/index.php/Accessing_modem_from_inside_firewall pfsense can also do the dhcp if you wanted to go for this type of setup. ISP –- pfSense ---  switch ---- 10 clients

Do the servers respond properly from LAN when accessed via their LAN IP?  Can the servers talk out, such as fetching updates?  Everything in your config looks ok to me.  Perhaps do a capture on LAN just to confirm that the packets are getting out of pfSense or not.  Are you running any extra packages like Squid. Snort, pfBlocker…?  Anything in your firewall log at the time that you tested?  SSH in or login via console and view the pf NAT ruleset: pfctl -sn or the NAT & firewall rules: pfctl -sa Look for weirdness or post it here.

Seems to be working. Thanks!

Excellent, thank you Derelict! That's what I was thinking, just wanted to make sure. Turns out the primary is down due to the two Chelsio cards not being recognized (not populating in dmesg) - I have a separate post in the Hardware section for this. Thanks again!

Your device might not support vlan tagging so can you get your switch to tag the packets/frame as they come in and strip them as they go to the device?

2.2.5 is a maintenance release of 2.2 branch. 2.3 is a new release with a new gui & new freebsd base & new package system. just check out the 2.3 snapshots and you'll see the differences. (don't recommend it on any production systems just yet)

"Wow!! what a mess I had done." Said to say this is like 99.9% of the issues people have.. When in firewall rules are source ports given - almost NEVER!!  Most applications use a random source port, there are only a couple of exceptions - dns with zone transfers can use 53 as source and as dest.  Any is almost allows the source port.. Not paying attention to what port the service is actually listening on.. Glad you got it sorted.. Hope this thread helps the next guy..  Most threads could be like 2 posts.. Post up your rules and what your trying to do and could point out where the mistake was made..  It's almost always a MESS ;)  Not understanding how the rules are evaluated, top down.  Not understanding that you put rules on interface traffic will enter pfsense, etc.. Now what you should be doing is rethinking the whole idea of webgui open to the public net – I had mine open all of 10 seconds to get the screen shot.. And then OFF again to the public.  I admin pfsense and my network remotely via vpn access how any sane person would do it ;)