Messages

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.

Thank you for your help.

Context: NAT Forward is not present for Wireguard and Ipsec because they are on the Opnsense himself.

I have tried to add 172.19.1.0/24 (in source) manually in the SPD but the result is identical.

This SPD get added automatically :
Source                             Destination              Tunnel endpoints
172.17.32.193/28[any]   10.70.38.0/23[any]   172.20.0.253->IP_Public_Remote_Site

IP "172.20.0.253" in the Tunnel is a second LAN but not the one mentioned in IPSEC.

Hi,

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

I am migrating from RouterOS to Opnsense, I have a problem where I want a client connected with wireguard to opnsense be able to access a remote site connected via IPSec.

Client Wireguard (Instance : 172.17.32.193/28) -------> Opnsense (LAN : 172.19.1.0/24) -------IPSec--------> remote Site (10.70.38.0/24)

Maybe someone have some tips for me.

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)

IPSec configuration :
Local Nets : 172.19.1.0/24
Remote Nets : 10.70.38.0/23

If I use traceroute since Opnsense with Hostname/IP : 10.70.38.56, Protocol : ICMP, Source address : 172.19.1.253 (GW LAN/Interface address) it works. The packet passes through the 2 public IPs (Local and Remote).

If I use traceroute since  Wireguard client to remote site connected with ipsec don't work. Details :
traceroute to 10.70.38.56 (10.70.38.26), 30 hops max, 60 byte packets
1  172.17.32.193 (172.17.32.193)  10.994 ms  10.879 ms  10.855 ms
2  * * *

I tried to create :

• a "dynamic" gateway and disabled routing in the wireguard config.
• a static route and specify GW (172.17.32.193(LAN GW)) or 172.17.32.192(WG GW). (like on RouterOS)
• a rule NAT Outbound : Interface:WG0   Src address: :172.19.1.0/24   Dst adress:10.70.38.0/23        Transition :Interface address

The same behavior. I can´t reach the IP behind the ipsec tunnel. 

Thank you in advance for your help.

Similar problem :
https://forum.opnsense.org/index.php?topic=41037.msg201152#msg201152