Messages

1

21.7 Legacy Series / Re: OpenSSH does not start after updatding to 21.7.5

« on: December 15, 2021, 11:53:17 am »

Hi Franco,

thank you for the suggestion. I'm not aware to have changed something to override defaults (in this area), but at the same time, being pretty new to firewalls and especially opnsense, I have been doing guesswork to get things working the way I want.

Anyway, after some searching I've found System -> Settings -> Administration -> Key Exchange Algorithms which was configured to accept the entire list, except for the last entry.
After disabling all methods with "SHA1" in their names and saving, OpenSSH managed to start up again.

Note that disabling everything with SHA1 in their names is again a wild guess based on the fact that SHA1 isn't considered the most secure algorithm any more. It could be OK in combination with other things though. Sometimes wild guesses work :-)

Thank you again for the valuable hint!

Best regards,

Ronald

2

21.7 Legacy Series / Re: OpenSSH does not start after updatding to 21.7.5

« on: December 14, 2021, 02:49:51 pm »

Hi Bongo,

I've seen the same issue in my installation and an upgrade to 21.7.6 didn't help.
It shows the following entry in the general log file:

Code: [Select]

/usr/local/etc/rc.sshd: The command '/usr/bin/protect -i /usr/local/sbin/sshd' returned exit code '255', the output was 'Unsupported KEX algorithm "sntrup4591761x25519-sha512@tinyssh.org" /usr/local/etc/ssh/sshd_config line 14: Bad SSH2 KexAlgorithms 'diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,curve25519-sha256,curve25519-sha256@libssh.org,sntrup4591761x25519-sha512@tinyssh.org'.
Now to at least answer one of your questions:
As long as you don't want to log in into your firewall over a network, you won't even notice that openssh isn't running.
Most of the time I think that the web gui is pretty convenient and there's hardly need to start a remote (secure) shell. But still, I'd prefer to have openssh running.

3

General Discussion / Re: New user for SSH access

« on: January 11, 2021, 03:03:11 pm »

I'd say that not requesting a password might be convenient, but certainly not safe.
In fact, the way I read it, sudo was more complaining about the fact that the user gongo isn't allowed to use sudo.
In the sudoers file (usually /etc/sudoers, at least on linux systems) you can define which users are allowed to use sudo in the first place, and furthermore if they are allowed to acquire superuser privileges.

As an example (since I don't have a sudoers file on my opnsense box),an excerpt of the contents of my ubuntu sudoers file:

Code: [Select]

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

This basically means that any user of the sudo and admin group can gain root privileges.

So you might have to add your user gongo to the admin group.

HTH

Ronald

4

General Discussion / different routing for TCP/UDP and ICMP

« on: January 11, 2021, 12:48:07 pm »

Hi All,

I'm encountering the following behaviour which I fail to understand:

Code: [Select]

root@FW2:~ # traceroute -I fw3
traceroute to fw3.independit.de (192.168.36.60), 64 hops max, 48 byte packets
 1  dns2 (192.168.16.3)  0.362 ms  0.268 ms  0.243 ms
 2  fw3 (192.168.36.60)  2.574 ms  2.522 ms  2.278 ms
root@FW2:~ # traceroute fw3
traceroute to fw3.independit.de (192.168.36.60), 64 hops max, 40 byte packets
 1  fw1 (192.168.16.60)  0.384 ms  0.284 ms  0.250 ms
 2  zyxel (192.168.2.1)  0.895 ms  0.728 ms  0.744 ms
 3  62.156.244.22 (62.156.244.22)  12.491 ms  12.249 ms  12.061 ms
^C
root@FW2:~ # traceroute -P TCP fw3
traceroute to fw3.independit.de (192.168.36.60), 64 hops max, 40 byte packets
 1  fw1 (192.168.16.60)  0.393 ms  0.262 ms  0.261 ms
 2  zyxel (192.168.2.1)  0.826 ms  0.815 ms  0.789 ms
 3  62.156.244.22 (62.156.244.22)  12.015 ms  12.158 ms  11.605 ms
^C

IOW, if I traceroute from FW2 to FW3 using the standard UDP or TCP, the packages are sent to the default GW, if I use ICMP the packages are (correctly) sent to the staitcally configured GW.

The routing table of FW2 looks like:

Code: [Select]

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.16.60      UGS        igb0
127.0.0.1          link#6             UH          lo0
192.168.2.0/24     192.168.16.60      UGS        igb0
192.168.9.0/24     192.168.16.60      UGS        igb0
192.168.16.0/24    link#1             U          igb0
192.168.16.38      link#1             UHS         lo0
192.168.25.0/24    link#2             U          igb1
192.168.25.60      link#2             UHS         lo0
192.168.36.0/24    192.168.16.3       UGS        igb0
192.168.49.0/24    192.168.16.3       UGS        igb0

If I try to reach FW3 from behind FW2 (i.e. from the 192.168.25.0/24 network), this works without issues.

I used to have the problem that I couldn't even ping from FW2 to FW3, but was able to "repair" this by adding a firewall rule.
Adding the same firewall rule for UDP instead of ICMP didn't change the behaviour shown above though.

The mistake is probably sitting in front of the computer, but still, I don't understand a bit of this.
I also don't understand the concept that firewall rules influence routing.

In my naive understanding, a firewall is a kind of custom office that checks the documents of the packet that wants to pass the border (and maybe also checks the luggage space). The routing table is like a bunch of road signs telling the packet what path to follow in order to reach its destination.
But obviously this is an incorrect understanding.

I already had defined very loose rules that permit all traffic from the 192.168.25.0/24 network to the outside.
But first after adding the redundant more specific rule for ICMP, the "ping" and "traceroute -I" selected the correct route.

Oh, and for the record, FW2 has installed:
OPNsense 20.7.7_1-amd64
FreeBSD 12.1-RELEASE-p11-HBSD
OpenSSL 1.1.1i 8 Dec 2020

If more information is required, please tell me.

Could anyone please try to explain me why my understanding of this is so horribly wrong?
And why UDP or TCP packets are forced to take a different route than ICMP packets (if sent from FW2) ?

Thanks in advance!

Ronald

5

German - Deutsch / Re: OPenSense Einrichtung und Netzwerkhilfe

« on: January 07, 2021, 05:36:36 pm »

An Sich einverstanden, aber da ich ein einzelnes Netzwerk in vier kleineren Netzwerke zerlegt habe, wollte ich mich zuerst um das Routing kümmern.

Beim Aufsetzen der Firewalls ist dann Dein Ansatz natürlich genau richtig. Erstmal nichts durchlassen, und dann eine Service nach der anderen freigeben.

Wenn man aber die Reihenfolge umdreht, und irgendwas funktioniert nicht (was garantiert der Fall ist), ist es erstmal unklar wo der Fehler liegt.

Da mein Netzwerk ursprünglich nur dur NAT "geschützt" war, konnte es nicht schlimmer werden. Sich zuerst ums Routing zu kümmern, mach es nicht schlimmer. Und dabei darf man nicht vergessen, dass ich auf dem Gebiet (wie der OP) kein Profi bin. Die konfigurieren das Routing (in meinem Netzwerk) vermutlich auch noch problemlos nach 8 Maß Bier; ich habe aber auch nach 8 Espresso meine Schwierigkeiten.

6

German - Deutsch / Re: OPenSense Einrichtung und Netzwerkhilfe

« on: January 07, 2021, 04:51:38 pm »

Hallo,

in einer ähnlichen Situation war ich von einigen Monaten auch.
Gut, ich bilde mir ein etwas Ahnung von Networking zu haben und habe demnach beschlossen es erstmal selbst zu versuchen.
(Das mit der "Ahnung" wird immer mal wieder "disproved", aber ich mache Fortschritte).

Der Schlüssel zum Glück ist eine Planung im Vorfeld.
Was möchtest Du schützen, was soll weiterhin möglich sein?

In meinem Fall war das komplex. Zum einen wollte ich das Büronetzwerk vom WLAN trennen (WLAN ist so sicher wie ein vergammelter Holztür). Zum anderen wollte ich einen VPN Zugang ermöglichen. Und aus ästetischen Gründen war ein Ethernetkabel mitten durchs Wohnzimmer nicht akzeptabel. Mein Internetprovider ist eher ein Vielleicht-Internet-Provider.

Letztendlich bin ich nach der Planung mit einem Setup mit 3 Firewalls und ein Router rausgekommen.
(2 Firewalls hinter den (nun) zwei Internetzugängen (davon einer mit feste IP wg. VPN). Eine Firewall vor dem Büronetzwerk.
Der Router verbindet verkabeltes Netzwerk mit dem WLAN, was privat genutzt wird).

Dann habe ich mir ein Buch über OPNSense gekauft (und gelesen), um den ersten Zugang zum System zu bekommen.
Auch wenn das Buch letztendlich nicht genial ist, bietet es dennoch eine gute Einführung und sorgt dafür, dass nachher die Online Doku sowie auch viele Posts hier einen Sinn ergeben. (Der OPNsense Praktiker).

Beim Aufsetzen habe ich dann erstmal die Firewall ausgeschaltet und habe mich ums prinzipielle Routing sowie das Aufsetzen von VPN gekümmert (schlimmer konnte die Unsicherheit des Netzwerks nicht werden, also in der Entstehungsphase akzeptabel).
Anschliessend habe ich dann die Firewalls (eine nach der andere) scharf geschaltet und dafür gesorgt, dass alles so funktioniert wie ich möchte.

Der letzte Schritt ist dann ein never ending story: Schauen, was durch kommt und eventuell blockieren.
Ich habe feststellen müssen, dass es einige Quasselstrippen in meinem Netzwerk gibt. Die reden jetzt gegen die Wand :-)

Ich hoffe, dass dies Dich motiviert. Aber auch wenn Du jemanden engagierst, wirst Du ihm erzählen müssen, was Du eigentlich erreichen möchtest. Demnach ist zumindest der Schritt absolut notwendig.

Ronald

7

German - Deutsch / static routes ignoriert?

« on: January 07, 2021, 04:05:43 pm »

Hallo Alle,

ich habe da ein Verhalten, was ich mir nicht erklären kann.
Es geht um folgendes Netzwerk (nun ja, ein Ausschnitt):


FW3 -- dns2 -+- FW2
             |
            FW1

FW1 (192.168.16.60) ist default GW für FW2 (192.168.16.38).
dns2 (192.168.16.3 sowie 192.168.36.105) ist ein einfacher router.

Wenn ich nun einen Ping von FW2 an FW3 schicke, geht der ins Leere, denn FW2 hat nichts besseres zu tun, diesen an FW1 zu schicken.
Allerdings hat FW2 folgender Routing Table

Code: [Select]

root@FW2:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.16.60      UGS        igb0
127.0.0.1          link#6             UH          lo0
192.168.2.0/24     192.168.16.60      UGS        igb0
192.168.9.0/24     192.168.16.60      UGS        igb0
192.168.16.0/24    link#1             U          igb0
192.168.16.38      link#1             UHS         lo0
192.168.25.0/24    link#2             U          igb1
192.168.25.60      link#2             UHS         lo0
192.168.36.0/24    192.168.16.3       UGS        igb0
192.168.49.0/24    192.168.16.3       UGS        igb0

Also, nach meinem Verständnis zumindest, sollte FW2 die Ping Pakete an dns2 (192.168.16.3) schicken.
Das macht er aber nicht. Ein traceroute zeigt dies:

Code: [Select]

root@FW2:~ # traceroute fw3
traceroute to fw3.independit.de (192.168.36.60), 64 hops max, 40 byte packets
 1  fw1 (192.168.16.60)  0.318 ms  0.257 ms  0.248 ms
 2  zyxel (192.168.2.1)  0.802 ms  0.789 ms  0.755 ms
 3  62.156.244.22 (62.156.244.22)  12.117 ms  11.909 ms  12.073 ms
^C

Welcher Denkfehler mache ich? Bzw. warum wird trotz Vorhandensein eines expliziten Routes die Default GW benutzt?

Lustigerweise ist fw3 von den Rechnern hinter FW2 problemlos errichbar, und der ping wird auch korrekterweise an dns2 weitergeleitet, nicht an die default GW.

-------------------------------------------------------------------------------

In der Zwischenzeit bin ich etwas weiter gekommen.
Irgendwo  im (Englischen Teil vom) Forum gab es einen vagen Hinweis auf benötigten Firewallregeln die das entfernte Netzwerk (in meinem Fall 192.168.36.0/24) ansprechen.

Also habe ich eine solche Regel zugefügt. Dabei ist die Position der Regel auch noch wichtig, wie es scheint.
(Siehe Screenshot im Anhang)

Und siehe da: der ping hat erfolg:

Code: [Select]

root@FW2:~ # ping -m 1 fw3
PING fw3.independit.de (192.168.36.60): 56 data bytes
92 bytes from 192.168.16.3: Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 fabe   0 0000  01  01 0938 192.168.16.38  192.168.36.60

^C
--- fw3.independit.de ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
root@FW2:~ # ping -m 2 fw3
PING fw3.independit.de (192.168.36.60): 56 data bytes
64 bytes from 192.168.36.60: icmp_seq=0 ttl=63 time=2.954 ms
^C
--- fw3.independit.de ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.954/2.954/2.954/0.000 ms

Allerdings benimmt traceroute sich nach wie vor daneben:

Code: [Select]

root@FW2:~ # traceroute fw3
traceroute to fw3.independit.de (192.168.36.60), 64 hops max, 40 byte packets
 1  fw1 (192.168.16.60)  0.382 ms  0.255 ms  0.262 ms
 2  zyxel (192.168.2.1)  0.847 ms  0.721 ms  0.709 ms
 3  62.156.244.22 (62.156.244.22)  11.649 ms  11.674 ms  12.253 ms
^C

Diese Interferenz zwischen Firewall-Regeln und Routing ist für mich höchst unerklärlich.
Vielleich kan mir jemand zumindest das erklären?

Ronald

8

Dutch - Nederlands / Re: [RESOLVED] ping lukt, ping lukt niet

« on: June 11, 2020, 03:23:49 pm »

Hallo Miruoy,

met een WLAN-Ethernet Bridge bedoel ik een component dat zich als client in het WLAN inboekt en dan de traffic van en naar het ethernet omzet. Uiteindelijk doet een WLAN signaal het niet zo goed op een ethernet kabel, en een ethernet signaal werkt niet zo goed in het WLAN. Dus heb ik een bridge nodig.

Nou heb ik gisteren een Fritz!Repeater 1200 gekocht en het lijkt er sterk op dat het werkt.
Ik heb nog steeds af en toe korte onderbrekingen. Maar die komen slechts sporadisch voor en duren maar 10-20 seconden. Daarmee kan ik leven.

Om mijn madam content te stellen moet ik er voor zorgen dat er geen kabels door de woonkamer lopen. Ik heb daar ook wel begrip voor. Maar het betekent wel, dat ik een stukje communicatie in het netwerk door de lucht moet doen (WLAN dus).

Net zo min als dat ik een fan van WLAN ben, ben ik een fan van powerline. In beide gevallen kan de buurman mij afluisteren (en misschien zelfs meepraten) zonder dat ik het merk. Dat is bij het gebruik van Cat6 kabels minder gemakkelijk het geval (ik heb niet de illusie dat ik de NSA kan uitsluiten).

UPDATE:
Na een tijdje bleek dat ook die FritzRepeater niet stabiel functioneert.
Een Raspberry Pi 4 doet nu, sinds enige maanden, alles wat ik wil.

Groet,

Ronald

9

Dutch - Nederlands / [RESOLVED] Re: ping lukt, ping lukt niet

« on: June 10, 2020, 10:34:43 am »

De oorzaak is gevonden.

Tussen de firewall en de gateway naar het Internet stond een Access Point Client die een bridge tussen WLAN en Ethernet vormde. En blijkbaar is dat ding niet zo compatibel als je zou verwachten.

Nadat ik een kabel door de woonkamer heb gelegd funktioneert alles probleemloos.
Nou moet ik dus op zoek naar een WLAN-Ethernet Bridge die functioneert. (Als ik de kabel laat liggen ben ik bang dat ik niet veel ouder word; mijn vrouw is not amused).

Mocht er iemand toevallig een tip of goede ervaringen met een dergelijke bridge hebben dan zou ik mij daar zeer over verheugen.

Ronald

10

Dutch - Nederlands / [RESOLVED] ping lukt, ping lukt niet

« on: June 04, 2020, 04:46:17 pm »

Hallo iedereen,

ik ben net nieuw op dit forum en ik ben ook maar pas bezig met het verwerkelijken van een beveiligingskonzept in mijn bedrijfje.

In de oorspronkelijke situatie hingen alle computers in hetzelfde netwerk, wat ook een WLAN toegang bood. Dat vond ik geen aangename situatie aangezien WLAN beveiliging niet erg goed is en er bovendien nog apparaten als televisie en BD players in het netwerk hangen.

In de eerste stap op weg naar een veiligere situatie heb ik het netwerk in twee netwerken verdeeld:
192.168.25.0/24 en 192.168.36.0/24. Daartussen staat een OPNsense installatie die in de eerste instantie alleen maar router tussen de beide netwerken hoeft te zijn.

En na veel geknutsel werkt het dan ook, ... soms.

Ik kan van het ene netwerk naar het andere een ping sturen, en ook weer terug. Ik kan ook een ssh connectie opbouwen van het ene netwerk naar het andere en vice versa.
Dus op zich lijkt dat allemaal goed.

Maar soms valt het plotseling uit, niet volledig, maar ten dele. Plotseling lukt een ping van sommige computers van het ene netwerk (192.168.25.0, LAN kant van het OPNsense systeem) naar het andere (192.168.36.0/24, WAN kant) niet meer (een traceroute stopt bij het OPNsense systeem). Van andere computers echter nog wel. En korte tijd later, een minuut of 5 tot 10, gaat alles weer goed.
Surfen in het Internet lukt (dns servers staan in het 192.168.25.0 netwerk, Internet aansluiting hangt achter de router in het 192.168.36.0 netwerk),... meestal.

Ik zoek me een bult en snap er geen fluit van.
En voordat ik dit probleem heb opgelost kan ik ook de firewall regels niet aktiveren. en daarmee heb ik nu nog niet de veiligheid die ik aanstreef.

Heeft iemand een idee waar ik die dobbelsteen optie kan uitschakelen?

--------------------

Goed, ik geef toe dat ik wel de situatie heb geschilderd, maar verder niet al te veel informatie heb verstrekt. Dus daar gaat ie dan:

OPNsense versie:

Code: [Select]

OPNsense 20.1.7-amd64
FreeBSD 11.2-RELEASE-p20-HBSD
OpenSSL 1.1.1g 21 Apr 2020

Hardware:

Code: [Select]

CPU: Intel(R) Celeron(R) CPU  J3160  @ 1.60GHz (1600.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406c4  Family=0x6  Model=0x4c  Stepping=4
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x43d8e3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,RDRAND>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x101<LAHF,Prefetch>
  Structured Extended Features=0x2282<TSCADJ,SMEP,ERMS,NFPUSG>
  Structured Extended Features3=0xc000400<IBPB,STIBP>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8152670208 (7774 MB)

4 Netwerk interfaces, igb0, ..., igb3
In gebruik zijn igb0 en igb1

ifconfig:

Code: [Select]

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
ether dc:58:bc:e0:0e:8a
hwaddr dc:58:bc:e0:0e:8a
inet6 fe80::de58:bcff:fee0:e8a%igb0 prefixlen 64 scopeid 0x1
inet 192.168.36.38 netmask 0xffffff00 broadcast 192.168.36.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
ether dc:58:bc:e0:0e:8b
hwaddr dc:58:bc:e0:0e:8b
inet 192.168.25.60 netmask 0xffffff00 broadcast 192.168.25.255
inet6 fe80::de58:bcff:fee0:e8b%igb1 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=400b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO>
ether dc:58:bc:e0:0e:8c
hwaddr dc:58:bc:e0:0e:8c
inet6 fe80::de58:bcff:fee0:e8c%igb2 prefixlen 64 scopeid 0x3
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: no carrier
igb3: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether dc:58:bc:e0:0e:8d
hwaddr dc:58:bc:e0:0e:8d
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
enc0: flags=0<> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
pflog0: flags=0<> metric 0 mtu 33160
groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
syncpeer: 0.0.0.0 maxupd: 128 defer: off

Routes:

Code: [Select]

root@FW2:~ # route show 192.168.36.0
   route to: 192.168.36.0
destination: 192.168.36.0
       mask: 255.255.255.0
        fib: 0
  interface: igb0
      flags: <UP,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
root@FW2:~ # route show 192.168.25.0
   route to: 192.168.25.0
destination: 192.168.25.0
       mask: 255.255.255.0
        fib: 0
  interface: igb1
      flags: <UP,DONE,PINNED>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
root@FW2:~ # route show default
   route to: default
destination: default
       mask: default
    gateway: dlink
        fib: 0
  interface: igb0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

Disk Usage:

Code: [Select]

root@FW2:~ # df -k
Filesystem      1024-blocks    Used    Avail Capacity  Mounted on
/dev/gpt/rootfs    51414800 1388612 45913004     3%    /
devfs                     1       1        0   100%    /dev
devfs                     1       1        0   100%    /var/dhcpd/dev
devfs                     1       1        0   100%    /var/unbound/dev

Uptime:

Code: [Select]

root@FW2:~ # uptime
 6:17PM  up 2 days,  6:36, 2 users, load averages: 0.67, 0.60, 0.49

Verder geldt: het OPNsense systeem is altijd bereikbaar vanuit het 192.168.25.0 netwerk. Vanuit het OPNsense systeem kom ik probleemloos naar het Internet.
Voor mij ziet het er naar uit dat het OPNsense systeem niet altijd aan zijn routing opgave voldoet.
Ik heb nog geen wetmatigheid ontdekt, maar het lijkt een beetje op: 10 minuten aan, 10 minuten uit.

Ik vind echter niets interessants in de mij bekende logfiles.

Heeft iemand een idee hoe ik nadere informatie vinden kan?

Ronald