Need to route traffic destined for a specific external IP from Office B through Office A via Wireguard

PraeceCharles

Hi all,

We have 2 offices, both with Netgate 4200 firewalls.

There is a cloud service in use that requires IPs that access it be added to their whitelist. We'll call the external IP for this cloud service IP1.

Office A has a static IP that is whitelisted and can access the service fine. Office B is on satellite internet that does not offer static IPs and can potentially see multiple public IP changes per day as different satellites connect. There is a Wireguard split tunnel set up between the two offices on the 4200s.

What I want to accomplish, ideally without configuring a full tunnel, is as follows:

Office B makes a request to IP1, any kind of request
That request gets routed through the Wireguard tunnel, and goes out to the public internet via Office A's static IP
Cloud service at IP1 sees the traffic as coming from Office A's static IP and accepts it
Return traffic flows properly back to the host at Office B

Office B has external IP1 added to the Wireguard Allowed IPs list and a static route to always send traffic for IP1 over the Wireguard tunnel. I can't figure out where the packets are getting lost at this point, though. If I set a Wireguard interface firewall rule at Office A to pass and log all traffic to external IP address X, I get logs for passed packets when trying to access the IP from Office B, so they're getting over the tunnel. But pings, tracert, etc. all fail, and I'm having a hard time determining where exactly they're failing.

PraeceCharles

I should also add, both ends have Wireguard fw rules to allow all traffic as well.

viragomann

@PraeceCharles
You have to add an outbound NAT rule at A to masquerade outgoing traffic from B.

If the outbound NAT is an automatic mode,enable the hybrid mode and save this.
Then add a rule:
interface: WAN
source: B LAN subnet
dest: IP1 or any
translation: interface address

Office B has external IP1 added to the Wireguard Allowed IPs list

This shouldn't be necessary, since you don't expect incoming traffic from this IP.

PraeceCharles

@viragomann that was exactly what was needed, thank you.