Messages

I'm interested in this. When the system is in the "broken" state is there any "0.0.0.0" in the ifconfig output or in the pf.conf rules?

# ifconfig | grep 0\\.0\\.0\\.0
# grep 0\\.0\\.0\\.0 /tmp/rules.debug

Because if there is not this might be a kernel bug in FreeBSD 13.1 or our auxiliary patching for it (shared forwarding).


Cheers,
Franco

I am currently really glad that I could somehow solve the problem. Nevertheless, I would like to help, of course, if this is a general problem.

I still have the backup config XML where the problem occurred. If I find time tomorrow I will restore it to a virtual machine with OpnSense. Then I can do the said searches for 0.0.0.0.

I was able to fix it. But don't ask me how. Tried so many things.
Most likely it was related to a old failover interface (not connected).

Thanks a lot for this.

This finally fixed my update problem and I believe it will fix my wireguard problem as well.

I only had automatic NAT rules before - none of which changed IP.

I don't really get your point. But good to know this was somehow helpful.

[how]

Can be closed. I was able to fix it by myself.

And how exactly, please?

I'm not 100% sure. But i disabled e.g. a failover interface (which i don't use anymore) and all routes / gateways belonging to it. I also disabled dynamic gateway switch globally.

Can be closed. I was able to fix it by myself.

[major]

Hello guys,

One important note beforehand: this all is not working anymore since my update to 22.7.2.

might be somehow a copy of https://forum.opnsense.org/index.php?topic=29962.0 , but i think this is quite urgent and not directly related to Wireguard.

On my firewall, after the latest update, every traffic originated from the firewall itself leaves with a source ip of 0.0.0.0. Therefore i never receive any answer.

If i do ping 9.9.9.9 --> no answer
If i do ping -S <WAN_IP> 9.9.9.9 --> everything works as expected

I added a NAT rule (Outbound, Interface WAN, Source IP 0.0.0.0/32, Destination !PRIVATE_NETWORKS(10.0.0.0/8, 192.168.0.0/16,..., MASQUERADE with WAN IP) --> now ping 9.9.9.9 works

This is definitly a major problem for me. Does anybody has a clue whats going on here?

Thanks in advance!

[really]

I was able to narrow down the problem even further.
Now it's getting really interesting!

Everything that leaves the firewall and is not bound by IP to a specific interface, e.g. ping, goes out with the source ip 0.0.0.0. Therefore no response is received.

See screenshot.

That peer is a smartphone, therefore only one ip is correct.

I have some addition: This is what a wireguard log looks like. I captured on WAN side.

Is 0.0.0.0 as sender OK? Looks not right.

Hello together,

Since the last update to OPNsense 22.7.2, none of my wireguard tunnels work anymore. I never had a problem with Wireguard and OPNsense before, how can this be?

Am I the only one for whom Wireguard no longer works?

The error image shows that traffic reaches the Wireguard server on my OPNsense and the server supposedly responds (see image) --> however, this traffic does not reach the endpoints on the other side.



I also did a complete reinstall of OpnSense and played back a backup. Problem stays the same.

Hallo,

ich wollte nur mal anfragen, ob bei der Verwendung von DNS over TLS im Unbound, die gesendeten Server TLS Zertifikate validiert werden? Der Theorie nach, dürfte der Unbound sonst ja keine Daten von z. B. gefaketen Cloudflare DNS Servern akzeptieren.

Komischerweise muss man aber keine Common Names oder ähnliches angeben sondern gibt ja die DoT Server im Stil IP@Port an.

Kann mir das hier jemand näher erläutern? Muss ich davon ausgehen dass Unbound auch bei einem möglichen Man in The Middle Angriff weiter DNS Anfragen beantwortet?

Danke!