They apparently changed their update URL semi-recently, and no longer support HTTPS. I updated the client for 2.3 (and 2.2.7 if there is one, but probably won't be) to use the new dyns URL. Thanks to GP^ on IRC for noting the change and this thread.

Use netflow and prtg. It can give you a real insight into what's going on in the network. For torrent you can use snort at least to identify users doing so.

Softflowd does not send netflow v5 or v9 that NTA will understand. This is because in all netflow packages, both Interface Indexes = 0 in exported flows: https://thwack.solarwinds.com/thread/31006 By forcing the traffic to be shown as you probably have done in NTA, you are only seeing what the NTA can decipher from SNMP data. Unfortunately, doing so excludes all traffic not originating from the router and multicast, as you have seen. NTA is extremely picky about netflow. The only netflow that I have been able to get working reliably with NTA on pfsense is Pfflowd. Unfortunately, on recent PfSense versions, this no longer works: https://forum.pfsense.org/index.php?topic=88441.0

@jimp: A general FreeBSD forum would be better for that but it's not a really complicated issue. It depends on how you login and/or how the shell starts. Try making .bash_profile instead, or linking the two. Indeed, this worked: $ mv .bashrc .bash_profile I will anyway ask on a FreeBSD forum and post the link here, for those interested. Thanks you.

If you want multiple, discrete, SSIDs then your AP needs to be on a tagged port and be able to tag each SSID with a separate VLAN. If you only want one SSID just put it on an untagged port on the VLAN you want.

Agreed running a downstream router can be a huge learning experience. Not sure what harmful traffic you would want/need to isolate from your firewall?  If you mean blocking clients from access to gui, ssh or even services your running on pfsense sure..  But its meant to be your firewall, so I would think you would want to filter all your traffic through it all it to filter/isolate clients and services from each other. The filtering capabilities are going to be much better using pfsense than any l3 switch I can think of ;) Isolation of traffic like voip and data sure can be done with vlans or even physical segments routing the traffic through pfsense. To be honest the only reason I can think of a downstream router in a home setup would be learning experience or if you need to move traffic between segments that require none or very min filtering, And the interfaces of pfsense are not just up to it.  I would look to updating the pfsense box and or its interfaces if this is the case as better option other than just the pure learning aspect of the downstream router. I have toyed with turning on my sg300 l3 mode, since my pfsense runs in vm and can not really push full gig that I have seen in testing.  I could for sure update my vm host to accomplish this.  But the simpler solution (KISS) was to just put those devices that move lots of data on the same segment so they don't go through pfsense at all.  Since these devices don't really need filtering.. Where I need/want filtering is between my wifi and my lan - no real need for 100% util of gig there - wifi just can not do it anyway, and my internet connection is no where close to gig..  Come on google fiber in Chicagoland ;)  Chicago is on the list… And I isolate my wired stuff like TVs, and console devices on their own segments..  They again don't really need full gig speeds..  I want full gig between my workstation and my vm host/nas/etc  So I just put them on the same segment keep pfsense out of the mix for traffic between these devices. I took the OP to being on a home/lab sort of setup and not production, maybe I was mistaken in this?

No sorry. :-\ I had other evidence, for example by removing the first VLAN. In doing so the vlan_50 had appeared as output of "netstat -g4" (not seen before). From there I had found on freebsd forum a post that talked about a known issue related to a maximum limit of virtual interfaces …. but then I gave up: I was losing too much time. In the end I think it's the igmp proxy module to be quite buggy, maybe the developer should think of alternatives .....

@awebster: Check that your interfaces are properly negotiating link speed/duplex; on both ends of each link. A 100mbps Half-duplex link would produce what you're experiencing. pfsense reports: BRIDGEIN interface (wan, em0) Media: 1000baseT <full-duplex>BRIDGEOUT interface (opt1, em1) Media: 1000baseT <full-duplex>LAN interface (lan, nfe0) Media: 1000baseT <full-duplex,flowcontrol,master,rxpause,txpause></full-duplex,flowcontrol,master,rxpause,txpause></full-duplex></full-duplex> this matches the uplink and local switch port configurations.

Is the Netgear/DD-WRT router running as a router or as a WLAN AP? If there, at the Netgear, NAT will be done on the WAN Port it could be based on this issue that there will be no traffic running over this ports then. I would let the Netgear running in WLAN AP mode and let do the pfSense the entire DHCP part if needed.

Thanks for the explanation cmb. FWIW, I am using Google Public DNS: 8.8.8.8 8.8.4.4 Is there a retry interval option for failed updates other than the cron entry? Perhaps a flag that gets raised when the update fails and a process that checks for a failed update at a greater frequency than the default cron?

Appreciate the feedback. Usually strongswan picks the strongest option where multiple are chosen, like AES auto defaults to 256 bit. racoon did the opposite there at times, with AES auto choosing 128, then it switched to preferring 256 post-upgrade to 2.2.x. Which is most always fine, but some people using glxsb crypto accelerators which don't work with 256 bit had issues. I'll check into that. @bradenmcg: cmb, I appreciate the reply.  I'd rather wait for 2.3 to be closer to release before jumping in there - I need the connection for work, plus my wife would grumble if she doesn't have her Netflix.  ;) I hear that. Though outside of packages that haven't been Bootstrap-converted yet, 2.3 is solid. That's all we use internally at home, including those who work from home.

Hi, $ top -o res -SH last pid: 93452;  load averages:  2.46,  2.03,  1.05  up 0+01:33:06    05:41:19 181 processes: 13 running, 111 sleeping, 57 waiting Mem: 30M Active, 54M Inact, 30G Wired, 152M Buf, 696M Free Swap: 64G Total, 64G Free PID USERNAME PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND 27968 root      23    0  238M 39592K uwrlck  8  0:00  0.00% php-fpm{php-fpm} 27968 root      20    0  238M 39592K kqread 10  0:00  0.00% php-fpm{php-fpm} 71376 root      21    0  233M 37552K piperd  5  0:01  0.49% php-fpm   240 root      20    0  229M 21884K kqread  0  0:00  0.00% php-fpm 8996 root      20    0 28344K 18120K select  5  0:41  3.56% ntpd{ntpd} 8996 root      20    0 28344K 18120K kqread  8  0:00  0.00% ntpd{ntpd} 28501 root      20    0 62848K 17036K select  6  0:39  2.39% bsnmpd 18813 root      20    0 85556K  5708K kqread  3  0:00  0.00% lighttpd 6052 root      52    0 32424K  5196K select  9  0:00  0.00% sshd   273 root      20    0 13160K  4448K select  4  0:00  0.00% devd 28825 root      20    0 17476K  3368K ttyin  5  0:00  0.00% tcsh 93452 root      21    0 21988K  2948K CPU10  10  0:00  0.00% top 11467 root      20    0 16804K  2788K bpf    6  1:01  2.59% filterlog 26420 root      21    0 43568K  2660K wait    8  0:00  0.00% login 26522 root      21    0 17136K  2628K wait    8  0:00  0.00% sh 26830 root      52    0 17136K  2516K wait    4  0:00  0.00% sh   256 root      41  20 19024K  2492K kqread  4  0:00  0.00% check_reload_status 30428 root      52  20 17136K  2408K wait    2  0:00  0.00% sh

sw (vlan 100)  –---> lan [pfsense ]  wan –------> sw (vlan 100 ) In that case you must bridge the ports together, but I really want prevent to do this really. Often this is causing then more problems then it solved problems. flapping ports packet drops packet loss Or you disable NAT at the WAN port and enables only plain routing this could be also a workaround to drive VLANs at the WAN port.

@hda: Did you see these ? netwerkje.com/eigen-router haroldschoemaker.nl/2015/07/eigen-router-achter-een-xs4all-vdsl-aansluiting-3/ https://forum.pfsense.org/index.php?topic=104809.msg584237#msg584237 @David_W: A switch will do what it is configured to do - tagged operation on a VLAN, untagged operation on a VLAN or no access to the VLAN. In this case, the VDSL bridge's Ethernet port needs to have access to VLAN 4 and 6, both tagged. pfSense needs interfaces on both those VLANs - the most efficient way is to use a single switch port (or lagg group, if you have such a thing) with access to VLAN 4 and 6, both tagged. The switch must be configured to match what is plugged in to the ports. For access to the VDSL bridge's management interface, you will probably need access to a third VLAN unless the bridge has a second Ethernet port for management purposes. If the management VLAN must be untagged, you must set the PVID of the switch port to the ID of the VLAN you intend to use for this management interface on your switch as well as configuring the port to have untagged access to the relevant VLAN. Though I'd get one thing working at once, if you have sufficiently recent firmware on your Vigor 130 and the network interface in your pfSense box supports jumbo frames, I believe you should be able to use RFC 4638 to operate with MTU 1500 over PPPoE on XS4ALL. As of today, this support is built in to pfSense 2.3 builds (which reach beta status today) - all you have to do on 2.3 is set the MTU of your PPPoE interface (likely WAN) to 1500. I've made an unofficial patch for 2.2.4, 2.2.5 and 2.2.6 - amd64 full installs only. I'd upgrade to 2.2.6 before trying this. Thank you both for the comments on this. The solution was indeed to tag the vlans on the switches. It all works now. Thanks again!