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!

It happens to me too on Linux when using netdiscover: sometimes some device is not seen. But I think it is normal: this list is not exhaustive, because it depends on the method(s) used to detect devices. Even nMap sometimes does not detect an open port that is really open, i.e: 22TCP is shown as filtered, but if I try to log via SSH, I success. When I reviewed about the matter sometime ago, I found a brief explanation about the several methods that detect nearly 100% each device in the LAN at the websites of dSploit and zANTI2 for Android: ARP scan, ICMP ping… etc. Anyway, NetDiscover/ARP-Scan partial search is enough for me on most cases. Thanks you, JohnPoz.

I run RASPBX behind NAT (pfsense) and am able to connect both laptops and mobile phones remotely. If you are able to connect to other applications over the IPSEC tunnel then you be good to go. Here is what I did. 1. Port forwarded 5060 to RASPBX IP for SIP messaging. 2. Port forwarded a RTP port range for the audio traffic. The size of the  port range is  dependent on the number of users you have. In my case I forward a range of ports starting at 10000. 3. pfsense auto created the firewall rules for the above. 4. Ensured that the remote clients were programmed to use the ports in #1&2. Don't assume that they are. my BRIA mobile sip app was using some other ports and had to be reconfigured. 5. Set up an IPSEC VPN same as the OP. 6. Confirmed that I can connect with  Android and IPAD versions of Bria and a Mac application called Telephone. 7. Just for kicks I also tested allowing SIP requests from my cellphone IP address directly through the firewall to the RASPBX. (No VPN). Also work fine, with caveat that my cell data plan provider always assigns the same IP address no matter where I am. I suggest that you get access to the SIP logs on the server to see if there are any transcoding errors or mismatched RTP port ranges.

Where are these logs? I'm very new to PF Sense. I've watched a couple tutorials and read some of the documentation  :-\

Someone already asked for a Smokeping package for pfSense but it didn't go anywhere.  You could run your own instance of *nix in a VM and then install Smokeping and use that.  Not as good as running it on the one appliance but better than nothing.

Hi! You can use OpenVPN in bridge mode for that. Add network adapter and bridge it with OpenVPN tap device.