the first is normal in all circumstances, the second is normal at this point in Hyper-V but seems to only be cosmetic for most people (it's one that Microsoft's looking into).

hold off on the bug report, let's troubleshoot further here, as I don't think there is an actual bug there. The description isn't clear to me though. What type of VIPs? What traffic did you see on the affected IPs in a packet capture before fixing it? It sounds a lot like what'd happen when you have a stale upstream ARP cache after swapping hardware and it sorted itself out by chance while you were going around pushing buttons in the config.

IKEv2 docs are coming, two are up now: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2 https://doc.pfsense.org/index.php/IKEv2_with_EAP-TLS More scenarios are likely to work, but they need testing. A Mutual RSA doc would be good to have, portions of it could be copied from the existing docs as well (the two above have good docs for generating certs and such)

@jimp: PBIs were a good move at the time, but not so much anymore. It's not that PBIs have become a bad move, it's just that nobody else is using them now (including PC-BSD and FreeNAS, which is where they started.)

OK, my apologies … :(. It thought I had this working, but not quite. I was fooled by being on my local LAN (for debugging, it's easier), and some traffic "bypassed" the VPN connection. Not working as well once remote. Trying to debug it, but having a heck of a time with the Firewall Rules. I have added a floating rule (which should be applied first), passing and logging all DHCP traffic between / on LAN and OpenVPN (TAP) ... but it's not catching anything - even though I see the traffic in the DHCP log, and also using tcpdump on the server (LAN interface). Very frustrating ... :(. Any suggestions on the firewall would be greatly appreciated, as it's hard to debug this blind. Thanks!!!

The & was in my config.. not sure if I did while back or was part of a update that I got.  Either way that worked.  But yes you have point since the package points to amd 64 locations that would cause issue with i386 and older versions as I think they have different file structure My skills are limited.. Hope someone will help with this. And my time is limited also.. Found Jim-p did that & stuff to the file little while ago https://github.com/topper727/pfsense-packages/commit/a890380266da7f589b809701bd3d0e8ac715e82f

I've decided to give up on IPSec IKEv1 with just the settings on my phone, and instead focus on L2TP/IPSec instead, which is also done from just the phone. At least there's an option there to send all traffic over the connection. There's already a separate thread about that.

@Topper727: service squid_clamav squidclamav.so squid_clamav does not exist in /etc/rc.d or the local startup squid_clamav is an c-icap service, not a rc.d file.

IPv4 will trigger an IPv6 reconfiguration.

I'll pm you on this, ok ?

We need logs. Not useless screenshots, totally censored in addition.

Since SSH goes down after reboot from first upgrade when it works.. I can not get in ssh just use the local monitor and keyboard to the machine.  Also noted that system failed to give me IP.  I tried using the upgrade from console hoping this would fix it but didn't work.  Did upgrade or reinstall install same version I think but still didn't fix it. 2.1 was so much more stable than this version

The states are also still present. Does anyone know what the timescales are for killing off states for the System: Advanced: Firewall and NAT, Firewall Optimization Options? Normal Conservative High Latency Aggressive TIA. lo0 udp 127.0.0.1:40491 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:40491 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:3303 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:14691 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:24498 SINGLE:MULTIPLE lo0 udp 127.0.0.1:2715 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:2715 SINGLE:MULTIPLE lo0 udp 127.0.0.1:37793 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:37793 SINGLE:MULTIPLE lo0 udp 127.0.0.1:26492 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:26492 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:46176 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:61273 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:31460 SINGLE:MULTIPLE lo0 udp 127.0.0.1:22542 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:22542 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:47157 SINGLE:MULTIPLE lo0 udp 127.0.0.1:4973 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:4973 SINGLE:MULTIPLE lo0 udp 127.0.0.1:31373 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:31373 SINGLE:MULTIPLE lo0 udp 127.0.0.1:3292 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:3292 SINGLE:MULTIPLE lo0 udp 127.0.0.1:26860 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:26860 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:20080 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:23008 SINGLE:MULTIPLE lo0 udp 127.0.0.1:64516 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:64516 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:51168 SINGLE:MULTIPLE lo0 udp 127.0.0.1:7419 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:7419 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:48626 SINGLE:MULTIPLE lo0 udp 127.0.0.1:63417 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:63417 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:36969 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:8434 SINGLE:MULTIPLE lo0 udp 127.0.0.1:4106 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:4106 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:63602 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:8706 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:43514 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:3325 SINGLE:MULTIPLE lo0 udp 127.0.0.1:28131 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:28131 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:49626 SINGLE:MULTIPLE lo0 udp 127.0.0.1:26090 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:26090 SINGLE:MULTIPLE lo0 udp 127.0.0.1:43222 -> 127.0.0.1:53 MULTIPLE:SINGLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:43222 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:40824 SINGLE:MULTIPLE lo0 udp 127.0.0.1:53 <- 127.0.0.1:54960 SINGLE:MULTIPLE

I only have snort installed but that wasnt doing an update and I think that goes elsewhere iirc. No widgets installed, no autoconfigbackup installed, wasnt in packages, how would I know about a bogons as I cant see anything in the logs? I've been trying to adopt the backtrack tag "The quieter you become, the more you are able to hear.", so things like Windows nic phone home is off, http://technet.microsoft.com/en-us/library/cc766017(v=ws.10).aspx, as is windows updates, in fact that only gets initiated when a snort surpress for exe's, dll's aka PE's is enabled until the updates are completed then it goes back on again. And because it can take AV companies months sometimes years to reverse engineer and then decide if some code is malicious, not to mention the AV programs miss a % of virus according to shadowserver.org https://www.shadowserver.org/wiki/pmwiki.php/AV/Viruses I try to be careful and I have an enquiring mind.  ;)

I now see this when I add a new user but can log in ok as the newly created user. Jan 19 22:54:19 php-fpm[6634]: /system_usermanager.php: The command '/usr/sbin/pw groupmod admins -g 1999 -M '0,2003' 2>&1' returned exit code '67', the output was 'pw: user `2003' does not exist' Jan 19 22:54:19 php-fpm[6634]: /system_usermanager.php: Tried to remove user but got user pw instead. Bailing.

@falumas: Hyper-V 2012r2 network speed is 10Gbps to VMs, the speed to pfSese might be a bit slower since freebsd works with an older version of the hyper-v driver for the network card. One thing that I have noticed with this is that the speed is very dependant on CPU speed for Hyper-V. If I have understod things correct. The pfSense team will work together with MS after the 2.2 release to solve this. Given the conversations I've had with Microsoft, and presentation from them, my understanding is that we're running something quite recent.  Microsoft's current focus on FreeBSD is enhancements to Vmbus and storage for HyperV.  These went in 6 days ago: https://github.com/FreeBSDonHyper-V/freebsd/commit/926c32128af7e987669acfd399bddc653783d516  and I didn't think it was worthwhile to put them in now, especially when the impact for pfSense won't be that visible.

@jimp: 2.2.1 should follow up before too long after. :-X

Something else is bound to port 53, which is making unbound fail to restart under that circumstance.

I assume you've read this: @ermal: For bridge you have to set the sysctl where pf filters will be applied by default they are on member interfaces. That makes sense if the altq shaping is tied into pf and pf is filtering on the members then applying shaping to the bridge isn't going to work. That hadn't occurred to me, thanks Ermal.  :) Normally I would expect the filtering to have been moved to the bridge in a setup such as yours already though. Steve