Folks, problem solved – after update the issue disappeared. Hope this helps you, too. Cheers, Cyberax. :)

Determine if apinger is detecting and marking the interface down. Maybe try increasing the apinger down threshold.  Or disable apinger to see if that helps.

Suggest starting a new thread for this non related topic. Edit / Update: Oh I see you did that already. @shuhdonk: Thanks all for the help and suggestions, I appreciate it.  I have another non related issue. How do I determine why occasionally lose internet connection for just a brief moment a few times a day since putting this pfsense box up, no issues at all with my connection before the pfserver.  What should I look into to see if anythings shows up anywhere?  I assume logs, but which logs, how?  what am I looking for? thanks again!

I'm not sure what you accomplished Heper?  Are you saying pass all https traffic Wan 1 or 2, not balanced? If not, different tier relative to what, the load balance tier 1?  I have the same issue.  I first plopped a Lan pass rule putting all https on Wan2 just above the loadbalance catchall (Wan1+2) at the bottom. Problem is Netflix is on https so the balance becomes very imbalanced. Another issue is dynamic "per ip" rate limiting. I limit, on the loadbalance rule, with values just below the aggregate of Wan1+2 both having an equal provision. However, load balance is never equal and gets more unbalanced when sticky connections are applied so the modem buffer gets hit on occasion increasing latency during high load.  I can't figure out a way to apply separate limiters on each Wan and still load balance both Wan's.

Suggestion: Upgrade your pfSense to a version with uptodate timezone data…

An example of telnetting into a mailserver with different codes that might be shown by some mailservers, could also be tried from a lan side machine https://technet.microsoft.com/en-us/library/aa995718%28v=exchg.65%29.aspx https://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/ As its likely going to be coming from pfsense itself, you might need to create/allow a rule from ThisFirewall to your email server destination on which ever interface your mail server resides on. I only say this because you can see some things like DNS lookups in the fw logs and these are allowed by default, but mail server comms may possibly not be enabled/allowed by default on some/all interfaces from the firewall.

o snap…i forgot i had to port forward 10000-20000 for VOIP lol

@Killertjuh A little tip if you didnt already know which you might find useful for interpreting firewall logs, in Status, System Logs, Settings tab, there is a drop down option called Filter Descriptions. If you change it to Display as Column, you can see which rule blocked the packet which can make things easier to workout what rules might be in the wrong order or not correct in some way. fwiw. Edit. I also increase the GUI Log Entries to Display on the same tab to 2000 which is handy for seeing more info and I see you already have your logs set to display in reverse order. The increase is necessary when you have lots of traffic and/or interfaces and theres nothing stopping you from right mouse clicking on the Firewall, Normal View tab so you get a new browser tab opened up showing the latest firewall log, if you need to see more than say 2000 entries from the gui.

What real life elements are you looking to replicate in your lab experiment? One way you could do this, is load up virtualworks/vmware workstation onto a decent desktop pc, create a couple of virtual guests running pfsense and run the vpn that way, all from one desktop. Add in different virtual guest OS's to add to the realism. VMware Workstation and Virtual Work will let you set up a good number of virtual networks as well, plus you could also plug it into your live network to further add & test the realism in your lab experiment.

The first doesn't seem to be an issue. Just IRC running over a non-standard/ default port. However, the second is related to Dealply, an adware extension/ add-on for browsers. It's normally installed as a bundle with some 'freeware' programs. You can check the computer for this and remove it. See: https://malwaretips.com/blogs/dealply-adware/

It has an: Atom Z3735F @ 1.33GHz - roughly 3-4x as powerful as the atom in those old 2010 netbooks. 2GB DDR3 ram 32GB Nand SSD B/G/N Wfi + 4.0 Bluetooth 100mbit NIC - I assume its a realtek Power usage however I'm not sure, description says 12V 2.4A but the box says 5V on it, but as with most of these mini PCs I'd say the ladder 5V and at most 3A or 15W max as these things don't draw a lot of power which is great. I can't say for sure if it supports vlans, however even the cheapest realtek nics support vlans right? I mean even though I haven't tried it yet but if vlans work on my netbook I don't see any reason why they wouldn't work on a newly made mini PC.

Little bit of an update. If I plug the Apple TV directly into my firewall (ALIX board) - everything works. However, if it's plugged into a switch (tried 3 different brands) or uses Wifi from an AP that's plugged into the firewall, it fails. No errors appear on the interfaces.  I can also confirm the current version of DD-WRT on a linksys router does not produce this issue. Going to compare dumps from both scenarios tonight to see if anything sticks out.

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)