IKEv2 Site-to-Site and MultiWAN on one side
-
Well if you set one side to allow traffic from any IP address (0.0.0.0/0) then connections can only be established from the other end. That would be the multiwan end. You can set a tunnel to use a backup WAN specifically if you need to.
If you set a tunnel on a failover group it will always try to use the lowest tier WAN. That can be a different group so the VPN uses a different WAN than other traffic.
-
@stephenw10 said in IKEv2 Site-to-Site and MultiWAN on one side:
Well if you set one side to allow traffic from any IP address (0.0.0.0/0) then connections can only be established from the other end. That would be the multiwan end. You can set a tunnel to use a backup WAN specifically if you need to.
If you set a tunnel on a failover group it will always try to use the lowest tier WAN. That can be a different group so the VPN uses a different WAN than other traffic.
Even though I configure the backup WAN in the tunnel, it doesn't connect, I can only connect to the main WAN. I don't know if I'm forgetting some configuration.
I have 3 wans and some ipsec tunnels, I would like to balance these tunnels between the 3 wans, but I get stuck connecting them all to the main one.
-
If you're not using a gateway group on the multiwan end and the other side is connecting to one of the non-default WANs by IP that should connect fine.
How does it fail? What errors are shown?
-
@stephenw10 I use "gateway groups" with these wans, could that be the problem? Can't the wan belong to a gateway group?
-
The existence of a gateway group should not prevent other services being set to use a specific WAN even if it's in a group.
-
-
OK that looks like the other end is not seeing the replies for some reason.
Check the state table at both ends.
Which end are those logs from?
-
@stephenw10 This is the side that has the two wans.
-
Ok so it sees the incoming request on the correct WAN and replies but the other end never sees that reply because it just sends the initial request again.
So either that reply is not actually being sent or it's send incorrectly somehow. Or something in the route is blocking it.
I'd first check the state tables at each end. If that doesn't show something obvious then run a pcap at both ends to confirm replies are being sent and received.
-
-
OK so never makes it to the firewall state at the remote end.
Run pcaps and make sure it's leaving the multiwan end correctly.
-
You might also try just pinging between those sites using that WAN as source and see if it gets to the remote side as expected.
-
@stephenw10
I think I found the problem. I was using this configuration:
Because I used 0.0.0.0 in remote gateway.
After I switched to, it worked.
-
You should be able to use ASN at both ends as long as it all matches.
-
@stephenw10 With ASN, the tunnel only connects to the WAN with tier1.
I block the ping protocol on both WANs for external requests, could this affect the IPsec request?
-
Does that ASN resolve to the other WAN IP perhaps?
-
@stephenw10 I think so.
How do I test?
-
Just try to resolve it somewhere. In Diag > DNS Lookup in pfSense for example.
If you use an IP address or something actually resolves it must match the actual address IPSec is using.
