USG error meldingen (OPGELOST)

[As4Tech]

Wanneer ik VLAN300 aanpas (zowel nieuwe als classic GUI) komt de wijziging niet door in de USG (moet handmatig op 192.168.1.1 worden gedaan)

Ik ben op zoek naar de server.log, maar aangezien ik de controller als add-on op Home Assistant heb, kan ik ze (nog) niet vinden. (heb ik ander draadje hulp gevraagd)
Ik heb een keer gezien dat de firewall Active was. Weet niet wat er gebeurt is (waarschijnlijk een wijziging) maar nu is en blijft de firewall INACTIVE.
(zodra ik logging heb kom ik hier weer terug)

 

[Hofstede]

Ik begin er aan te denken dat er in je controller configuratie database iets verminkt is geraakt. Mogelijk moet je je controller eens volledig resetten en je configuratie opnieuw opzetten. Of probeer tijdelijk een kleine opzet met een nieuwe schone controller en je USG. Als dat werkt weet je of het probleem ergens in je huidige database configuratie zit.

Ik snap niet waarom je geen server.log file hebt, die maakt de controller altijd aan. Misschien moet je de computer waarop de controller draait doorzoeken op de server.log file.

 

[As4Tech]

Hi (en dank voor het geduld)
Ik heb ontdekt dat ik in HA een logger moet aanzetten. Alles wordt weliswaar in één grote logfile geschreven, maar ik denk dat ik betreffende regels gevonden in de log ten tijd van het toevoegen van een test rule. De betreffende regels heb ik een apart bestandje toegevoegd.

Hierin denk ik ook terug te zien dat de WAN config geen IP nummer krijg (0.0.0.0) omdat het VLAN niet op 300 wordt gezet.
Ik heb vorige week de controller gemigreerd van raspberri naar een andere hosts met HA. Eén van de eerste stappen is export bestand importeren n de nieuwe controller. Ik heb de migratie juist uitgevoerd omdat ik hoopte op deze manier de issues kwijt te raken.

Als niemand iets verdachts zit in de debuglog, dan is het waarschijnlijk een goed idee om de hele config opnieuw op te bouwen van scratch (om eventuele DB corruptie te voorkomen)

 

[Hofstede]

Heb je inmiddels de classic (legacy) interface al teruggevonden?

Iets wat je zou kunnen testen:
- Haal (in de classic interface) de VLAN ID van je WAN. Ik weet dat je dan geen internet hebt, maar dan kun je testen of het provisionen wel weer werkt en of de firewall op WAN IN weer actief wordt.
- Het (tijdelijk) verwijderen van alle aanpassingen aan de firewall. Dus ook port forwards die je hebt aangemaakt.


De logging die je laat zien is niet iets dat ik herken. Waarschijnlijk probeert die HA add-on de logging van de controller in zijn eigen logging te integreren o.i.d.
Het zou helpen als je een "normale" controller installatie zou hebben waarbij je gewoon een server.log file hebt die precies laat zien wat er fout gaat bij het provisionen.

 

[Wimpie]

debuglog

@As4Tech Ik dacht een ip-adres van t-mobile gezien te hebben. Misschien goed om je debug bestand nog even na te kijken en een en ander te verwijderen. Op deze wijze maak je het potentiële hackers wel erg gemakkelijk

 

[As4Tech]

De HA plugin is mooi, echter wanneer er issues zijn is debugging een "ding".
Ik probeer nu eerst zsm de controller weer op de pi3b+ te zetten. En om dan hier terug. Voor nu super bedankt.
(Op de pi heb ik eerst andere issues te overwinnen; to be 64b or not)

 

[As4Tech]

Hallo,
Het issue lijkt opgelost te zijn door een volledig nieuwe installatie uit te voeren.
Nu is de WAN_IN firewall rule ACTIVE
Ter controle: nmap vanuit een cloud machine:

[opc@instance-20220328-1755 ~]$ nmap xx.xx.xx.xx
Starting Nmap 7.70 ( https://nmap.org ) at 2022-04-04 17:25 GMT
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds

Hiermee is ook het issue opgelost dat ik steeds met de hand de VLAN moest instellen op de USG.

dank allen voor het geduld.