Messages

Hold on...I need to enable web proxy before clamav will be used? If yes I did not know this. I don't believe the doc explains this clearly. If I setup transparent http proxy will clamav be engaged? Do I need icap at that point?

Yes, you need to setup web proxy and cache. But everything is explained in this doc:
https://docs.opnsense.org/manual/how-tos/proxyicapantivirusinternal.html

Hey there,

you should describe your network setup more detailed to get some help...
How are clients and WAN connected to opensense? Is your 2nd router the WAN modem?
Where are wifi devices connected to?

What logs did you look at to think there is no traffic to pass through? Firewall logs?
Maybe default allow is not set to be logged?

Clamav will not check traffic until you setup a proxy. Did you?

Thank you for sharing, I already tried out and checked everything mentioned in this chapter, but nothing worked for me.

Knowing that these entries are nothing to worry about I would just like to know why they massively appear since I changed my hardware (espacially NICs)... I can live with that, its just a little annoying...

I have similar issues (since new hardware) , questioned in german forum some days ago.
Did you have a look at the tcp flags? In my case those packets are hit by default deny because they are out of state.

But can`t figure out why there are (in my case so much) out of state packets.

Moin nochmal,

habe nun etwas herumgetestet:
Die Meldungen kommen auch, wenn ich den ISP wechsle (Prio in der gateway group).
Auch wenn ich die gateway group aus dem policy based routing nehme und direkt über das gateway gehe erscheinen diese Meldungen.
Die fw optimization stand auf normal, wie auf meiner vorherigen appliance auch.
Nachdem ich nun auf conservative umgestellt habe kommen die Meldungen nicht mehr, natürlich auf Kosten einer um 100% gestiegenen CPU auslastung. Von diesem workaround würde ich gerne absehen und frage mich natürlich warum das erst jetzt mit der neuen appliance auftritt.
Kommando zurück, ist nun doch wieder aufgetreten...

Hat dazu noch jemand eine Idee?

Gruß

nope, sorry, never used such setting...

should be

Code Select Expand

–reneg-sec n in config file, but maybe this command doesnt exist in client config.

for reference the command description from ovpn:

–reneg-sec n
    Renegotiate data channel key after n seconds (default=3600).When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.

    Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set –reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase –reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side.

Hey there,

there ist a setting

Code Select Expand

Renegotiate time under advanced VPN Server config:

Code Select Expand

Renegotiate data channel key after n seconds (default=3600).
When using a one time password, be advised that your connection will automatically drop because your password is not valid anymore.
Set to 0 to disable, remember to change your client as well.

Maybe thats it what you are looking for...
Otherwise you should post some logs from VPN server at verbosity level 3 or 4

Moin,

danke für Deine Rückmeldung... ja igb0 ist das LAN Interface.

"Tritt gelegentlich auf" war etwas unglücklich bzw. falsch formuliert:
Es tritt durchaus häufig auf, die logs sind quasi voll damit (seit gestern 22:45 bis heute 07:00 ca. 1000 Einträge).
Es sollte nur heißen, dass nicht alles komplett geblockt wird, da der Internetzugriff vom LAN ja nunmal funktioniert.

Asynchrones Routing (wenn ich es richtig verstanden habe mehrere default Gateways) sollte es hier zumindest nicht bewusst geben, wobei ich durchaus mehrere Gateways habe:

1. WAN_DG_DHCP6 (active)           WAN_DG    IPv6    250 (upstream)
2. WAN_DG_DHCP (active)            WAN_DG    IPv4    250 (upstream)
3. LTE_PPP                                    LTE              IPv4   254 (upstream)
4. WAN_htp_GWv4                      WAN_htp     IPv4     255

Nr. 2 und 3 sind in einer GW Group (Failover) und Nr. 3 wird nicht als upstream verwendet sondern dient lediglich (temporär) für den VPN Verbindungsaufbau über IPv4.
Für die GW Group exisitert eine entsprechende FW Regel auf LAN, die alles außer DNS an die GW Group leitet.

Ich habe mal die default pass rules auf LAN mitgeloggt um zu sehen, was um diese Meldungen herum passiert, eventuell gibt es hier ja einen Hinweis (den ich nicht sehen würde):
In rot default deny und grün default allow LAN to any; igb2 (blau) ist das WAN Interface, der Rest DNS.

2020-05-27T07:28:23   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61778,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:19   filterlog: 87,,,0,igb2,match,pass,out,4,0x0,,63,53494,0,DF,6,tcp,60,100.73.101.101,80.158.23.146,27337,80,0,S,121773098,,65535,,mss;sackOK;TS;nop;wscale
2020-05-27T07:28:19   filterlog: 101,,,0,igb0,match,pass,in,4,0x0,,64,53494,0,DF,6,tcp,60,10.13.12.60,80.158.23.146,57618,80,0,S,121773098,,65535,,mss;sackOK;TS;nop;wscale
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53583,0,DF,17,udp,84,10.13.12.60,10.13.12.2,36074,53,64
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53581,0,DF,17,udp,84,10.13.12.60,10.13.12.2,52120,53,64
2020-05-27T07:28:18   filterlog: 94,,,0,igb0,match,pass,in,4,0x0,,64,53580,0,DF,17,udp,84,10.13.12.60,10.13.12.2,36064,53,64
2020-05-27T07:28:15   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61777,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:11   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61776,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:10   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61775,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:09   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61774,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61773,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61772,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,
2020-05-27T07:28:08   filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,61771,0,DF,6,tcp,40,10.13.12.60,80.158.23.146,57588,80,0,FA,378695775,1760214647,347,,

Leider bin ich nicht daheim um feststellen zu können was genau in diesem Moment abgerufen wurde, beim Client handelt es sich jedenfalls um ein Android Gerät.
Bei weiterer Beobachtung der logs ist auch festzustellen, dass das "Problem" nicht bei jeder Verbindung auftaucht sondern einiges so wie es soll durchgeht.

Gruß

Moin zusammen,

bevor es zur Sache geht so wie ich es vor Jahren mal gelernt habe kurz einmal zu mir:
Ich nutze opnsense seit vergangenem Jahr für mein Heimnetz, insbesondere wegen des OVPN Servers und WAN Failover. Bei der Einrichtung und sonstigen Problemen habe ich mich immer hauptsächlich durch die Docs und Forenbeiträge geschummelt oder gemäß Try and Error ausprobiert... demnach hält sich meine Erfahrung mit der gesamten Materie etwas in Grenzen, außerdem bin ich GUI-Liebhaber der nur hobbymäßig Bezug zur IT hat ;)

Beim Wechsel zu einem neuen ISP (Deutsche Glasfaser) im verganenen Monat habe ich auch meine Hardware gewechselt (Terra/ Wortmann RC100 G3) und opnsense 20.1.7 entsprechend neu aufgesetzt.
Mein ISP liefert mir CGNAT und natives v6, opnsense hängt direkt am Modem, alles läuft soweit einwandfrei.

Was mir auffällt sind jedoch Einträge in der FW-log auf die ich mir keinen Reim bilden kann, wobei igb0 und 10.13.12.0/24 mein LAN ist.

Code Select Expand

filterlog: 16,,,0,igb0,match,block,in,4,0x0,,64,34390,0,DF,6,tcp,76,10.13.12.60,172.217.16.138,46232,443,24,FPA,2298045867:2298045891,3739770163,376,,nop;nop;TS

Das gleiche tritt auch auf IPv6 und von unterschiedlichen Clients auf...
Wie kann es sein, dass hier Pakete geblockt werden, die vom LAN ins WAN gehen, obwohl eine default allow LAN to any Regel besteht?

Einschränkungen merke ich wie gesagt nicht, die Einträge sind nur ziemlich lästig und bereiten mir die Sorge, dass irgendwo doch der Wurm drin ist...

Sollten noch Infos benötigt werden stelle ich diese natürlich gern zur Verfügung, ich will jetzt nur nicht mit redundanten Infos um mich werfen...

Gruß