Thank you for tracking

Two issues still outstanding there.

One, for upgraded configs.
https://redmine.pfsense.org/issues/4163
To work around that, just edit and save each phase 1 config.

Two, for multiple P2s.
https://redmine.pfsense.org/issues/4164
No workaround available there.

I'm guessing yours probably falls under the first there. If you edit and save each, does it then work?

Thanks for the feedback, that helped narrow things down to two remaining issues.

One, for upgraded configs.
https://redmine.pfsense.org/issues/4163
To work around that, just edit and save each phase 1 config.

Two, for multiple P2s.
https://redmine.pfsense.org/issues/4164
No workaround available there.

Seems I have figured out what the second part of the problem was. I got the "port forwards not working/no v4 pakets arriving on WAN".

Still hitting the first part of the puzzle (see first post). Those UDP logs are still hitting.

Used to operate the Netgate servers co-located in San Jose when I lived in Hawaii.  5000 mile plane trip if I screwed the pooch.  (Only happened once.)

It's never worked.

@jimp:

Given that we'd probably be better off with some upgrade code to explicitly set the iketype on upgrade so it isn't ever undefined, too.

Yes, there are already a few places in the code that treat empty iketype as ikev1, thus working with the old configs. A search for "iketype" turned up the 2 places above that did not handle the empty iketype case.

But it is nice that the config explicitly specifies things like this, because in 10 years when there is IKEv1,2,3,4… people will be a little confused by an ancient config with no iketype specified, and it saves future new code having to remember to handle the empty case.

I expect something has gone wrong reading the status response from the socket there - that code is a tight loop reading the response text and keeps going until it gets "" indicating end.
If something has gone wrong with the socket then it will go into a spin and eventually chew up 900 seconds and PHP will kill itself.
Some code like this should handle a socket read error there:
https://github.com/pfsense/pfsense/pull/1411

I can run with that change and nothing is broken, but I do not know how to create the socket read error to check that the error handling code really does do a reasonable thing.

As far as I've been able to determine, all the IPsec widget issues should be fine now. If you can still replicate anything there on the newest available snapshot, please provide details in a new thread on this board rather than continuing to hijack this one so we can follow up with everyone.

I managed to work around this by forgoing the pfSense bridge and just having the Quickbooks server connect to the same tap VPN as an OpenVPN client.

Still think my original approach should have continued working though, and that this is a bug.

thanks. Go figure the one system where I had a slew of test nsupdate things setup just happened to be 32 bit when most all my test/dev systems are 64.
https://redmine.pfsense.org/issues/4159

https://github.com/pfsense/pfsense-packages/commit/28c552b11ab71035755720ff2a6092f45b961439
There was a bug-fix update to Suricata just some hours ago. That fixed an installation issue for first-time installs of Suricata. Maybe you got the previous version, then next the new version that works.

the wan failure monitoring system needs work in my humble opinion , had an old xincom which was like syswan which had 3 methods of detection also more granular settings to load balancing  have not studied what or how else is currently on the market about to though. thought ermal made mention of replacing apinger in a post some where

Are these PSK tunnels with a " in the PSK by chance? That's the only circumstance where I can find any problems in the context of what you described.

which packages do you have installed? Looks like one of them has something broken with newer PHP versions.

You can check package reinstall status in the system log. That error likely hung up the process, so clearing the package lock and manually reinstalling will probably be necessary.

I am also seeing this under Hyper-V 3.0 and the 2.2 RC. It seems that every so often, apinger marks the WAN interface as down.

Dec 29 09:14:59 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 09:15:21 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 09:20:15 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 09:20:31 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 09:35:07 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 09:35:28 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:38:15 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:38:35 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:39:14 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:39:30 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:52:38 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 14:52:54 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down *** Dec 29 15:12:31 apinger: ALARM: WAN_DHCP(68.67.x.x) *** down *** Dec 29 15:12:48 apinger: alarm canceled: WAN_DHCP(68.67.x.x) *** down ***

It also seems to be related to traffic or packet load, as the frequency is greatly diminished overnight when I am not using my network.

FWIW, I ran Smoothwall under this same Hyper-V config until a few days ago when I noticed that pfSense 2.2 went RC and it did not experience these issues, so this is something unique to Hyper-V + pfSense or Hyper-V + FreeBSD.

I'm going to disable gateway monitoring and see if that at least masks the underlying issue. Note, state killing on gateway failure is not enabled (the box is checked) so I don't think that's the cause.

I know Hyper-V is probably a low priority, but I am extremely excited to be able to run it with non-legacy NICs, so I'd really like to get this resolved and will help in any way possible. This is perfect for my 1Gbps connection at home (under Hyper-V I can hit 850Mbps, my Atom D2500 couldn't manage more than 500Mbps) and I'd like to start using it in our Hyper-V environment for my business in addition to our physical installations.

If you guys would like me to open a paid support case, I'd be more than happy. I can also provide you with access to pfSense installed in a Hyper-V VM if that would help.

Additionally, I am finding additional problems with the IPSEC connections:

I have three tunnels to remote end points that with the exception of sites specific information (IP addresses) that are exact duplicates of each other, even to the point of running the same hardware.  All three sites are running version 2.15.

Since upgrading to the 2.2 RC stream on my local firewall, 1 of the remote connections works without fail.

The second site establishes a connection, but the no data can be passed across the tunnel to the remote side.  As can be seen in the first screen print the tunnel shows it is active but the child entry shows no packets being passed.

The third site also establishes the tunnel however it creates 10 child entries all with no data being passed. (second screen print).  This tunnel fails and then recycles after about 10 minutes.  During the process I find many of the following message in the IPSEC Log:

Dec 29 11:02:23 charon: 08[NET] sending packet: from 69.69.69.83[500] to 2.6.3.4[500] (420 bytes)
Dec 29 11:02:23 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
Dec 29 11:02:23 charon: 08[IKE] <con18000|623>received retransmit of request with ID 0, retransmitting response
Dec 29 11:02:23 charon: 08[NET] received packet: from 2.6.3.4[500] to 69.69.69.83[500] (372 bytes)

gschild.png
gschild.png_thumb
childentries.png
childentries.png_thumb</con18000|623>

ooops … so i completely misunderstand the philosphy behind until now!

I thought i have to ensure manually to make a backup from my slice. This means also, that there is no way to hold a defined backup of a working config on a different slice since the update and switch slice is performed automatically. Thanks for clarification and point me that out.

Pull request #1408 to back-out changes made to the CSS files.