UPDATE:

The last monday upgrade (April 8) seems to have fixed it. RRD Quality stats are now back and been working perfectly since..

Not sure what was wrong but got that bug from and update and lost it the same way… nothing changed on my side.

Anyway ty! Just wanted to let you know

Still seems busted, I did finally get to test with the negate disabled but that made no difference.

Any specific part of the rules.debug you are after?

I am running the latest snap shot avail but no joy :(

Thx in advance for your assistance.

I did some investigation and think I figured out what is causing the issue.  When the gateway for the openvpn interface has custom settings the return_gateways_array() function in gwlb.inc returns the gateway array  like the following

Array (     [VPN_VPNV4] => Array         (             [interface] => ovpnc1             [gateway] => dynamic             [name] => VPN_VPNV4             [weight] => 1             [ipprotocol] => inet             [interval] =>             [descr] => Interface VPN_VPNV4 Gateway             [monitor] => 10.8.0.1             [dynamic] => 1             [friendlyiface] => opt1             [attribute] => 0         )     [WAN_DHCP] => Array         (             [dynamic] => 1             [ipprotocol] => inet             [gateway] => 72.38.36.111             [interface] => em1             [friendlyiface] => wan             [name] => WAN_DHCP             [attribute] => system             [defaultgw] => 1             [monitor] => 72.38.36.129             [descr] => Interface WAN_DHCP Gateway         ) )

notice the open vpn interface's gateway attribute is set to dynamic.

Here is what the array returns when using no custom gateway settings

Array (     [VPN_VPNV4] => Array         (             [interface] => ovpnc1             [gateway] => 10.8.0.17             [name] => VPN_VPNV4             [weight] => 1             [ipprotocol] => inet             [interval] =>             [descr] => Interface VPN_VPNV4 Gateway             [monitor] => 10.8.0.1             [dynamic] => 1             [friendlyiface] => opt1             [attribute] => 0         )     [WAN_DHCP] => Array         (             [dynamic] => 1             [ipprotocol] => inet             [gateway] => 72.38.36.111             [interface] => em1             [friendlyiface] => wan             [name] => WAN_DHCP             [attribute] => system             [defaultgw] => 1             [monitor] => 72.38.36.129             [descr] => Interface WAN_DHCP Gateway         ) )

As you can see it has an IP.

The function that creates the apinger.conf checks for a proper gateway. If the gateway is set to 'dynamic' no targert for that interface is created in apinger.confcausing the gateway status to always be unknown.

Here is block of code in the return_gateways_array function causing the issue.

/* if the gateway is dynamic and we can find the IPv4, Great! */ if (empty($gateway['gateway']) || $gateway['gateway'] == "dynamic") { if ($gateway['ipprotocol'] == "inet") { /* we know which interfaces is dynamic, this should be made a function */ switch($wancfg['ipaddr']) { case "dhcp": case "pppoe": case "pptp": case "ppp": $gateway['ipprotocol'] = "inet"; $gateway['gateway'] = get_interface_gateway($gateway['interface']); /* no IP address found, set to dynamic */ if (!is_ipaddrv4($gateway['gateway'])) $gateway['gateway'] = "dynamic"; $gateway['dynamic'] = true; break; } }

Here is what I changed it to, which seems to make it work. There is probably more correct way to do this.

/* if the gateway is dynamic and we can find the IPv4, Great! */ if (empty($gateway['gateway']) || $gateway['gateway'] == "dynamic") { if ($gateway['ipprotocol'] == "inet") { /* we know which interfaces is dynamic, this should be made a function */ switch($wancfg['ipaddr']) { case "dhcp": case "pppoe": case "pptp": case "ppp": $gateway['ipprotocol'] = "inet"; $gateway['gateway'] = get_interface_gateway($gateway['interface']); /* no IP address found, set to dynamic */ if (!is_ipaddrv4($gateway['gateway'])) $gateway['gateway'] = "dynamic"; $gateway['dynamic'] = true; break; default: $gateway['ipprotocol'] = "inet"; $gateway['gateway'] = get_interface_gateway($gateway['interface']); /* no IP address found, set to dynamic */ if (!is_ipaddrv4($gateway['gateway'])) $gateway['gateway'] = "dynamic"; $gateway['dynamic'] = true;   break; } }

Thanks,
Adam

Just a consequence of how the auto-added policy routing negation rules work, that's how it's supposed to work.

This should be fixed all-around in current snapshots. It will ignore the none if it's there and edit/save will remove it.

I have been delaying a full reinstall for the past 4 days. I routinely shut down pfsense at the end of each day … for some reason today the wireless decides to load the driver and function  :-\

After a lot of fiddling around I finally managed to fix it. The clients cached their leases and somehow preferred their own cached leases toward the lease that pfSense offered them.
(Even though I did "dhclient -v -6 eth0 -r" and then "dhclient -v -6 eth0" to release/renew). Weird.

That's how things are supposed to work and always have worked. If a NIC is down, its IP is unreachable. You can get in by the OpenVPN server IP, or the WAN IP or some other IP that's on a live NIC.

1.2.3 and 2.1 are no different in this regard. New connections that match a rule with logging enabled are logged.

Not supposed to work, input validation should prevent that config.
http://redmine.pfsense.org/issues/2941

That's a bug:

If you change the settings for ipsec from WAN1 (dhcp) to WAN2 (static ip) the route over WAN1 still exists and ipsec won't work until you reboot the pfsense and the route is deleted.

I don't know if this is still wanted, because if it's use gateway groups or static IPs no routes are made:

If a interface has dhcp there will be a host route to the ipsec destination.

Did it reboot itself, or actually turn its own power off?

If the power went off and stayed off, usually that was done by the BIOS – most often for an overheating condition.

My intention is not to config a pfsense.
My intention is to make the GUI clear for other users.

I speak about the crypted packets of openvpn client.

Assuming the default route is on interface WAN2.
If you config an interface (WAN1) for an openvpn client the pfsense will never take the rules (NAT or filter) for this interface (WAN1).
But the GUI will let you think that the rules for WAN1 will be choosen.

If you have OpenVPN set to "any" interface, then UDP traffic replies will always go out via the system's default route.

I'm not speaking about replies.
It doesn't matter which interface you set for openvpn client, the UDP/TCP traffic will always go out via the system's default route.
It always uses the rules (NAT, filter) of the default route interface and not the interface which is set for the openvpn client.
After this the outgoing interface will be choosen by the source ip address of the packet.

It's not clear for somebody that the rules of an other interface, than the configured, are the right one.

Should hopefully be fixed by https://github.com/pfsense/pfsense/commit/4fd2fed2ad6672c3be771146048bee61317f3197

I split this off into its own topic since it is more of an AES-NI question than directly related to that other thread.

We have observed some similar issues (see the other threads about AES-NI, especially http://forum.pfsense.org/index.php/topic,54008.0.html ) but we don't have any AES-NI capable hardware in our lab yet to tinker with.

Having the AES-NI module loaded hooks into the crypto system of FreeBSD so that IPsec can take advantage of it, and OpenVPN will latch on as well.

OpenSSL 1.0.1e does have its own AES-NI code, but the way it selects its engine is based on which ciphers have registered engines. If there is an engine that offers to support AES, it will be used over OpenSSL's internal code. That explains why it is slower with AES-NI loaded no matter what you select in the OpenVPN engine list.

In this case it would appear that OpenSSL's internal code handles AES-NI better than FreeBSD's crypto engine hooking into AES-NI but why that is the case exactly, I'm not sure. There may be some other bit for FreeBSD's AES-NI code that we're missing or that needs setup/optimized in some way.

I like this one if you can find still find it:

http://www.newegg.com/Product/Product.aspx?Item=N82E16859324026

dual gigE, fanless, Intel Atom D2700 2.13GHz 2C/4T