Hello!
I have the following topology:
VPS (iptables) <‑‑ IPSec VTI <‑‑ OPNsense <‑‑ WebServer
3.3.3.3 | [10.64.0.2/30 <‑‑ 10.64.0.1/30] | 2.2.2.2 <‑‑ 192.168.100.4
- 3.3.3.3 – public IP address of the VPS.
- 2.2.2.2 – public IP address of the OPNsense box.
- 10.64.0.0/30 – address space used for the IPSec VTI tunnel.
- 10.64.0.2 is advertised as the gateway on the tunnel side of OPNsense.
The tunnel is up and functioning.
When an inbound packet arrives from the VPS side, I can see it reach OPNsense and then be delivered to the WebServer (TCP SYN). However, the client never receives a reply.
What I have tried:
1) Policy‑Based Routing (PBR) on the WebServer's network – set 192.168.100.4 to use ipsecX(10.64.0.2) as the next‑hop. Traceroute shows the traffic follows the expected path.
2) Reply‑to rule on enc0 (the IPSec interface) – added reply‑to ipsecX(10.64.0.2) in the allow rules. (src: any, src_port: any, dst: 192.168.100.4, dst_port: 443, reply_to: ipsecX(10.64.0.2).
tcpdump on enc0 shows the outbound traffic attempting to go to the client (192.168.100.4 → client IP). No return traffic is observed on the opposite side of the tunnel. The VPS has IP forwarding enabled, NAT configured to its public IP, and port‑forwarding rules in place. There are no firewall rules that would block the traffic.
Observation: If I add a static route on OPNsense such as client‑IP/32 → 10.64.0.2, the communication works immediately.
Question: Any ideas why the reply traffic does not traverse the tunnel without the explicit host route? Could my reply‑to configuration be incorrect?