This is just a quick reply to again thank all for replying, and to say I will be spending some time on this at the weekend and hope to have news - Dave_W, I have also joined the Zen IPv6 trial and have seen your notes in a thread on the Zen forums, thank you for this too hopefully I will be able to get pfSense working as you have.

Just remember to generate separate CA's and certs for the different OVPN instances and clients respectively. Depending on the number of clients per instance, it might be quite tedious to do client overrides but you should at least do it for the servers. If you use the internal user manager and generate the certs properly (the CN of the cert should match the username), you should be able to check the logs to determine who has logon to the VPN. While it is possible to setup pfSense without a LAN interface from 2.X onwards, I would recommend still having a LAN interface for management. Otherwise, pfSense would allow management access on WAN - not a good thing to have this exposed to the interwebs. As for the multiple instances, once you have tag each instance with an interface name, you can simply regard them as being additional interfaces on pfSense. That is, they behave just like additional local networks on pfSense except that they don't exist physically. Since these VPN connections are meant strictly for users to connect to your servers, you should make sure not to redirect the gateway (route all traffic through the VPN). In which case, you do not need to worry about NAT rules since all traffic is 'local' to pfSense.

Some more investigation reveals that the admin account that I created is still present in /etc/passwd, but does not show up in or allow login to the WebCfg. Also the packages I had installed were somehow rolled back to previous versions.

Hi John, your approach is correct: the problem must be stopped at the origin, denying the use of Apple products into the company, or controlling packets at AP level, or controlling at switch level with right rules. I think that this storm into medium size networking should be known at Cupertino and the solution should come from their. Obviously this means stopping the resource discovery into the net by Bonjour and the Apple's men never they'll do! I think that many people have this problem worldwide and many strategies have been applied for solving. After many days of research and tests I solved observing the mDNS destinations into the captured packets and then filtering they at level of incoming port. Many thanks for showed me the right way!  :)

So expecting pfSense to handle 500 VLANs should not be something outragious. Yes for sure you are right, but then please also please on adequate sorted or strong enough hardware that is able to drive this VLANs. And in the last time I see here in the forum more and more peoples they let the router do really the switch jobs on top of all other things. If the need is there and for sure also the traffic it must be a stronger router playing together with more powerful switches and often the SMB (KMU) mid-ranged ones will be in the game, but not the really powerful ones for more money, but pfSense should be then even the evil, has failures, produces problems and so on. I like the way @Firewalluser was suggesting as a fast solution to get more headroom, building Interface groups should be a really good point. And perhaps a Chelsio NIC from the pfSense store that is able to full offload the VLAN part would be also a thing that could help a bit out here. But that doesn't help with guest wired ports. Yes for sure this is right. 500 VLANS makes perfect sense for something like a WISP, where they have 500 customers There fore I was thinking perhaps the client isolation would do a good job, to prevent from the many VLANs.

I have abandoned the idea of using the DB9 breakout board like originally planned. I have now taken a new plan on how to connect everything and I hope it all works. I purchased a really small project box and will drill 3 holes in it. I have taken an old PS/2 extension cable and an old RS232 DB9 extension cable and cut off the male ends (no gender jokes intended  ;D ).  I have stripped the shielding on each of the cables. Thankfully, each wire is a different color on both cables. [image: cablecolors2.png] Since I know that for the GPS device ground is on pin 1 and 5VDC is on pin 2, I will put a DC barrel jack in my little project with the orange wire going to ground and red wire going to the center pin. The other applicable wires, I will use small IDC 2-wire button splicers to join wires between the PS/2-type connector to the DB9 wire. For the PPS, the GPS unit will be on pin 3 of the PS/2 and this will go to pin 1 on DB9, so I'll splice PS/2-yellow to DB9-black. For RX, the GPS unit uses pin 4 and this will go to pin 2 on the DB9, so I'll splice PS/2-brown to DB9-brown. For TX, the GPS uses pin 5 which should go to pin 3 on the DB9, so PS/2-green will be spliced with DB9-red.  The cut ends with all the splices will be inside the little project box, so it will have two cables coming out of it and one DC barrel jack in it. I will then plug the GPS unit's male PS/2-type connector into the female PS/2-type connector of the project box. The DB9 female connector will then plug into the serial port on the back of my pfSense device. Finally, I'll plug a 5VDC wall wart into the DC barrel jack. All of this is fairly inexpensive and mostly from parts I already had in my collection from previous projects or devices. I am posting this first to make sure I haven't screwed up with anything and for other's sake if they are trying to do something similar if I'm successful and as a reference to myself if I am trying to remember what I did.

Pass access to the local assets they need if any (DNS, etc) Reject access to the local assets you want to protect (other local networks, this firewall) Pass everything else (the internet)

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 ?