With debug logs on I got some more useful info. I just rebooted the server to make sure everything starts from scratch.

First, only some of the tunnels came up. Of those tunnels that came up only some of them got their child security associations. This is what is logged for the transport mode security associations that didn't come up (I can see this same thing in the log for each):

Mar 28 11:57:36 gateway2 charon: 15[IKE] traffic selectors 222.127.xx.xx/32|/0 222.127.xx.xx/32|/0 === 193.239.xx.xx/32|/0 193.239.xx.xx/32|/0 inacceptable
Mar 28 11:57:36 gateway2 charon: 15[IKE] <con12|19>traffic selectors 222.127.xx.xx/32|/0 222.127.xx.xx/32|/0 === 193.239.xx.xx/32|/0 193.239.xx.xx/32|/0 inacceptable
Mar 28 11:57:36 gateway2 charon: 15[IKE] failed to establish CHILD_SA, keeping IKE_SA
Mar 28 11:57:36 gateway2 charon: 15[IKE] <con12|19>failed to establish CHILD_SA, keeping IKE_SA

For the tunnel mode connections, if I grep for the IP of the other end I can't see anything like this in the log, I can only see the send/receive packet entries so I might need to disable all tunnels to be able to get the logs just for that specific host…</con12|19></con12|19>

@cmb:

Stock FreeBSD also isn't pushing the traffic through pf, scrub, etc. Disable the packet filter under System>Advanced, Firewall/NAT and you'll have an equivalent test from that perspective. Try that and see if that's the difference.

Cats, dogs (love them both) or throughput related.  This is not a 2.3 snag.

Please punt

@cmb:

[…]Yes, "many firewalls" will block it, but it's not a problem with the firewalls, it's that the application is broken.

The problem is not that way :) When I had problems with users using Ares Galaxy (almost ten years ago) solutions I have used can't block that p2p software. This software very quickly exhaust available bandwidth.

@cmb:

Your config is correct.

Go through the troubleshooting steps no differently from any other version. You can eliminate common problems #1 assuming your config's still as it was when those screenshots were taken.
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

I followed mostly troubleshooting from your link earlier. Mostly, because 10.0.10.100 box is not property of my company and I can't log into it.
But…I would like to thank jimp and cmb for ensuring me that port forwarding with multi WAN config works in pfSense BETA, thanks to what I began to investigate much deeper and found a "bug" :)
An hour before I migrated from previous system to pfSense, someone from company supporting that device logged in and changed (probably by mistake) default gateway. From LAN side HTTP server on 10.0.10.100 worked properly, but port forwarding didn't work.
Because I'm newbie in pfSense I assumed that I configured something improperly :)

@BlackDwarf:

LCDProc doesn't exist in the available packages,

Is anyone else running 2.3 on Watchguard hardware?

Dah! I knew that…  Really!  :P      Ive got one Xcore-e box left in production and its my only box still on 2.2.6 just because I want to throw 2.3 on one I have here sitting on the shelf to test first.  Other than that the other Watchguards I have are XTMs and run fine.

Can you move over to your MSK interfaces and give them a try?  They would have higher throughput anyways as they are on a PCIe bus.  SK interfaces are on a PCI bus.

Cool! the message stop flood logs

Thanks :)

Ok thanks, they are. For others distracted, like me, should be a link then. Only a idea.

I've seen these "mail bombs" too.  There's even a ticket for it- https://redmine.pfsense.org/issues/4031  (which now says target version is 2.4)

How does the dedupe work? Does it just hash the outgoing messages and not send again if the new hash matches the previously sent one within a certain amount of elapsed time? I could see how this results in a bomb because sometimes you get alerts in rapid fire like

MONITOR: WAN1 is down
MONITOR: WAN2 is down
MONITOR: WAN1 is down
MONITOR: WAN2 is down
…ad infinitum...

If that's how it works, I would suggest it would be great to have a knob we could tweak that says "Send no more than X number of alerts within Y minutes".  And if this was set to e.g. X=2, Y=15 then regardless of the contents of the emails (even if it was "the CPU is on fire!") the unit would not send out more than 2 alerts in a 15 minute window. Chances are the 1st critical alert is enough to prompt you to try to remediate the situation anyhow.

I think the build in question must have been pulled… when I got home last night and checked for updates, I was offered an update that was built at 0633 yesterday morning... nonetheless, there's a new build from 0516 this morning available now.

ok sorry haven't kept up with tickets my internets been hit and miss today even with dual wan maybe figure what i missed in Friday hangout

@virgiliomi:

And then there are those with multi-WAN setups… How about a drop-down or widget setting to pick whatever interface you choose, and just show in/out for that interface?

It will be a multi-select box or similar that allows you to select any number/combination of interfaces (both in and out for each).

So far the options I have planned are: Select interface(s), invert outbound, and refresh interval.

Something else I was going to play with was a totals line, but that sounds more complicated than I originally thought.

@virgiliomi:

Want to see multiple interfaces, add the widget multiple times.

There currently isn't code in place that allows a widget to be used multiple times and configured in multiple ways, so that would have to be implemented first and would also be useful for the monitoring widget (that doesn't exist…yet?)

Group names with spaces are invalid on pfSense. Add an AD group name without spaces if you want to use it on pfSense in that way.

Until a few days ago they were not blocked, but also malfunctioning at the OS level.

Rate limiting of captive portal clients who are making too many requests to the portal. Probably some background process hammering away trying to get to the Internet on a system that isn't authenticated.

Just pushed a fix.

Available via gitsync right now and in the next snapshot. (Current snaphot is 2.3.b.20160322.1146 so the next one after that)

it seems doktor, not this more showing up the forum ..
I hope that some developer can help us.

after update in clamav database , clamav is not updating …
i thing is need change something in code ..

http://blog.clamav.net/2016/03/clamav-signature-interface-maintenance.html

PS : if anyone need more informations , please tell me .

@biGdada i don't remember. Should have dome some screen shots. Most of the time the problems are tagging VLAN Interfaces. Power off and power one solve the problem, the similarity to your resolution. Restarting it was not sufficient.

Maybe latter i will try after build a new bare metal machine for pfSense, i can't do it now, sorry.

The latest commit to diag_traceroute.php introduced that syntax error. The code at line 169 does not need a semi-colon at the end.
https://github.com/pfsense/pfsense/pull/2775

Thank you all for the clarification. Got worried when I saw VPN traffic without authentic action.