Messages

Nobody able to help?

Dear all,

I have two local networks connected to each other via two different wireguard connections.

What I would like to know:
How can I establish a route metric/route cost, so that one of the two connections only works as a kind of a fallback?
Without a metric, the possibility to crate a routing loop is quite high.

Could somebody please give me a hand?

Kind regards,

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,

Virtual IP-Mode ist "IP Alias"? Auf den Servern sind die ULAs ebenfalls als /64 angelegt?

Ja und ja.

Gateway-Adressen sind üblicherweise link-local, keine GUAs oder ULAs.

Darin sehe ich wenig Sinn. Route sollte Route sein.

Answering my own question:

mimugmail posted a short but effective answer (https://forum.opnsense.org/index.php?topic=34815.msg168643#msg168643) , saying:

In 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!

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:

Code Select Expand

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:

Code Select Expand

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!

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!

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!

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...

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:

Code Select Expand

<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,

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?

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:

Code Select Expand

__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,

LAN net is 192.168.150.0/24

Yes, State Table has been reset

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,

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...