Messages

166

17.1 Legacy Series / kernel error message ifa_maintain_loopback_route: insertion failed for interface

« on: June 07, 2017, 01:37:02 pm »

Hello together,

after upgrade to 17.1.8 for what reasons ever, one of my interface is not accepting to get configured with a linkloca address:

Code: [Select]

OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/ifconfig igb3 inet6 fe80::1:1%igb3' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): File exists'
I have then the  following error messages in routing.log:

Code: [Select]

Jun  7 20:28:26 OPNsense radvd[54605]: received icmpv6 RA packet with non-linklocal source address from 2003:46:e954:26f2:XXX:XXXX:XXXX:XXXX
Jun  7 20:28:26 OPNsense rtsold[88234]: <rtsol_input> invalid RA with non link-local source from 2003:46:e954:26f2:XXX:XXXX:XXXX:XXXX on igb3

and in dmesg

Code: [Select]

ifa_maintain_loopback_route: insertion failed for interface igb3: 17

igb3 is one of my internal networks .... Mr. google is not really enlighting .....

What is the corrective measure to get rid of these messages? RA on all other internal interfaces works and they also get an link local address 

Thanks ...

br br

167

17.1 Legacy Series / Re: IGMP-Proxy stops stream after 2 minutes

« on: June 05, 2017, 02:06:56 pm »

Hi dasmaeh,

this topic has been discussed already in several topics,
e.g. https://forum.opnsense.org/index.php?topic=4828.msg19080#msg19080

Still not functional also in my installation ....

Br br

168

17.1 Legacy Series / Re: WAN with too many In/Out errors reason?

« on: June 01, 2017, 12:40:29 pm »

Hi hirschferkel,

Suggestion: Check with an appropriate tool how many WiFis are around and on which channel. How many try to send on the same channel as yours resp. sending on the channel where your station is receiving. This gives you an indication how noisy is your environment. In addition to the suggestions of Franco, you can then with many wifi stations configure/adapt the channel hopping sequence or switch to 5G only or ..... You could the also detect any kind of unauthorized sender compromising your RF signal if so.

 If e.g.. you are using a 5G frequency band,  another reason could be that signal strength may be too low as this frequency is much more blocked by walls etc. you could then try to configure 2.4 band only

Wifi has as most other RF working according to standards reserved frequencies so there is no interference with other technologies like phones etc.

Br br

169

17.1 Legacy Series / Re: [SOLVED] [17.1.5] Still no working IPv6 on LAN

« on: May 20, 2017, 10:40:27 am »

Well,

there is another ipv6 configuration option on the fritzbox under

Internet->Zugangsdaten->ipv6

There you can configure which prefix length the fritzbox shall request

Default is /62

In my case I changed that to /60 and .... voila

br br

170

German - Deutsch / Re: [GELÖST] IPSec Bugs

« on: May 18, 2017, 10:43:31 pm »

Hi Franco,

Dein Post beschreibt sicherlich einen validen Konflikt, den ich wie folgt adressieren würde:

Im Linuxlager gibt es für alle Deine drei zitierten Szenarien Distributionsbeispiele (Debian, Ubuntu, Redhat etc.) Und alle drei haben für verschiedene Anwendungsfälle ihre Stärken und natürlich auch Schwächen. FreeBSD ist ebenfalls ein General Purpose OS. So gesehen ist Opnsense ein sehr spitzes Applikationsgeschehen mit einer klar definierten aber eher schmalen Bandbreite an benötigten Funktionen des OS. Würde ich zB eine Firewallappliance auf Linux aufsetzen würde ich eher Debian wählen (seehhr alter (aber gewarteter Kernel)  und weniger die neueste Ubuntu Release 17.04; genauso würde ich auch HW seitig nicht den letzten Schrei einsetzen (damit bin ich ja nun gerade selbst recht nett vor die Pumpe gelaufen, siehe https://forum.opnsense.org/index.php?topic=5063.0 und https://forum.opnsense.org/index.php?topic=4637.0)

Daher frage ich mich, was die WIRKLICH JETZT benötigten neuen Features von 11.0 sind die den Wechsel treiben. Nach meinem Verständnis könnten dies doch nur neuere NIC Treiber sein, ggf auch Updates im IP(v6) Stack oder neue Versionen bei IDS oä; PHP7 und andere Dinge gibts als Updates für 10.3 auch. War das Delta wirklich so groß (zB auch wenn man an die Realtek Treiber issues denkt etc.)? Aus meiner Sicht eher nicht.

Zwei Ansätze könnten hier vielleicht hilfreich sein

1.) Man könnte  zB einen Wechsel des Unterbaus nicht gemeinsam mit einem Major Release durchführen sondern eher mittendrin, in der ersten Hälfte fokussiert man auf neue Features, in der zweiten Hälfte auf neuen Unterbau. Dann kann man die Zeitleiste mit der Freebsd Releaseroadmap syncen, die ja mW auch etwa im Jahrerythmus tickt

2.) Man pflegt eine stable Release auf einer älteren Unterbau Version mit minimalen Backports für die Produktion und fokussiert sich auf Bugfixes und die Integration von Sicherheitsupdates; Man hat eine progressive innovative Release und setzt diese erst später nach einer ausgiebigen Testphase und Stabilisierungsphase für produktive Zwecke ein. Mit der Übergabe in die Produktive Phase managed man die alte ab und stellt die Pflege ein, um den Aufwand zu minimieren. So hat man max. 2 Versionen 'in Arbeit'. Der Vorschlag wurde ähnlich auch schon gemacht ...

Für Modell 2 müssten wir sicherlich mehr aktive Mitarbeiter in der Community gewinnen. In jedem Fall brauchts die von Dir richtigerweise erwähnte professionelle Entwicklungsumgebung

Ich glaube im Grundsatz, dass eine stabile, sichere, produktiv eingesetzte und gepflegte Version dem Projekt mehr Reputation verschafft und vielleicht mehr Contributions von Firmen/Organisation/Personen triggern könnte, die diese einsetzen. In Summe könnte dies die Sache schneller voranbringen.

Br br

171

German - Deutsch / Re: [GELÖST] IPSec Bugs

« on: May 15, 2017, 09:08:47 pm »

Hallo zusammen,

die Diskussion ist sehr spannend und vieles was hier aufgeführt worden ist sicherlich auch nachvollziehbar und richtig. Dennoch glaube ich, dass es erforderlich ist, einige der Aspekte nochmals aus einer anderen Perspektive zu beleuchten.

Zunächst: was hier bei Opnsense geleistet wird ist in jeder Hinsicht hochgradig anerkennenswert und vor allem dem unermüdlichen Einsatz von nur wenigen aktiven Streitern zu verdanken, die neben der Entwicklung und Pflege der Plattform auch noch die gesamte Bedienung der Kommunikation stemmen. Der Output ist extrem effektiv und kompetent, dafür Chapeau und Gratulation. Auch ich werde im Rahmen meiner Möglichkeiten (die iW Test und Kommunikation von Findings bedeuten (bin leider kein php Experte  )) nach Kräften weiterhin dazu beitragen!

Aus meiner Sicht muss man die Thematik abschichten: Zunächst mal die technische Sicht/die Erwartung:

Opnsense muss den Anspruch haben, produktiv einsetzbar zu sein. Diese Erwartung weckt das Projekt auf seinem Webauftritt und kommerzielle Angebote (Appliances, Service, ...) rund um Opnsense befeuern genau diese Erwartung. Produktiv meint hier, einmal konfiguriert sehen viele in Routern/FW ein 'eh da' System, was über Wochen und Monate einfach funktioniert und ohne signifikante Serviceunterbrechung gewartet werden kann. Schade finde ich, dass in der Diskussion der Eindruck entstehen könnte, dass man so etwas von einer Opensource Lösung, die durch eine Community getrieben wird, nicht realistisch erwarten darf. Diese Sicht teile ich nicht und es gibt genügend Beispiele, dass das nicht so ist. Opnsense hat bislang jedenfalls auch diese Erwartung hervorragend bedient.

Ein Router/eine Firewall hat aus meiner Sicht besondere Anforderungen an Stabilität und Sicherheit und unterscheidet sich dadurch auch von anderen Softwareprojekten. Das ist unabhängig von 'Opensource' oder 'Kommerziell' und gilt auch für Opnsense. Design und Roadmapentscheidungen müssen sich aus meiner Sicht zuallererst an diesen beiden Kriterien orientieren; neue Features müssen zur Not dann auch hinten anstehen. Ob Opensource oder Kommerziell, Ziel eines jeden SW Projekts sollte es sein, alles dafür zu tun, SW in hoher Qualität zu realisieren und möglichst fehlerfreien Code zu bauen (auch wenn es das absolut nicht gibt). Dieses Paradigma gilt für alle an der Bereitstellung der Lösung beteiligten Komponenten, also 'Unterbau' und 'Plattform', nur so kann das Gesamtergebnis stimmen. Eine Position 'für Fehler im Unterbau können wir nichts, das ist FreeBSD Sache' hilft da nicht, wenn es das eigene Ergebnis kompromittiert.

Technisch betrachtet gibt es ja bei FreeBSD die Möglichkeit, Releases zu verwenden, die mehrere Jahre gepflegt werden (selbst 10.3 RELEASE wird nach meinem Verständnis bis MINDESTENS Ende April 2018 mit Updates versorgt, wahrscheinlich sogar noch länger) und damit eine höhere Reife aufweisen sollten (das stimmt zwar nicht in allen Details, aber in vielen Bereichen). Den Tradeoff zu managen, wann man auf eine neue 'Unterbau'-Version wechselt und wann man neue 'Features' einbaut ist schwierig und ein ständiger Balanceakt.

Mit Release 17.1 hat Opnsense eine Vielzahl von Neuerungen gebracht, die über die letzten Releases von 16.7 und 17.1-BETAs vorbereitet wurden (Suricata, Sprachen, UI, ....). Gleichzeitig wurde aber auch der 'Unterbau' auf FreeBSD 11.0 upgedated, mit einer Reihe von unschönen Seiteneffekten wie Consoletreiber, Installations- und Updatethemen sowie unterschiedlichem Verhalten auf verschiedener HW usw. Gefühlt ist im Ergebnis in der Tat der Eindruck entstanden, daß das Major Release Upgrade auf 17.1 nicht so geschmeidig verläuft wie man es von vorherigen Releases kannte (ich selbst arbeite seit 15.1 auf 15.7 mit Opnsense). 17.1 stürzt im Betrieb bei mir häufiger ab als die Releases vorher. Das ist mein persönlicher Erfahrungswert, andere mögen da andere Erfahrungen haben. Ich frage mich, was kann ich beitragen, um den Zustand zu verbessern.

Das bringt mich dann zum zweiten Punkt: Was kann die Opnsense Community in ihrer heutigen Form denn realistisch leisten? War es vielleicht 'zuviel auf einmal' mit 17.1 auch den Unterbau zu wechseln? Fakt ist: Sichtbar contributen nicht vielmehr als eine Handvoll Leute regelmäßig zum Opnsense Code, unterstützt von einigen, die qualifiziert Fehler zurückmelden; fixen tun es dann aber wieder die gleichen Leute. Es ist aus meiner Sicht ein riesen Stretch, ein Projekt mit der Komplexität mit so wenigen zu stemmen und gleichzeitig auch noch zu versuchen den Link zur FreeBSD Community zu bilden und ganz viele HW Varianten zu unterstützen, Treiber, etc.. Ich halte es für schlicht unrealistisch in dem Setup die og Erwartung zu bedienen. Die Aktiven sind dadurch gezwungen, Kompromisse einzugehen und 'mutige' Entscheidungen zu treffen, um das Projekt nach vorne zu bringen. Das geht häufig gut, manchmal eben auch nicht.

Sprüche wie 'ich habe jetzt aber mal das Vertrauen verloren' bringen in der aktuellen Situation in der Sache gar nichts! Stattdessen würde ich mir wünschen, dass alle, die Erwartungen vor sich her tragen, darüber nachdenken wie sie denn AKTIV helfen können, das Projekt zu unterstützen und nicht einfach auf 'die Entwickler' - also 'Andere' aber nicht 'ich' verweisen. Ich bin fest davon überzeugt, dass Opnsense dies wert ist !!! 

Vielleicht schaffen wir es ja alle zusammen, in ein Setup zu kommen, in dem eine stabile produktive Release auf vielleicht nicht der allerletzten Leading Edge Release stabil gepflegt werden kann und sich an den Releasezyklen von FreeBSD orientiert und sich eine zweite Release überlappend dazu mit den neuesten Features beschäftigt und leading edge Unterbau beschäftigt. Und vielleicht schaffen wir es ja sogar dann auch noch, dass sich eine weitere Gruppe mit Backports von Core Essentials beschäftigt, die einfach großes Interesse in produktiven Umgebungen geschaffen haben, bevor die Leading Edge Release produktionsreif ist.

Das erfordert aber einfach, dass mehr Leute aktiv mitmachen - anders wird es nicht funktionieren. Und es wäre schön, wenn möglichst viele dies als Appell auffassen würden, mitzumachen und einen Beitrag zu leisten.

In diesem Sinne

Br br

172

17.1 Legacy Series / Re: Help with IPv6

« on: May 02, 2017, 12:57:58 pm »

Oh ..yesl - the fibre box needs to connect to your ISP provider - its then indeed a (fibre) cable modem 

173

17.1 Legacy Series / Re: Help with IPv6

« on: May 02, 2017, 10:18:40 am »

I would simply try to copy your radvd.conf and your dhcp6c_wan.conf to a backup and empty the file and then reconfigure WAN interface and LAN interfaces again.

don't forget to save and then confirm the settings (this are 2 steps), WAN first and then the LANs. Check the config files afterwards again.

Then reboot.

If then again you don't have a prefix, then I would assume that your ISP is not sending one (or your modem config prevents ...)

Br br

174

17.1 Legacy Series / Re: Help with IPv6

« on: May 01, 2017, 08:21:36 pm »

Yes, this is what I meant - however, for what reasons ever, this setting did not find its way into your ipv6 config (radvd.conf).

Can you somehow check whether your ISP is really sending you a prefix or an IPv6 address only?

And still - your configuration contains values which are only accessible when using extended config options.

The line

Code: [Select]

id-assoc na 0 { };

indicates that you have used extended config options for your WAN interface (having ticked non temporary address assignment). You should consequently use Basic!

Perhaps it is best to start the entire ipv6 config once again from scratch

Br br

175

17.1 Legacy Series / Re: Help with IPv6

« on: May 01, 2017, 01:37:01 pm »

Hello,

sorry for the late reply, was off yesterday.

Your radvd.conf file is incomplete. if you use SLACC /what you obviously have configured on your WAN interface, the individual lines in your radvd.conf must contain

Code: [Select]

interface em0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvLinkMTU 1500;
AdvOtherConfigFlag on;
prefix 200X:XXXX:XXXX:XXXX::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
DNSSL star-one.co.uk { };
};

while yours only contain

Code: [Select]

interface em0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvLinkMTU 1500;
AdvOtherConfigFlag on;
prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
DNSSL star-one.co.uk { };
};
i.e. your prefix is empty.

Moreover you seem not to have set a domain name in your general config.

So, either the /56 prefix which your ISP sends is not recognized or it even does not send one but only an address.

Br br

176

17.1 Legacy Series / Re: Systems suddenly HALTS - Stability issue since 17.1

« on: April 29, 2017, 10:24:01 am »

Hello together,

after a long night of testing, chats and communications, there is some progress.... The error could be provoked/reproduced.

I am much probably affected from this: https://forum.pfsense.org/index.php?topic=98230.0  . Motherboard hardware replacement with new Supermicro HW revision is getting ordered.

Will give an update when I have it and made the necessary stability verification....

Br br

177

17.1 Legacy Series / Re: Help with IPv6

« on: April 28, 2017, 05:00:55 pm »

And how do your /var/etc/dhcp6c_wan.conf and your /var/etc/radvd.conf look like?

178

17.1 Legacy Series / Re: Systems suddenly HALTS - Stability issue since 17.1

« on: April 28, 2017, 04:56:49 pm »

Hello,

no first time I could get an output on the console when my WAN interface went down suddenly. (See attachment). is there something how I could perhaps fine tune some parameters in configs to at least degrade the impact if not possible to solve it?

Br br

179

17.1 Legacy Series / Re: Help with IPv6

« on: April 28, 2017, 04:39:34 pm »

Can you please check whether your rtsold and radvd agents are running?

180

17.1 Legacy Series / Re: Help with IPv6

« on: April 28, 2017, 03:31:47 pm »

@djGrrr - same opinion ... according to my understanding finding lines like

Code: [Select]

(...)
Apr 27 12:17:45 bart dhcp6c[34719]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Apr 27 12:17:45 bart dhcp6c[34719]: failed initialize control message authentication
Apr 27 12:17:45 bart dhcp6c[34719]: skip opening control port
(...)
in the log indicate advanced mode - never have had those in basic mode ... Then the WAN configuration fail ...

@Taomyn How do you get step 2 of your bullet list done if not via rtsold/radvd then? Indeed, the address is build from the prefix obtained on WAN and the derived address part which is usually defined related to the Mac address (SLACC). Or do you config that manually/set up radvd.conf manually

Br br