There were some changes to that since 1 November - https://github.com/pfsense/pfsense/commit/d5566d43f4ace5036b5e5476d975bb8d13ce3b6f So update to the latest snapshot and then report back.

@cmb: Looks like it connects just fine initially, then you stop getting replies to your echo requests, indicating a dead connection. Are those logs entirely from before you fixed it? If so, what does it look like after fixing? You mean I am too impatient? You mean it would take >10 mins … ? Nov 5 22:26:59 ppp: [wan] IPV6CP: Open event Nov 5 22:26:59 ppp: [wan] IPV6CP: state change Initial –> Starting Nov 5 22:26:59 ppp: [wan] IPV6CP: LayerStart Nov 5 22:26:59 ppp: [wan] IPCP: Up event Nov 5 22:26:59 ppp: [wan] IPCP: state change Starting –> Req-Sent Nov 5 22:26:59 ppp: [wan] IPCP: SendConfigReq #1 Nov 5 22:26:59 ppp: [wan] IPADDR 0.0.0.0 Nov 5 22:26:59 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Nov 5 22:26:59 ppp: [wan] PRIDNS 0.0.0.0 Nov 5 22:26:59 ppp: [wan] SECDNS 0.0.0.0 Nov 5 22:26:59 ppp: [wan] IPV6CP: Up event Nov 5 22:26:59 ppp: [wan] IPV6CP: state change Starting –> Req-Sent Nov 5 22:26:59 ppp: [wan] IPV6CP: SendConfigReq #1 Nov 5 22:26:59 ppp: [wan] IPCP: rec'd Configure Request #1 (Req-Sent) Nov 5 22:26:59 ppp: [wan] IPADDR 213.129.228.1 Nov 5 22:26:59 ppp: [wan] 213.129.228.1 is OK Nov 5 22:26:59 ppp: [wan] IPCP: SendConfigAck #1 Nov 5 22:26:59 ppp: [wan] IPADDR 213.129.228.1 Nov 5 22:26:59 ppp: [wan] IPCP: state change Req-Sent –> Ack-Sent Nov 5 22:26:59 ppp: [wan] IPV6CP: rec'd Configure Request #1 (Req-Sent) Nov 5 22:26:59 ppp: [wan] IPV6CP: SendConfigAck #1 Nov 5 22:26:59 ppp: [wan] IPV6CP: state change Req-Sent –> Ack-Sent Nov 5 22:26:59 ppp: [wan] IPCP: rec'd Configure Reject #1 (Ack-Sent) Nov 5 22:26:59 ppp: [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid Nov 5 22:26:59 ppp: [wan] IPCP: SendConfigReq #2 Nov 5 22:26:59 ppp: [wan] IPADDR 0.0.0.0 Nov 5 22:26:59 ppp: [wan] PRIDNS 0.0.0.0 Nov 5 22:26:59 ppp: [wan] SECDNS 0.0.0.0 Nov 5 22:26:59 ppp: [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent) Nov 5 22:26:59 ppp: [wan] IPV6CP: state change Ack-Sent –> Opened Nov 5 22:26:59 ppp: [wan] IPV6CP: LayerUp Nov 5 22:26:59 ppp: [wan] 020d:b9ff:fe18:aeec -> 8a43:e1ff:feba:fe18 Nov 5 22:27:00 ppp: [wan] IFACE: Up event Nov 5 22:27:00 ppp: [wan] IFACE: Rename interface ng0 to pptp0 Nov 5 22:27:00 ppp: [wan] IPCP: rec'd Configure Nak #2 (Ack-Sent) Nov 5 22:27:00 ppp: [wan] IPADDR 213.129.238.225 Nov 5 22:27:00 ppp: [wan] 213.129.238.225 is OK Nov 5 22:27:00 ppp: [wan] PRIDNS 213.129.226.2 Nov 5 22:27:00 ppp: [wan] SECDNS 213.129.232.1 Nov 5 22:27:00 ppp: [wan] IPCP: SendConfigReq #3 Nov 5 22:27:00 ppp: [wan] IPADDR 213.129.238.225 Nov 5 22:27:00 ppp: [wan] PRIDNS 213.129.226.2 Nov 5 22:27:00 ppp: [wan] SECDNS 213.129.232.1 Nov 5 22:27:00 ppp: [wan] IPCP: rec'd Configure Ack #3 (Ack-Sent) Nov 5 22:27:00 ppp: [wan] IPADDR 213.129.238.225 Nov 5 22:27:00 ppp: [wan] PRIDNS 213.129.226.2 Nov 5 22:27:00 ppp: [wan] SECDNS 213.129.232.1 Nov 5 22:27:00 ppp: [wan] IPCP: state change Ack-Sent –> Opened Nov 5 22:27:00 ppp: [wan] IPCP: LayerUp Nov 5 22:27:00 ppp: [wan] 213.129.238.225 -> 213.129.228.1

Ok, it's fixed with the newest snapshot  ;D

Thanks, I just pushed a fix for that. It'll be in the 5th and newer snapshots.

Yes, since at least 31-Oct, but I have not been in a position to test it.

Apologies, I am an idiot. I reset to factory defaults and set up basic stuff and it all worked fine. Then put back the original config and then looked hard at the config - there were some traffic shaper queues set up on LAN! One had "default queue" checked and limited to 111 Kbps. Removed all traffic shaper settings and now everything is fine. There is no software, firmware or hardware issue, it did exactly what it was told. I had completely forgotten that I had played with Traffic Shaper a while ago. Sorry for the time waste - to my friends, and to me.

hi, there is nothing special about my config: I put pfSense in a VM, there are three active adapters in which each adapter of pfSense is connected to a vswitch. Currently there are one WAN (its vswitch has a physical adapter connected to) and two LAN. I plan to add two PPPoE connections to my pfSense to replace current physical router so I add two more adapters and config it to use PPPoE. The issue happened right when I add two more VMXNET3 and reboot pfSense. Then I change them to E1000 -> pfSense acted normally. I did report to this forum at that point. Last weekend, I decided to add one more adapter for another LAN. Added VMXNET3 -> failed. Changed to E1000 -> OK. The VM is nanobsd and is installed with 2.2 snapshot about 1 month ago. I did not capture the traffic at the failed moment. I will try to do it again when I have chance (the pfSense currently handle NAT for some VMs now) I think basic features of pf is stable enough for using.

Works perfectly. Just have to run these commands after every upgrade.

Good news, many thanks for the info!

Oops, sorry!  Guess I still don't get the FreeBSD release engineering process

@karl23: Thanks - that explains why unity didn't immediately fix the problems I am seeing. Could you also enable charon.accept_unencrypted_mainmode_messages ? This is a sonicwall specific quirk as noted in the documentation here https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf On new snapshots there is an IPsec setting for enabling this.

@charliem: Can this replace the existing GUI option for state killing when a gateway goes down (system - advanced - miscellaneous)? No, those are two completely separate things. Your IP may not change when a gateway goes down, and your gateway may not go down when your IP changes.

Ok, problem fixed. Port Forwarding is working, the problem was definitely that: https://redmine.pfsense.org/issues/3760. PS Please MOD you can put a big SOLVED in the title!

@charliem: Bug now opened here: https://redmine.pfsense.org/issues/3947 This is fixed by today's snapshot with strongswan updated to 5.2.1.  Thanks!

Both sides firewall logs are ok. I have inspected all logs, tried to use different interfaces, but always with the same result. The value in the interface field seems to be ignored… Status -> Ipsec shows the tunnle up, Dashboard -> ipsec -> tunnels shows phase 2 down. Also after yesterdays snapshot, i wasn't able to ping connected openvpn clients any more from the lan. ping from pfsense was still possible. After switching back to 2.15 with the same config everything was working...

Don't do that. Really, don't do that. It's not likely to work much of the time for a program that large/complex and odds are it will pull in libraries that may conflict with versions we include already. You should never need to mess with pkg2ng either unless you upgraded from an older version where you also manually added packages which is asking for even more trouble. Don't treat the firewall like a shell box. If you want to browse the filesystem, connect via scp from a system that can display the files how you want.

The big speed advantage with 2.2 you're going to see is the multi-core capable pf in FreeBSD 10. I think that the maintainer of the Snort and Sucuricata packages mentioned he was working on making them scale better across many cores though. Edit: Can't find where I read that now though.  ::) Steve

It probably will do, but I found creating an interface connected as a trunk to be tricky in Hyper-V. The solution I found to be the easiest was to add 4 NICs to pfSense virtual machine and connect each of these NICs to an individual VLAN. Then within pfSense you don't use VLANs at all, pfSense sees each of these NICs as separate interfaces on separate networks. Remember, you'll need to think about if and what VLAN you connect the Hyper-V host machine to when configuring the Hyper-V switch itself.

Oook i apply defaults  :-X ty