Background:
I have (almost) IPv6-only network with two WAN from two independent ISP. I use NPTv6 to match the ULA with the external IP.
Everything works fine. If I send one UDP/TCP/ICMP packet to 2001:my:isp:1111::4242 I get a reply from the same 2001:my:isp:1111::4242. If I send to 2001:another:isp:2222::4242, I get a reply from 2001:another:isp:2222::4242. The `reply-to` is working.
In the underground both IPs are translated to fd00::4242 (for instance).
The Wireguard:
I added a Wireguard connection (as client). So, my OPNSense is connected to an external server. That external servers routes the /64 block to Wireguard tunnel and also have a NDP proxy.
Back to OPNSense, I have added the "external server IP" to my NPTv6.
The goal:
Well, I want to use the /64 from the external server. Basically, my server can be reached by 2001:server:ip:2222::4242. That will send the packet to fd00::4242, similarly to ISP 1 and ISP 2.
In other words, use Wireguard as GRE Tunnel or another ordinary WAN.
The issue:
No matter how hard I try, the packets never routes back to Wireguard. If I send one ping (from another machine) the response will come from ISP 1 or ISP 2 (the other WAN's), but not from the external server's IP.
In other words, the packet comes from WG and leaves from WAN_1.
For some reason, the "WAN" interface (using Wireguard) doesn't have "reply-to" attached. I already have created some rules in the "Rules [new]", forcing to use Wireguard Gateway. I already try checking "Dynamic gateway policy" or creating another Gateway (using the interface), without success.
The packets are always leaking from another Gateway/WAN.
Anyone have any idea of how to force the same behaviour of WAN on Wireguard interfaces?
Quote from: inkeliz on Today at 07:27:42 AMIf I send one UDP/TCP/ICMP packet to 2001:my:isp:1111::4242 I get a reply from the same 2001:my:isp:1111::4242.
What does this even mean. You ping your own IP-addresses? This is not a valid test I would guess.
Quote from: Bob.Dig on Today at 10:42:07 AMQuote from: inkeliz on Today at 07:27:42 AMIf I send one UDP/TCP/ICMP packet to 2001:my:isp:1111::4242 I get a reply from the same 2001:my:isp:1111::4242.
What does this even mean. You ping your own IP-addresses? This is not a valid test I would guess.
That means that it works, because the reply is from the same IP of the target. If I send a ping to 1.1.1.1 I get a reply from 1.1.1.1.
The issue is: when you ping 1.1.1.1 and get a reply from 2.2.2.2 (because 2.2.2.2 is the other WAN). That happens because of multi-WAN, the output uses another WAN (2.2.2.2) instead of the right WAN (1.1.1.1).
I will clarify, I have the following interfaces:
- WAN_MEO (i.e 2111::/56)
- WAN_NOS (i.e 2222::/56)
- WAN_WIREGUARD (i.e 2333::/56)
I have one LAN:
- LAN (fdcc::/64)
I'm pinging from the internet (example: https://fra-de-ping.vultr.com):
2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2111::1234 (WAN_MEO) -> fdcc::1234 = Works
2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2222::1234 (WAN_NOS) -> fdcc::1234 = Works
2001:19f0:6c00:8002:5400:ff:fe00:536a -> 2333::1234 (WAN_WIREGUARD) -> fdcc::1234 = Fail
The Wireguard fails because the reply/response uses WAN_MEO or WAN_NOS instead of WAN_WIREGUARD.
Basically, you (in the internet) send ICMP to 2333::1234 and receives a ICMP reply from 2111::1234, of course it doesn't work. I can't find a way to force the exit to match the input. The "reply-to" works for WAN_NOS and WAN_MEO, but doesn't apply to WAN_WIREGUARD.
So you testing externally, ok. A network diagram could help, especially what is ULA and what is GUA.
None the less, WireGuard-interfaces don't have reply-to by default. You have to go in the firewall-rule on your WireGuard-interface, which allows the traffic, tick advanced mode and then set the reply-to to your gateway of choice: WireGuard.
You have a lot of other variables though, so good luck. :)
Quote from: Bob.Dig on Today at 11:33:10 AMYou have to go in the firewall-rule on your WireGuard-interface, which allows the traffic, tick advanced mode and then set the reply-to to your gateway of choice: WireGuard.
I didn't see the 'Advanced' toggle in `Rules [new]` dialog.
Editing each rule and adding Reply-To to 'WAN_WIREGUARD_GW' works. Thank you.