<![CDATA[Routing Traffic Across 2 VPNs]]>Been trying to wrap my brain around this and for some reason I can't figure it out.

Long story short, I have a wireguard mobile VPN, the client on that VPN needs to access a service on a subnet that the WireGuard "server" has a connection to over IPSec.

So: client > WireGuard "server" pfsense > IPsec VPN > remote service

I've got rules in place to pass the traffic on WireGuard to the subnets across the IPsec VPN, but no matter what I do pfSense running WireGuard replies with a syn closed instead of forwarding the packets.

I'm sure it's something simple that I'm missing but just need another set of eyes on it I guess.

]]>https://forum.netgate.com/topic/171220/routing-traffic-across-2-vpnsRSS for NodeFri, 17 Apr 2026 05:55:10 GMTThu, 31 Mar 2022 20:48:02 GMT60<![CDATA[Reply to Routing Traffic Across 2 VPNs on Thu, 31 Mar 2022 21:38:59 GMT]]>@stephenw10 You are 100% absolutely right, knew it had to be something stupid I was missing lol. Good to go now ,thanks!

]]>https://forum.netgate.com/post/1035549https://forum.netgate.com/post/1035549Thu, 31 Mar 2022 21:38:59 GMT<![CDATA[Reply to Routing Traffic Across 2 VPNs on Thu, 31 Mar 2022 21:35:18 GMT]]>If you're using policy based IPSec (not VTI, route based) then you need a phase 2 policy in the IPSec tunnel to cover the traffic from the Wireguard subnet to the remote service subnet. It sounds like you don't have one so pfSense uses it;s default route to try to reach it.

Steve

]]>https://forum.netgate.com/post/1035548https://forum.netgate.com/post/1035548Thu, 31 Mar 2022 21:35:18 GMT<![CDATA[Reply to Routing Traffic Across 2 VPNs on Thu, 31 Mar 2022 21:29:05 GMT]]>So now I've confused myself more, it seems that pfSense is sending these packets outside it's default gateway (wan) as if it doesn't have a route but it definitely has a route since every LAN interface directly on pfSense can send traffic over this IPSec VPN just fine.

]]>https://forum.netgate.com/post/1035547https://forum.netgate.com/post/1035547Thu, 31 Mar 2022 21:29:05 GMT