If your main firewall has monitoring, filtering and user authentication features, it should (usually) have multiple interfaces and VPN server functions (possibly SSL VPN too). Any reason not to use the existing hardware to do this work?

The VPN tunnel will need to be attached to an interface so that you can add a gateway.  Assign the gateway to your LAN firewall rules once you've done that. You're going to have issues with both of those being on the same subnet though.

Aaand another update: Looks like increasing Probe Interval to 30 and Down to 300 fixed the problem.

I would check your firewall logs shortly after trying to connect.  Likely the specific ports being used by Lync 2013 are being blocked on the firewall level. http://technet.microsoft.com/en-us/library/gg398798.aspx Looking though that, looks like it would be 43 or 5061, or possibly both.

Nothing wrong with that. You don't need managed switches I just like them because they let you have more control of your network. I would just make sure that you only send untagged traffic to your unmanaged switches. Although there are some unmanaged switches that can deal with tagged traffic. Typically unmanaged switches will not support LAGG and may not have spanning tree too so be careful when running extra links between switches for redundancy.

Just to confirm. The netgear modem was causing issues. Seems it doesnt really go into full bridge mode. Have replaced modem and all is well.

I couldn't try actual physical disconnection because I needed to be there in person to do that! Now I tried it, unplugged the main WAN and waited. The ordinary internet access using a gateway group failed over to WAN2 and the Dynamic DNS names that are tied to a gateway group changed. But none of the OpenVPN servers (site-to-site and 1 road warrior) switched to listen on WAN2 and the 1 OpenVPN site-to-site client going out to another office did not switch to going out WAN2. None /var/etc/openvpn*.conf got rewritten - which they should to in response to gateway group status change. I will have a look at that code, I guess it doesn't implement the same failover processing as when a gateway just stops responding to ping. Added: On a test system, it activates all the processing, but my test hardware only has 1 real WAN, and thus a gateway group with only 1 WAN in it. But it does rewrite the server.conf file. I will have to try a real WAN unplug again and investigate why it didn't seem to work for me early this morning.

I do most of what you're asking for using squid and squidguard. Squid appears under "Proxy server" in the menu system, I forget which top-level menu but about 4th from the left. Squidguard appears under "Proxy filter", just above squid's entry. I use access control lists in squidguard filtered by IPs. I set up static IPs for kids' devices in the DHCP server for the wifi interface. It's a steep learning curve, but powerful once configured.

Firewalls the BANE of users ;) heheeh Glad you got it working - and maybe learned a bit in the process of tracking it down..  I am a big fan of going to the sniff for validation..  If you would of done the sniff you would of validated that pfsense was putting the traffic on the wire, and you just wasn't getting an answer..  This would of forced you to look at the host closer.

Thanks for clarifying how it works today Phil! I also checked out the source code so I understand the principle. The problem is that the table is in reality a DNS resolver cache so it really needs the same functionality. It needs to keep track of TTL values and count them down so the resolved IPs in the table expire when they should. And of course keep the pf table structure updated so it just contains IPs that hasn't expired. That way all IPs would always be current and it would hold onto the IPs as long as it should. I don't know how or if there is an OS level DNS cache in freebsd or if getaddrinfo() could use the DNS forward cache in pfsense. It would be elegant to use resolves IPs that way if it works. Anyway, that for a future release of pfsense I guess :-) Thanks again, Pete

The default rules for lan would be allow any any from lan net..  And pfsense by default would also do NAT from lan to WAN (internet) Did you modify the default rules? Can you post up your lan rules and we can see what might be the problem.

You can reset the IP from the console with menu option 2. So how is your VM host setup? How does the pfSense VM connect to other machines? Where are you trying to connect to the LAN from? You said that it was working until you added the static WAN address. That implies that you have an IP conflict of some sort. However in that case I wouldn't expect you to be able to connect via SSH.  :-\ Steve

check out this cool video which will help you. http://www.youtube.com/watch?v=Usi195rK35I

YOU ARE GREAT  ;D ;D finally it works ! big thanks to you, you made my day !

If you compile a working kernel module against FreeBSD 8.3 then the procedure for adding it would be the same yes. I'm going to suggest it's not an AR813x or AR815x since those should be supported by the alc(4) driver in FreeBSD 8.3. Steve

Would be nice with a feature on the pfSense to bring interface up and down if there is no traffic…  Anyone tried creating a custom script for this ?

If each app is served internally from a different IP address it doesn't matter if they all use port 80. Steve