Hello all,
I hope you have a good day.
Kindly find the following scenario:
I have two PEPs
1- Main, IP forwarding, its IP: 1.1.1.1, additional IP: 3.3.3.3
2- Branch, NAT, its IP: 2.2.2.2
On the Branh device, remote peer IP in the VPN profile is the Main’s additional one “3.3.3.3”, yet it’s a public one and routable over internet.
After creating PEP profiles, the tunnel doesn’t start, it shows “Starting” for a while, then “Creating tunnels”, then returns to “Starting”.
After some investigations, such as Packet Capturing, I found out that during the handshake phase, Branch is negotiating with Main’s addition IP “3.3.3.3”, and it’s successfully done. When the Data phase starts, Branch doesn’t continue negotiating with “3.3.3.3”, instead it’s trying to establish the tunnel using Main’s primary IP “1.1.1.1” which is not routable over the internet because it’s a private one.
We tried the NAT mapping, it worked.
However, it’s not an optimal solution for our case.
The question is, is there any way to use the Main’s additional IP for establishing the tunnel? Or the tunnel should be established using the Main’s primary IP “1.1.1.1”?
Appreciate any help you can provide.
Caveat: I’m not an expert-expert, just someone who’s had a somewhat similar issue to you in the past. My first thought is that your VPN profile on the ‘main’ router should only have a priority listed for the 3.3.3.3 WAN connection; if the 1.1.1.1 one isn’t routable, there’s no reason to include it in the list of WAN connections to use for the VPN profile. If you have some reason to leave the 1.1.1.1 WAN in there, you could opt to set up separate tunnels for each WAN connection: in the VPN profile screen on the ‘main’ router, click the white-question-mark-in-a-blue-circle button to the right of the SpeedFusion VPN Profile title section, and click the option to create multiple tunnels for the profile. Once you do that, you can create a tunnel with only the 1.1.1.1 WAN endpoint selected, and a second tunnel with only the 3.3.3.3 WAN endpoint selected. You should then see both tunnels attempt to stand themselves up, and the 3.3.3.3 should establish, leaving the 1.1.1.1 tunnel at ‘Starting’… I think. 