Messages

Hi @viragomann,

Thanks, it was effectively the client override CN, I made a mistake taping it, actually everything is working fine.

I really appreciate you help and time on this topic. thanks everyone who take time to read my post and tried to fix it with me.

Best regards

in my case I configured the server instance to not require a CN only to check the certificate and the static Key.

When configuring a CSO you need to state a "common name". This value is either checked against the CN in the client certificate or against the username.

You can toggle this behavior with "Username as CN" in the server settings.

my bad, I totally agree, the CN in the certificate is the same, I think I had to check the NAT - outbound with verbosity on 5 I can spot some dropped packet coming from distant site, should I add NAT rules on both sites ?

So most probably the common name in the CSO doesn't match the CN in the client certificate, presumed your server is configured to check the CN (default).

in my case I configured the server instance to not require a CN only to check the certificate and the static Key.

Use tcpdump on site-A wan, see if your expected vpn-icmp is hitting the wire there outside the vpn. Then you'll know where to look.

tcpdump on Wan site A not showing any ICMP request, tcpdump Site A on ovpnsx showing only requests from 10.100.1.1 to 172.20.2.1 with no answers

So you have to verify if the CSO is even applied.

Enhance the servers verbosity level to at least 4 and reconnect the client. Then check the log.
You should find a line similiar to

Code Select Expand

OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_686559328322f4aa7a88425ea4ead373.tmp
If there is no line like this, the CSO presumably doesn't match.

If the CSO is configured properly and applied, the routes to the clients LAN should appear in VPN: OpenVPN: Connection Status.

No CSO line in the log even with verbosity level 5, the route to the distant LAN is not visible only the route to the TUN GW is visible  the connection status > Routes.

🔧 Setup Overview (abstracted for privacy)
  •  Main Site (Site A):
  •  LAN: 172.20.0.0/24
  •  OpenVPN interface IP: 10.100.1.1
  •  Remote Site (Site B):
  •  LAN: 172.20.2.0/24
  •  OpenVPN interface IP: 10.100.1.2
  •  OpenVPN Tunnel: /29 subnet between 10.100.1.1 ↔ 10.100.1.2
  •  Authentication and TLS are correctly configured (verified with log trace)

No client specific override?
Then OpenVPN cannot route traffic to the clients LAN.

Thank you for your reply, I forget to mention it, client override is also set on the main site

Hello everyone,

I'm currently experiencing an issue with an OPNsense-to-OPNsense site-to-site OpenVPN setup. The tunnel is established successfully, and routing seems correct on both ends. However, I'm unable to reach the LAN interface of the remote site (let's say 172.20.2.1) from the main site (172.20.0.1) using ICMP (ping).

⸻

🔧 Setup Overview (abstracted for privacy)
   •   Main Site (Site A):
   •   LAN: 172.20.0.0/24
   •   OpenVPN interface IP: 10.100.1.1
   •   Remote Site (Site B):
   •   LAN: 172.20.2.0/24
   •   OpenVPN interface IP: 10.100.1.2
   •   OpenVPN Tunnel: /29 subnet between 10.100.1.1 ↔ 10.100.1.2
   •   Authentication and TLS are correctly configured (verified with log trace)

⸻

✅ Current Working State
   •   Tunnel is UP (OpenVPN server logs confirm TLS handshake)
   •   Ping from Site A to Site B's tunnel IP (10.100.1.2) works
   •   Ping from Site B to Site A's LAN (172.20.0.1) works
   •   Routes to 172.20.2.0/24 via 10.100.1.2 are present in Site A routing table
   •   Firewall logs show no ICMP being blocked on either side

⸻

❌ Problem
   •   Ping from 172.20.0.1 to 172.20.2.1 does not return
   •   Using Interfaces > Diagnostics > Ping on Site A → 100% packet loss to 172.20.2.1
   •   On Site B, using Diagnostics > Packet Capture on the OpenVPN interface:
   •   No ICMP requests from 172.20.0.1 are observed, even though the tunnel is up

⸻

🔍 Tests & Observations
   1.   ✅ ICMP echo replies from Site B to Site A are visible (when initiated from Site B)
   2.   ❌ ICMP echo requests from Site A to Site B do not reach Site B at all
   3.   ✅ Firewall rules allow ICMP on both LAN and OpenVPN interfaces
   4.   ✅ No NAT is being applied between the sites
   5.   ✅ Traceroute from Site A to 172.20.2.1 results in timeouts (* * *), confirming the packet does not reach the destination
   6.   ✅ OpenVPN interfaces are assigned and gateways created
   7.   ❌ Gateway status on Site B shows 100% packet loss toward 10.100.1.1 (even though tunnel is up)

⸻

🔄 What I suspect (but need confirmation)
   •   A routing/NAT/firewall issue on Site A, preventing traffic to Site B LAN from being forwarded through the tunnel
   •   Possibly an issue with how OPNsense treats outbound policy routing when using OpenVPN interfaces with gateway monitoring
   •   dinger gateway monitor logs show restarts and signal 15, possibly affecting packet forwarding

⸻

🧪 Next Steps I've Planned
   •   Re-check outbound NAT (currently in hybrid mode)
   •   Add an explicit "No NAT" rule for traffic from 172.20.0.0/24 to 172.20.2.0/24
   •   Test with firewall rules logging enabled
   •   Compare with a working site (other site-to-site tunnels are working fine)

⸻

Any help, advice, or similar experiences would be greatly appreciated.
If needed, I can share sanitized configurations or routing tables.

Thanks in advance!
Best regards,