Messages

Reboot opnsense this weekend due to latest update.

No ping on hosts on remote network: 10.220.0.0/16.
Ok after a manual restart of the tunnel.

If anyone has any ideas. The capture was made before the restart of the tunnel.

Hello,

We are experiencing an IPsec tunnel connectivity problem with OPNsense that occurs specifically on system reboots.
One particular IPsec tunnel fails to reconnect automatically after an OPNsense reboot, while all other tunnels reconnect without issue.The blockage seems to be in phase 2.

Workaround:

Once manually restarted via the interface, the tunnel remains stable until the next system reboot.
The problem occurs systematically each time OPNsense is restarted.

Configuration details :

• Tunnel Configuration: No special or unique configuration settings compared to working tunnels.
• Rekey Settings: Reconnection time values are correctly matched and identical on both endpoints.
• Symmetry: Both sides of the tunnel have consistent configuration settings.

Do you have any idea what might be causing this malfunction or any idea of a setting that might solve the problem?

Thank you in advance,

Best regards,

Thanks for your feedback.

It confirms what we thought, which is why we only applied it where it caused problems.

We don't have NFS, nor SMB etc... but if the infrastructure evolves. But in any case, it's preferable not to create other problems.

Do you think MSS Clamping should be applied across the entire network?
Would there be any problems if we activated this "normalization" everywhere?

ICMP is filtered on the public IP on the Proxmox VE side and on the additional public IP of the server used by the Opnsense WAN interface.
Do you think that allowing it would change anything? Since PMTU is a standard, it is natively authorized?

Edit: I've tried authorizing it, but it doesn't change anything.

Thank you for your answer.

How do I get the "path mtu discovery" (PMTUD) function to work properly? Is it possible to do this other than with MSS Clamping ?

Similar problem : https://community.spiceworks.com/t/network-mtu-problems/1112518/2

Hello,

We are experiencing TCP fragmentation issues on our network infrastructure, which have been resolved by implementing MSS Clamping (https://docs.opnsense.org/manual/firewall_scrub.html). Here are the details of our environment and situation:

Environment:

• Proxmox Virtual Environment (PVE) with multi-site Software Defined Networking (SDN) using VXLAN zones
• MTU set to 1450 on all VMs due to VXLAN encapsulation requiring 50 additional bytes (Proxmox documentation: https://pve.proxmox.com/pve-docs/chapter-pvesdn.html)
• OPNsense virtualized on these PVE hosts

Current Configuration:

• MSS Clamping enabled via "Firewall: Settings: Normalization"
• Specific rules created for interfaces experiencing issues:
• WireGuard VPN group interface (configured on OPNsense)
• 2 LAN interfaces (one with VMs using WireGuard+OpenVPN, and another where we limited the source to the VM requiring long curl requests)
• Max MSS value set to 1250

Symptoms observed before correction (non-exhaustive list):

• Timeouts on long requests (curl)
• Access issues to Proxmox consoles
• SSH connection difficulties

Note:

• Currently, no negative impact observed on IPSec tunnels configured on OPNsense or other LAN interfaces

Our question concerns the optimal strategy for MSS Clamping implementation:

• Should we apply it globally across the entire network?
• Or is it better to maintain our current targeted approach, applying it only to interfaces experiencing issues?
• Would there be a knock-on effect if we activated this "normalization" everywhere?

Thank you in advance,

Best regards,

Hello,

Have you found a solution?

https://forum.opnsense.org/index.php?topic=41486.0

I have 2 opnsense (primary and slave) where this tunnel appears, but a different IP range for the "Virtual Network".
When I check with the keyword "wg" (primary), the route 172.28.0.0/16 is not listed, but my secondary's route 172.29.0.0/16 is.

What I can't explain?

So I disabled the tunnel on the secondary and took its IP range 172.29.0.0/16 (Virtual Network) and put it on the primary.
The 172.29.0.0/16 range is indeed listed as "Allowed Address" on the WG side.

The ping from my WG peer comes out fine this time through the WG tunnel, so there's an improvement.
Since it goes through the tunnel, the ping appears in the Live View and is in "pass" status when I filter the Virtual IP of my OpenVPN client (172.29.0.6).
However, it doesn't reach the destination. I'm still looking for a solution.

Thanks for any help

The ping from my WG peer doesn't go out and goes through my local IP instead of through the WG tunnel. If I force the ping on the WG tunnel interface, it doesn't work either.
So no packet received on my host with the OpenVPN client (during tcpdump).
However, I can ping the WG peer from the OpenVPN client...

Does anyone have any ideas? Thanks in advance.

Unique tunnel IP address WG, IPsec network and I have add the  "Tunnel Network"  OpenVPN.

Thank you for your reply, unfortunately I had already tried it and I've just done it, but it doesn't change anything.

For IPSec I had the same problem, which was solved by mentioning my WG instance in the SPD section and creating an entry in SNAT using the IP of my gateway on the LAN side for translation.

https://forum.opnsense.org/index.php?topic=41108.msg201474#msg201474

[VPN > OpenVPN > Servers (Legacy)]

Hi,

I have a problem and can´t find any solutions.

Client Wireguard (Instance : 172.17.32.193/28) -------> Opnsense (LAN : 172.19.1.0/24) -------> OpenVPN (Tunnel Network : 172.28.0.0/16)

Part of my setup:

- 2x WAN
- IPSEC Connections (new method)
- WireGuard with multiple interfaces
- Wireguard Interface Rules has a ANY rule WG0  (used for my test)
- VPN > OpenVPN > Servers (Legacy)

OpenVPN configuration :
Tunnel Network : 172.28.0.0/16
Local Nets : 172.19.1.0/24

The connection is present (VIP : 172.28.0.6) and I have an "OK" status in "Connection Status".

Since Opnsense to VIP (OpenVPN) :
The ping is OK from Opnsense without specifying a source.
The ping is OK when specifying 172.19.1.253 (GW LAN) as the source.

Since WG Client to VIP (OpenVPN)  :
The ping is KO, and does not go through the WG tunnel.
I tried to create a SNAT rule (Firewall > Automation > Source NAT) specifying 172.19.1.253 as the translation address, but there seems to be a route problem.

How can I specify that the OPNsense needs the Wireguard Net as additional local network on the OpenVPN connection?

Thank you in advance for your help.

https://forum.opnsense.org/index.php?topic=41108.msg201809#msg201809

Thanks for your reply, the problem has been solved and it's thanks to you for pointing me in the right direction.


To solve the problem you need to :

Create a manual SPD in VPN > IPSEC > Security Policy Database :

• Source network = IP WG Instance : 172.17.32.193/28
• Destination network : empty

Created a SNAT rule in Firewall > Automation > Source NAT :

• Do not NAT : Uncheck
  
• Interface : Ipsec
• Source address = IP WG Instance : 172.17.32.193/28
• Destination = Range IP Remote site IPSec : 10.70.38.0/23
• Translation = LAN GW : 172.19.1.253 (of the network specified in Local NETs in IPSec children)

Last question:
I specified a number (1) on the ReqID in order to apply the manual SDP entry (my WG network) on all remote sites/connections. However, if I select an entry in "Connection child", the manual SDP entry will only apply to one remote site/connection.
Does this number need to be specified in all connection children as a best practice? It works without specifying it.