yep,

just ignore that status.

http://support.microsoft.com/kb/2956569

Its a vm, so I just cloned and ran the upgrade process so I'll run it again just to be double sure.

I've checked the backups so far and the staticmap node shows 3 child nodes mac, ipaddrr & hostname with the right text values  for the single static mapping that exists. There are other nodes in staticmap but they have no child entries or values to speak off and is the same for pf2.2 backups.

The version for the pf2.1 backup config showed version 10.1, pf2.2 is showing version 11.1 in the backup config and no staticmap in that xml file after it was upgraded.

The staticmap only appears in the pf2.2 version 11.1 backup config after I added it back through the gui, but the other thing I have noticed is a new entry called "cid" which appears between the mac and ipaddr nodes. Maybe this "cid" is gumming up the works?

Where it ends up showing "tstp never" is where you have BOOTP leases, it mis-parses them (because BOOTP leases have no end, and are output differently in the leases file). It should just show "never" whether viewing in UTC or local time.

https://redmine.pfsense.org/issues/3945

It is still useful if HTTPS is broken or the cert is broken somehow.

I think as long as the redirecting to dashboard that works for me. Maybe in version 2.2.1 someone with the skill or will add the extra code. Thanks for checking.

I have updated newest snapshot, it seems that IKEv1, PSK + XAuth is working.
I am trying IKEv1, RSA but failed (I tried IKEv2, EAP-TLS but failed then step back to IKEv1).
I am not sure if the certificate has issue (I use the Cert Manager on pfSense to create the certs, CA, it is quite useful if things work)
Thank you for your recomment.

@ermal:

AES-GCM is not supposed for phase1 without selecting a proper hash.

I would recommend it only for phase2.

It is there because of generic implementation but do not use it on phase1.

I kind of figured that but couldn't find any documentation on it. Thanks!

Strange - Let put that in the "not broken" category then (-:

Thanks, Phil.

What if we moved the checkbox from the DHCP Server settings page to the DHCP Leases page?  It's not really a DHCP Server setting, but a DHCP Lease display setting.  Moving it would eliminate confusion by putting the global setting in only one place, and it would make it very easy to find since it's on the same page it affects.  To make it work for DHCPv4 and v6, we'd either need two global settings or use your idea for two checkboxes that link to one setting.

I'm just trying to think of how to make it easiest for everyone, including new users.

Additional logs added to original post.

2.2-BETA (amd64)
built on Tue Oct 14 17:37:25 CDT 2014
FreeBSD 10.1-RC2

[2.2-BETA][admin@apu22.localdomain]/root(8): time /etc/rc.conf_mount_rw 0.158u 0.055s 0:00.22 90.9%    4097+328k 0+30io 0pf+0w [2.2-BETA][admin@apu22.localdomain]/root(9): time /etc/rc.conf_mount_ro 0.153u 0.069s 0:00.44 47.7%    4053+331k 0+43io 0pf+0w [2.2-BETA][admin@apu22.localdomain]/root(10): time /etc/rc.conf_mount_rw 0.146u 0.069s 0:00.22 90.9%    4254+334k 0+30io 0pf+0w [2.2-BETA][admin@apu22.localdomain]/root(11): time /etc/rc.conf_mount_ro 0.174u 0.047s 0:00.44 47.7%    3898+319k 0+42io 0pf+0w

My APU is feeling much happier now, thanks.

The IPsec backend changed between 2.1.x and 2.2. On 2.1.x it's racoon, on 2.2 it's strongswan.

The difference is in how racoon sends the network data to shrew compared to how strongswan sends it.

2.2 has hyper-v drivers built in

The redirect does what it's supposed to do – It returns you to the page listing the settings for that interface. It isn't meant to return you to where you came from originally. I suppose it could, but it would require a bit of extra logic to accomplish. Probably not something we'd do ourselves, but if someone submitted a patch/pull request it might be considered.

The static leases will not be moved away from the DHCP server settings. The leases view is a common view for all interfaces. The static mappings are a per-interface setting and not a global setting. It does not make sense to move them.

@jimp:

Probably not for 2.2, but perhaps after 2.2 at some point.

Sounds promising…
...if there's no(t much) CPU dependency in the code, then an unofficial, unsupported build might be relatively easy to do.
In any case, the perspective is thrilling.

Ronald

It turns out UDP only seems to work in Pure NAT mode with the 'Enable automatic outbound NAT for Reflection' option in the advanced firewall settings is checked.  If I use NAT + Proxy then the firewall stops accepting all LAN outgoing (or to the firewall connections including ping) when connections are initated from the LAN to the external IP on that UDP port.  The firewall is able to connect to LAN systems during that time though which is odd.  As soon as I reboot the firewall the LAN works again.  The firewall console works just fine during all this time.

Didn't work
Pure NAT reflection (Enable automatic outbound NAT for Reflection = UNCHECKED):
LAN udp l.a.n.70:23098 (w.a.n.54:23098) <- l.a.n.70:44428 NO_TRAFFIC:SINGLE
LAN udp l.a.n.70:44428 -> l.a.n.70:23098 SINGLE:NO_TRAFFIC

–------------------------

Worked:
Pure NAT reflection (Enable automatic outbound NAT for Reflection = CHECKED):
LAN udp l.a.n.70:23098 (w.a.n.54:23098) <- l.a.n.70:59853 MULTIPLE:MULTIPLE
LAN udp l.a.n:33208 (l.a.n.70:59853) -> l.a.n.70:23098 MULTIPLE:MULTIPLE

Firewall stops passing incoming connections from the LAN.  Can't ping firewall LAN IP, DNS fails, etc.  Connections from the firewall itself  to the lan (SSH to a lan server worked):
NAT + Proxy (Enable automatic outbound NAT for Reflection = CHECKED):

Didn't test this time but this is the scenario that caused the same issues above the last time I tested.
NAT + Proxy (Enable automatic outbound NAT for Reflection = UNCHECKED):

I am using rtl drivers so maybe this is just triggering some other hardware or rtl driver issue.  With these results it seems the firewall should only allow Pure NAT with UDP because if something connects to the external IP on the UDP port it can cause traffic incoming from LAN clients to stop working completely.  The text description in the Advanced firewal settings mentions that NAT + proxy works for UDP.  At a minimum maybe that should be changed.

NAT Reflection mode for port forwards : When enabled, this automatically creates additional NAT redirect rules for access to port forwards on your external IP addresses from within your internal networks. The NAT + proxy mode uses a helper program to send packets to the target of the port forward. It is useful in setups where the interface and/or gateway IP used for communication with the target cannot be accurately determined at the time the rules are loaded. Reflection rules are not created for ranges larger than 500 ports and will not be used for more than 1000 ports total between all port forwards. Only TCP and UDP protocols are supported. The pure NAT mode uses a set of NAT rules to direct packets to the target of the port forward. It has better scalability, but it must be possible to accurately determine the interface and gateway IP used for communication with the target at the time the rules are loaded. There are no inherent limits to the number of ports other than the limits of the protocols. All protocols available for port forwards are supported. Individual rules may be configured to override this system setting on a per-rule basis.

I am running the latest build during these tests…
2.2-BETA (i386)
built on Mon Oct 13 18:40:19 CDT 2014
FreeBSD 10.1-RC2

Hardware is an Axiomtek NA-0043A which I have been using for about 2 years on pfsense using the Realtek 8100C chipset with 1GB of ram.

Basically, build the kernel module on a FreeBSD 10.1 box and then transfer it to the pfSense box. Load it at boot time to over-ride the in kernel driver by adding:

if_ixgbe_load="yes"

to the file /boot/loader.conf.local

Steve

Just upgraded my unit, Supermicro A1SRi-2558 based, so good, so far.