Messages

I was looking on the net for a guide...and I was missing the "migration assistant" exactly a line above the NAT menu.
Thanks.

I migrated the firewall rules, but I have lost this part, apologies. There is a guide on hot to perfom the migration?
I am looking, but not yet found.
Thanks.

please double check.

You must be living under a rock. If you are current and have done all the migrations, it was replaced by Source NAT.

before my first reply I checked my system to be sure and here there are the screenshots:

Firewall / NAT / Outbound ...it is there, please double check.

Here: https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#step-9-configure-routing-for-traffic-generated-by-the-router

Q1:

Code Select Expand

Quick=unchecked means that you shall not have any other rule affecting the traffic to the external Authoritative DNS server otherwise this rule could be not effective, correct?

Q2: using a firewall rule to route traffic shouldn't be possible only when the direction is "IN"?

Q3:

Code Select Expand

Source=Select the interface address for your WireGuard VPN (eg WAN_VPNProviderName address)
Destination / Invert=Checked
Destination=Select the interface network for your WireGuard VPN (eg WAN_VPNProviderName net )
here we are telling the system to consider what is exiting any interface + coming from the VPN interface and directed to anything but the VPN subnet....honestly I do not understand this, someone can better clarify this?

Q4: this rule isn't be enough to solve the DNS leaking? (assuming that DNS is managed by opnsense itself) Would it not be best to mention this step again in the "dealing DNS leak" https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html#dealing-with-dns-leaks

Thanks!

Assuming you are using a VPN provider, did you check the official guide?

https://docs.opnsense.org/manual/how-tos/wireguard-client.htm

did you set the MTU of the wireguard to 1420 or lower?

Where you used that mtu value? I am capable to get also 180 Mbps, but I'd prefer to have a slower connection bit more stable.

Only today I found that there is an mtu setting also inside the interface setup page.

My setup has an lte modem - opnsense - wireguard connections (road warrior settings, more or less)

The opnsense guide tells you to lower the MTU value from 1500 to 1420 in the wireguard peer configuration (because of headers).

An official guide on openwrt tells me that the mobile connections ALSO have 80 bytes of headers.

If my assumption is correct I should:

set the MTU of wireguard instances to 1500-80-80 = 1340
set the MTU of the WAN interface to 1500-80 = 1420 (under "interfaces/overview/wan interface")
leave the lte modem to 1500

Some expert can kindly confirm if this is correct or wrong?

I already tried that, but it does not provide the same information.

I have a cpu n100 and 16gb of ram, keeping the unbound dns log active is detrimental for performances?

Is it possible to get a log as in

reporting -> unbound -> details

but extended to much more than 1000 lines and to be able to download it?

The log under services -> unbound dns -> log file seems to be more related to check it is probably working than to get a clear log of the queries.

Thank you.

I did tests for almost 2 years without identifying solution...but honestly I think that the cause lies both on proton side but also on opnsense side: while I am not able to restore the handshake with server A (using opnsense), instead I can do using exactly the same keys&parameters but using the wireguard app on a computer.

I think this is somehow related to my connection: I am using an LTE modem with CGNAT.

I have 3 connections, each one back up the previous one...I started using this configuration because of the connection problems with just one.

Hi, the issue is that proton is not aleays online, periodically and randomically the handshake cannot be restored.

The only ways to restore it are: restart modem (changing the ip) or stop the calls to the VPN entrypoint IP for at least 5 minutes. This script use the second option.

Generally speaking (AFAIK) you can redirect flow going inside an interface, but not a flow that only exit (in this case originated by the firewall itself and leaving through the wan)