Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Kornelius777

#1
Dear all,

On my wireguard gateway, I am monitoring the remote IP address.
This is no problem at all @IPv4,
however,
the IPv6 Gateway Monitoring Service stays down after every reboot and needs to be re-started manually.

Is that a bug or a feature?

If it's a bug - where will I report it?

Kind regards,
#2
German - Deutsch / Re: Probleme mit ULA in VLANs
April 22, 2024, 05:06:52 PM
Quote from: Maurice on April 18, 2024, 02:18:08 AM
Virtual IP-Mode ist "IP Alias"? Auf den Servern sind die ULAs ebenfalls als /64 angelegt?

Ja und ja.

Quote from: Maurice on April 18, 2024, 02:18:08 AM
Gateway-Adressen sind üblicherweise link-local, keine GUAs oder ULAs.

Darin sehe ich wenig Sinn. Route sollte Route sein.
#3
Answering my own question:

mimugmail posted a short but effective answer (https://forum.opnsense.org/index.php?topic=34815.msg168643#msg168643) , saying:
QuoteIn GUI set the filter rule, at the bottom tick advanced, scroll down, "keep state" to none

Indeed, this solved my troubles.

Chapeau! Thank you, mimugmail!
#4
Dear all,

Inside my LAN, there ist a wireguard server (connecting to other sites, of course).
My OPNsense knows about the route.

Now, if I access one of my Cloud Servers (using my PC), the outgoing connection will go via the OPNsense:

laptop:~$ tracepath -n 10.20.50.7
1?: [LOCALHOST]                      pmtu 1412
1:  192.168.150.1                                         1.284ms
1:  192.168.150.1                                         1.047ms             <--- OPNSense
2:  192.168.150.150                                       1.585ms asymm  1    <--- wireguard server LAN Interface
3:  10.20.50.1                                           25.557ms asymm  2
4:  10.20.50.7                                           25.343ms !H
     Resume: pmtu 1412


However, the way back into the LAN does NOT go via the OPNsense:

cloud-server-1:~# tracepath -n 192.168.150.205
1?: [LOCALHOST]                      pmtu 1280
1:  10.20.50.1                                            0.700ms
1:  10.20.50.1                                            0.591ms
2:  10.20.50.3                                           22.306ms      <--- Wireguard Server wg0 Interface
3:  192.168.150.205                                      23.537ms reached
     Resume: pmtu 1280 hops 3 back 3


Since OPNsense doesn't see the incoming traffic, the State Table will close any SSH connection after 15 minutes (Firewall Optimization is set to "conservative"). I call this situation "sub optimal".

Is anybody kind enough to give me a hand?
How can I get around this situation?

Is there a way to tell OPNsense "If traffic is going this way (10.20.50.0/24), never close the connection"?

At the moment, I am a little bit clueless...

Kind regards!
#5
German - Deutsch / Probleme mit ULA in VLANs
April 11, 2024, 05:28:26 PM
Hallo zusammen!

Meiner opnsense habe ich mehrere virtuelle IP-Adressen verpasst - eine pro VLAN.
So habe ich z.B. im VLAN1 fdaa:bbbb:cccc:1::1/64, im VLAN2 fdaa:bbbb:cccc:2::1/64 und so weiter.

Manuell habe ich den Servern pro VLAN eine passende ULA zugeordnet.

Jetzt habe ich versucht, aus der Sense heraus eine Server-ULA zu erreichen (ping, traceroute... egal.). Ich konnte z.B. die Adresse fdaa:bbbb:cccc:8::8:56 nicht erreichen. Die Sense weiß einfach nicht, wie sie dort hinkommen soll. WEIRD!

Einer meiner Server stellt ein Gateway zu anderen Netzen dar. Die IPv4-Adresse des Gateways ist grün, die IPv6-(ULA) ist rot, weil die Sense die Route nicht kennt.

Ein Gateway mit einer dynamischen GUA anzulegen (auch mittels Alias) war mir nicht möglich. Kennt jemand die Lösung? Wie geht das?

Zwei Fragen also:
Wie kann die Sense Routen zu ULAs lernen?
Wie legt man ein IPv6-Gateway (GUA) mit dynamischer IP-Adress-Range an?

Herzlichen Dank für Eure Gedanken!
#6
Quote from: soundie on November 10, 2023, 01:58:45 PM
I've been having this issue the last couple days.
Resolved it by setting the update mirror manually to Aalborg University - then checked for updates, and everything worked :)

Thank you!
This hint saved my day!

Kind regards!
#7
Following up on my own post:
It looks like my FritzBox (the ISP Router) received a new IPv6 Prefix at 20:23:30.
opnsense reports afterwards:
2023-08-12T20:23:34   Notice   dhcp6c   dhcp6c_script: RENEW on em0 executing

However:
How does this fit into the chronology of the filter.log?
The blocking events happened before the IPv6 Change...

Scratching my head...
#8
Dear all,

in my network, I have a zabbix server running (at ::20) which is using a mariadb server (at ::62). Both are on the LAN interface.

Yesterday, all of a sudden, I see this in my filter.log:

<134>1 2023-08-12T20:21:59+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435528"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xc1418,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,36882,0,A,,3150097180,8110,,nop;nop;TS
<134>1 2023-08-12T20:22:09+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435604"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xade03,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,56436,0,A,,3128288619,9767,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435893"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x54772,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,47300,0,A,,2174907491,501,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435894"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xb4439,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54974,0,A,,477656593,502,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435895"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xdaa7b,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55018,0,A,,658336494,502,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435896"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x41658,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55014,0,A,,866722073,9720,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435897"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xc7706,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55002,0,A,,1813106765,817,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435898"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x9d0d0,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54992,0,A,,2791888317,9744,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435899"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x3082b,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54986,0,A,,619335935,9813,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435900"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x6cabb,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55034,0,A,,3816875453,13877,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435901"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x7a9b5,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55046,0,A,,1415215424,9755,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435902"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xddffc,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55048,0,A,,2768401767,9802,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435903"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xfbf1e,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54862,0,A,,1599404197,9790,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435904"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x824c3,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54874,0,A,,3716731802,9697,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435905"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xb82db,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54880,0,A,,1416812441,502,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435906"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xbe660,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,54984,0,A,,3363215183,5263,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435907"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0x2755e,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,43444,0,A,,2445388427,657,,nop;nop;TS
<134>1 2023-08-12T20:23:04+02:00 OPNsense.lan.xxxx.de filterlog 33664 - [meta sequenceId="435908"] 18,,,02f4bab031b57d1e30553ce08e0ec131,re0,match,block,in,6,0x00,0xe19cf,64,tcp,6,32,2a02:b30:f1f:72ff::62,2a02:b30:f1f:72ff::20,3306,55054,0,A,,4186526575,9755,,nop;nop;TS


and at the same time, crowdsec blocks the mariadb server, because it performed a PORT SCAN?!?!?

Would somebody be able (and kind enough) to explain to me what happened here?
What might have lead my opnsense to blocking this on the LAN port?

Kind regards,
#9
It looks like when setting "Firewall Optimization" to "conservative", the ssh connection is a lot more stable.
How can I investigate this issue any further?
#10
Dear all,

since a while, I am facing a strange behaviour of my OPNsense firewall:

My setup is as follows:

LAN1 <--> wireguard server <--> OPNsense <--> Internet <--> Remote router <--> wireguard server <--> LAN2

Both wireguard servers are distinct machines.

When I establish a connection from LAN1 to LAN2, the connection will be interrupted after about 1 minute - regardless whether ssh, http, https - every connection will be interrupted.
And I always see something like:

__timestamp__ 2023-05-14T11:31:19
ack 1421731495
action [block]
anchorname
datalen 44
dir [in]
dst 192.168.144.222
dstport 22
ecn
id 65429
interface re0
interface_name lan
ipflags DF
ipversion 4
label Reject LAN net @anywhere
length 96
offset 0
protoname tcp
protonum 6
reason match
rid 5b365651e685f4e2bf5168036efe6f63
rulenr 216
seq 1680107980:1680108024
src 192.168.150.205
srcport 59690
subrulenr
tcpflags PA
tcpopts
tos 0x10
ttl 64
urp 501


I just cannot find the reason for the TCP PA.
Why will the State Table keep dropping these connections?
Where can I look for problems?

Kind regards,
#11
LAN net is 192.168.150.0/24

Yes, State Table has been reset
#12
Dear all,

the last few lines in my firewall rules look like this:

https://pasteboard.co/a28FaMlCVZ7I.png

However...
While accessing a website connected via a gateway, I keep getting this stuff:

https://pasteboard.co/r9ABXkZaw4t9.png

I was under the assumption that this last firewall rule should never be reached - I only inserted it for debugging purposes. How can I find out why the "grant all" rule is skipped?

Kind regards,
#13
23.1 Legacy Series / Re: Issue with Network Time
March 15, 2023, 01:49:18 PM
As usual, the mistake was 40 cm in front of the screen...

Of course, I had to check "LAN" on the interfaces drop down list.

Sorry for bothering you...
#14
23.1 Legacy Series / Re: Issue with Network Time
March 15, 2023, 01:41:03 PM
root@OPNsense:~ # ping 192.168.150.72
PING 192.168.150.72 (192.168.150.72): 56 data bytes
64 bytes from 192.168.150.72: icmp_seq=0 ttl=64 time=0.344 ms
64 bytes from 192.168.150.72: icmp_seq=1 ttl=64 time=0.243 ms
^C
--- 192.168.150.72 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.243/0.293/0.344/0.051 ms


I probably added them some 30 minutes ago. However, the Time Source doesn't report OPNsense as a client ("chronyc clients") and the status is still "Unreach/Pending".

For testing, I even set chrony.conf to "allow 0.0.0.0/0"
No success, so far....
#15
Dear all,

on my LAN, I run two Stratum-1-clocks which I wish to use as the Time Source for my OPNSense Firewall.
Having added them to "Services --> Network Time --> General" results in "Unreach/Pending" on the Status Page.

Will I need to add anything on the Firewall to enable this setting?
I'm confused.

Would anyone be so kind as to share their thoughts with me?