Messages

Ich hatte früher den Eindruck L2TP/IPsec ist für Apple-Anbindung die beste Wahl. pfSense hat ein Dokument dafür:

https://doc.pfsense.org/index.php/L2TP/IPsec

Schon mal probiert oder schon überholt?

Gruss
Franco

ZFS is a challenge. FWIW, you could now install FreeBSD on ZFS, bootstrap OPNsense from this system and deal with the fallout in the rc scripting. Far from stable, but it's work that will to be done next year, maybe for 16.7.

https://github.com/opnsense/update/commit/e3f63ecdb1149a8cc30e36027ff9f9ac8e31f12f

Firewall: NAT: Port Forwarding. Is there a more specific question you have? The rules there are verbosely annotated. :)

I'm not seeing a VLAN Adapter in the Windows 7 Host? If you add one, you can bridge it to virtual box. Anything else will likely not work.

http://www.heise.de/netze/artikel/Windows-224006.html

We're investigating this, though this is so far out of our immediate scope to trigger this behaviour. We are looking for specific feedback and steps to reproduce with 15.7.20, it will most likely take a short cycle to 15.7.21 to get to the bottom of this and fix it for good. More on this tomorrow.

Hi Jacobq,

Yes, some boards tend to do this. It could be fixed in the BIOS, but it's a very rarely asked question these days for vendors.

Welcome to OPNsense. :)


Cheers,
Franco

Another possibility would be to take the release image, import the config via the option in the installer and reinstall via quick/easy. Your fully configured system will come back up, except if you're using plugins (xen, vmware).

15.7.18 is available as an image, as well as 15.7.11. 15.7.11 will update to 15.7.17 in the first full firmware cycle, that may also be a viable target.

Note that the instructions will change once 15.7.20 is out tomorrow. We also talked to the suricata devs briefly and they have a 2.1 release candidate coming out hopefully this week, but we'll test with beta4 for now, it's looking good so far. 2.1 is scheduled for December, so it'll be the default for OPNsense 16.1. :)

Fehler treten weiterhin eher sporadisch auf, das macht das Debugging so schwierig. Mit 15.7.20 kommt verbessertes Debugging, 15.7.21 hat dann auch hoffentlich den Fix.

Siehe: https://github.com/opnsense/core/issues/473

Well, it'll take you back to 10.1 and you'll need to modify the script check for "10.1-RELEASE". Going backwards is generally unsupported in likely most scenarios, but being a stable branch family with ABI compatibility it ought to work out fine.

The cautious fix would be to release OPNsense on 10.2, and then lift the restriction, so that any 10.x will go to the latest 10.2. But the state of 10.2 is unappealing still. Maybe 10.3, but 11 is far shinier.

We are releasing opnsense-bootstrap with 15.7.20, it's a tool designed to reinstall OPNsense cleanly, and it also works on a stock FreeBSD. See the announcement here:

https://github.com/opnsense/update/commit/e3f63ecdb1149a8cc30e36027ff9f9ac8e31f12f

Using it on your FreeBSD 10.1-RELEASE installation on UFS works like this:

# fetch https://github.com/opnsense/update/blob/master/opnsense-bootstrap.sh
# sh opnsense-bootstrap.sh

If you can prepare a config and move it to /conf/config.xml before calling the tool it will even boot up with the correct settings. :)

This is pre-15.7.19? Because the last release has the fix for this, but it's not on the latest image. Nice work fixing it manually. :)

Was there any particular thing that you did before this happened?

PS: I think that this likely happens after a disk corruption.

We need to keep those files as long as the stable release supports the old captive portal in parallel so people don't unwillingly wipe their data by moving back and forth. We will remove stale files as soon as the stable/16.1 branch is created.

The patch has just now been added to the FreeBSD ports collection. Thanks for everyone involved for making that happen!! :)

VLANs in OPNsense are not needed and are likely discarded by the parent interface in the host.

Can you post your ifconfig for OSX and OPNsense?