Messages

Hi everyone,

is it possible to cascade VPNs?

Example:

Setup:
- Box 1 with WAN (Internet), LAN, DMZ. It is possible to enter the LAN from WAN through VPN.
- connected to LAN is Box 2 which sees the LAN of box 1 as its WAN. It has two own zones, e.g. WLAN and LAN2
- Box 2 shall only accept incoming traffic to its LAN2 from its WAN via VPN, let's call it VPN2

Task: A road warrior in the internet wants to connect to LAN2.

Question: The road warrior would need to connect via VPN first to LAN of box 1 and then from there on to connect again via a second VPN tunnel to LAN2 of box2, correct? Is that possible?

Thanx

In any case, when it comes to chose a SoC-device to support, I strongly recommend to study the list of flaws that the FSF outlines here https://www.fsf.org/resources/hw/single-board-computers and make a coice with as few flaws as possible.
The Raspberry Pi is not a good choice IMHO, as long as they stick to their blob strategy.

Here is a list with information about OS support and if BLOBs are needed or not: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#Operating_system

The topic on:

• Libreplanet: https://libreplanet.org/wiki/Group:Hardware/Single_Board_Computers
• reddit: https://www.reddit.com/r/linux/comments/2fujj7/single_board_computer_sbc_which_doesnt_require/

Cheers

Hello minimike!

Hey guys what you are thinking about a banana pi? The BPi-R1 looks very nice.

When I had first spotted the BPI-R1 I was enthusiastic about it since it seemed like the perfect solution for a firewall with its 5 NICs + WLAN. Unfortunately then I learned that it is not 6 physical interfaces but only a WLAN chip and a switch chip with 5 ports attached, check e.g. http://forum.lemaker.org/thread-12942-1-1.html. So it seems that someone could only create network zones by VLAN tagging which for security reasons I do consider to be inadequate, isn't it?

If that is true there seems not to be any significant advantage of the BPI-R1 over a Raspberry 1b, other than having e.g. SATA and a 5 port switch for a network zone, and of course more CPU power, etc...

Specs & images: http://www.banana-pi.com/eacp_view.asp?id=64

Regards

My whishlist is:

• Increase security of OPNsense file downloads:
  
  
  
  • Currently the download section points to mirrors which host the OPNsense files for download. The mirrors include checksums which is good, since it helps to check if the download was successfull or not. But it does not improve security, since someone who infiltrated the mirror and manipulated the download files can easily modify the checksums to match his manipulated versions, too, so the manipulations will remain undiscovered. Solution: Publish the checksums in visible text form and as downloadable files (only a few bytes of traffic) on the OPNsense website instead or in addition to having them only on the mirrors. This increases security, since a intruder will have to hack the mirror AND your website so to have the checksums match his manipulated files.
  • Even more of an improvement in security would be to additionally digitally sign the dowloads with GPG and publish the signature files & public key etc. on the OPNsense website and on the mirrors.
  • An example is e.g. Opensuse: https://software.opensuse.org/421/en
• Real time, dashboard-like, human readable, aggregated, in-depth, IP- or user-based network activity monitoring/ surveillance:
  See what all network clients are doing right now, e.g. IP 192.168.1.124 or user X is browsing websites a, b and c right now, has sent an email with subject xy and contens x to recipient yz, downloaded file x, etc. Possibility to record this activity information over a defined period of time and to export it, make statistics, etc. Usage possibilities: Network problem debugging, optimization, testing, learning, analyzing, etc., intrusion detection and intruder / trojan / backdoor behavor analyzing, legal investigation & evidence collection in case of e.g. fraudalent users/ employees. I assume that the use of this feature could be regulated by national laws in some jurisdictions, e.g. when the users are employees of a company, so there should be some warning info popping up when activating it, so the user can check his local laws first and use the features accordingly
• Live demo on website: I think it would be great marketing for OPNsense to offer a live demo on the website
• Firewall: Add outgoing filter. Currently on each interface only incoming traffic is handled and filtered, as it enteres the box. I would like to filter also traffic that leaves the box (i.e. packets that traverse the box or that are produced by the box) while it passes an interface when exiting the box again. This way I can much easyer overview and protect one network zone from traffic that wants to enter it (e.g. by having missconfigured another interface so that it lets traffic in and reach other interfaces while it should'nt) or traffic that is initiated on the box and wants to leave it while I do not want that.
• Plugins for hardware:
  
  
  
  • Daemon for uninterrupted power supply (UPS) from brand APC: apcupsd (http://www.apcupsd.org). It would be nice to be able to install, configure and monitor apcupsd via the OPNsense web interface
  • 3ware RAID controllers: a) Change SMART web interface support to pass settings to smartmontools that detect harddisks behind a 3ware controller (http://www.linuxweblog.com/smartctl-3ware-RAID) b) make a plugin for installing 3ware command line tool tw_cli (ftp://ftp.sgi.com/public/Technical%20Support/Pdf%20files/3Ware/9000/3ware_9000_CLI_User_Guide.pdf) and poll some overview & monitoring data through it for lobby plugin
  • ECC RAM: monitor ECC errors
• Honeypot: have one or multiple honeypots in isolated environments (VMs?) on the box, installable as plugins, including notifications in case of attack
• Refine & improve release cycle: I really like your decision to introduce a time based release scheme and your ambition to release 2 major releases per year (Jan & July). Additionally, it is really great that you release minor releases every week, this is really outstanding! Nevertheless I think that your scheme needs some refinement. The reason for this is that currently due to the fact that those weekly updates include not only bug and security fixes but also new features, things tend to seriously break very often and make those updates a real risk for anybody who is serious about his productive systems; actually - if someone takes "production grade" seriously and cannot afford even a tiny bit to risk his production networks, it is currently not possible to update for him.
  So what i propose is to further refine and improve your release scheme so to combine your really fast release ambition with reliable releases for users who need rocksolid versions for their businesses. The weel needs not to be reinvented though! Libreoffice has such a scheme which is outstanding and near to perfect, since it serves both user groups, those who want (or need) new features ASAP and those who need bullet-proof, rocksolid versions no matter what. And it is embedded in a 2-major-release-per-year approach, too. Here is a great introduction to their stategy: https://wiki.documentfoundation.org/ReleasePlan

Hi,

here https://opnsense.org/about/about-opnsense/#feature-set in the features section it still states 16.1 as in the future, this needs an update.

cheers

Hallo,

Aber gut, ein Körnchen Wahrheit steckt in diesen ganzen Schmähungen drin: OPNsense würde ich noch nicht wirklich als ausgereifte Lösung ansehen.

Könntest Du das weiter ausführen? Was fehlt denn Deiner Meinung nach, bzw. was muss noch getan werden um OPNsense in einem Produktivbetrieb einzusetzen?

Gruß

Hallo Franco,

Früher gab es ja noch solche Seitenhiebe von Jim (ein mal nach unten scrollen): https://blog.pfsense.org/?p=1773
Screenshots von OPNsense wie man es nicht machen sollte vom Juli 2015. Bootstrap 88% completed für pfSense 2.3. Na, ja, ok, ich lass das mal so stehen.

Sehr unseriös von pfSense, finde ich.

Oder aber meine liebste Email von Chris Buechler, in der er im Februar 2015 schon alles vorherahnt was an eingangs erwähnter Kampagne folgt: "OPNsense is extraordinarily shady, proceed with caution."

http://m0n0.ch/wall/list/showmsg.php?id=376/07

Ahh, ich schwelge in süßen Erinnerungen...

Würde es Dir etwas ausmachen, dazu Stellung zu nehmen und kurz Deine/ Eure Sicht der Dinge, bzw. des Verlaufs darzulegen?

Gruß
Σουπεργιούζερ

Hi Franco!

#2 was hat es mit der Ubuntu Namensmimikri auf sich?

Die Namen gibt es noch immer, aber diese sind lange nicht so präsent wie wir gedacht haben. Ob sie bleiben oder nicht werden wir sehen. Zufrieden sind wir allerdings mit der numerischen Versionierung, auch wenn wir hier noch experimentieren und machmal die Versionen zu lang werden. ;)

Ob sich das alles noch ändert bleibt offen. Wir haben jedenfalls keine Angst davor etabliertes einzureißen, gerade um Dinge einfacher oder deutlicher für unsere Nutzer zu gestalten.

Also meiner Meinung nach sind solche prosaischen Namensgebungen, wie sie leider auch z. B. Debian oder Opensuse verwenden, nachteilig und behindern mich nicht unerheblich in meiner täglichen Arbeit.

Ich benutze eine Vielzahl von Freier (oder zumindest Open Source)-Software und bin nicht automatisch in jedem dieser Projekte täglich intensiv involviert. So kommt es immer wieder vor, dass ich zu etwas recherchieren muss, aber die "locals" eines Projektes, also die stark Involvierten Projektmitglieder, sich in den Foren, Mailinglisten, etc. immer nur auf diese albernen Namen beziehen, anstatt auf die Selbsterklärenden und eindeutigen Versionsnummern.

So kommt es dann immer wieder vor, dass ich erst mal nachsehen muss ob ich jetzt eigentlich Clounesque Coyote oder doch schon Silly Snake verwende, oder mir bei Wikipedia die (hoffentlich vorhandene) Versionshistorie vorholen muss, um zu sehen ob Feature X in meinem Painintheass Penguin schon vorhanden ist, weil ich nicht auswendig weiß, wann es released wurde, und ob es jetzt vor oder doch nach Bullshit Buffalo released worden ist, weil ich die Reihenfolge dieser sinnlosen Namen nicht für jedes dieser Projekte auswendig aufsagen kann, etc. :-)

Deshalb plädiere ich dafür, ausschließlich aufsteigende Nummerierungen zu verwenden und nicht durch zweigleisige Bezeichnungspfade Verwirrung zu schaffen, zumal die zusätzliche prosaische Benennung einer Version keinerlei Mehrwert schafft. Wenn dann die Nummerierung auch noch zusätzlich Informationen beinhaltet, wie z. B. Jahr und Monat des Releases (also genau so, wie ihr es macht mit 16.1 für Januar 2016, etc.) dann finde ich es perfekt!

Sogar M$ hat irgendwann eingesehen, dass SE, ME, NT, XP und Vista als Versionsbezeichnungen ihre Kunden eher verwirren und knüpft seit 7 wieder an seine seit 3.11 schmerzlich vermisste Numerierung an, wobei ich die zwischenzeitliche Jahreszahlennummerierung von 95, 98 und 2000 aus oben erwähnten Zusatzinformationsgehalt-Nutzen besser fand.

Moment, Phalcon ist neu und genau wie Django 3.Generation um bei der Terminologie zu bleiben. Es ist unserer Meinung nach unmöglich den PHP Code komplett einzureißen und ein neues Framework mit neuer Sprache zu bauen. Das kostet Jahre. Jahre die nicht überbrückt werden können mit Zwischenlösungen. Was also mit anderen Projekten passieren könnte ist, dass eine "richtige" Version parallel ewig entwickelt wird aber niemals korrekt getestet wird, weil den Nutzern zu viele Features fehlen und dann "nebenbei" eine Legacy-Version gepflegt wird die weiterhin von allen genutzt wird. Man sieht deutlich, dass es auf 2 parallele Projekte hinausläuft. Wenn man dann noch annimmt, dass die Legacy-Version sehr viel Pflege und Modernisierung braucht könnte man zu dem Schluss kommen, dass das nur bedingt machbar ist auf die Jahre gesehen.

Wer von Euch den Projektverlauf des CMS "TYPO3" kennt, kann bestätigen, dass Du mit Deiner Einschätzung goldrichtig liegst! TYPO3 wollte sich komplett neu erfinden und ein neues Framework schaffen ("Flow") auf dem dann eine komplett neue Version ("Neos") laufen sollte. Ganze 6 Jahre (!) liefen drei Projekte gleichzeitig, das Legacy-Projekt "TYPO3 CMS" sowie die Zukunfts-Projekte zu Flow und, darauf aufbauend, Neos.

Ende der Geschichte: Flow und Neos wurden abgespalten und sind nunmehr nur noch experimentelle Projekte einer kleinen, unabhängigen und eigenständigen Gruppe, und TYPO3 CMS ist nicht mehr "legacy" sondern wieder das Hauptprodukt des TYPO3-Projekts. Der Großteil der Community ist bei TYPO3 geblieben, da keiner im Produktionbetrieb ein erprobtes, full featured und stabiles Sytem gegen ein experimentelles, funktionseingeschränktes System ersetzen konnte und wollte...
Allerdings hinkt TYPO3 durch die jahrelang eher halbherzige weiterentwicklung als "legacy version" jetzt entwicklungstechnisch anderen CMS fast ein Jahrzehnt hinterher, so dass im Grunde jetzt alles den Bach runtergegangen ist, TYPO3, Flow und Neos.

Unser zweigleisiger Plan sieht so aus:

* PHP bleibt, aber der alte statische Code wird Schritt für Schritt ins MVC migriert. Das Config-System ist schon umgeschrieben und vereint und erscheint heute mit 15.1.8. Das heißt die Basis für alte und neuen Code ist nun gegeben. Was als nächstes passiert ist eine Portierung des statischen Codes in eine modularisierte Variante. Das bringt weniger Code der gleichzeitig besser strukturiert ist und daher wird es einfacher für andere mitzuarbeiten. Das hat noch nichts mit Sicherheit zu tun, sondern ist eine vernünftige Grundlage. Ganz nebenbei ist PHP/Phalcon sehr schnell und im Vergleich mit z.b. Python/Django ähnlich schnell und umfassend: http://vschart.com/compare/django/vs/phalconphp

* Python ersetzt den alten check_reload_status Daemon, der für Hintergrundaktivität genutzt wurde. Daraus wurde kürzlich "configd", der nun weiter ausgebaut wird um mehr Systemkonfiguration zu übernehmen. Das führt Schritt für Schritt zu einer Situation in der das "schwache" PHP weniger privilegierten Code für die Systemkonfiguration ausführen muss. Der Frontend-PHP-Code bleibt aber erhalten. Wenn dies ausreichend vorangeschritten ist können wir PHP die Root-Rechte entziehen, weil es diese dann nicht mehr braucht. Sicherheitsproblem gelöst! Na, ja, zumindest eins davon. ;)

Diese Schritte ermöglichen es uns jede Woche Releases herauszubringen, die etwas besser sind als die Woche zuvor und gegen Ende des Jahres haben wir dann den Löwenanteil erreicht, vielleicht sogar eine REST API und weitere Security-relevante Dinge wie LibreSSL oder aber ein neues modularisiertes Package-System als Nebenprodukte eingearbeitet.

Das klingt vernünftig! Revolution klingt zwar immer sexyer, als Evolution, aber wie oben am Beispel TYPO3 gezeigt, krepieren solche Revolutionsansätze meist und führen nur zu Frust und Problemen.

Viel Erfolg
Σουπεργιούζερ