Help with IPSEC behind Peplink 20

I installed a new Peplink 20 Friday replacing a Dlink consumer router. Everything works great, except a CISCO 5505 that worked fine behind the DLINK but has trouble with the Peplink. The 5505 sits on my home LAN and when powered up creates an IPSEC tunnel to my office. I then can use the 5505 LAN ports for a direct connection to the company LAN and more important I have an Ayava IP phone connected to a company PBX.

With the Peplink in place of the Dlink the 5505 completes Phase 1 of the IPSEC handshake, but never completes Phase 2. If you saw this post before I edited it you will see I thought I was able to connect with my laptop, but that was a mistake. If I put the DLINK back in place of the Peplink 20 the phone works again. There are no rules on the DLINK for the phone or the 5505. I am doing a power cycle on everything as I swap routers.

Does anyone have any ideas on what I can try to get the phone working again?

Here are my current settings to help:

Only WAN1 is hooked up so far
Outbound Policy = Normal Application Compatibility
Inbound Access Port Forwarding. Two rules that bring two TCP ports to cameras I have on the LAN, UPnP and NAT-PMP enabled. I tried playing with a rule to send all other traffic to the 5505, but no luck so it is gone.
No NAT mappings
Firewall Outbound Any Any Allowed
Firewall Inbound has 2 rules to allow the port forwarding to the cameras based on destination IP and port. I added a rule to send all traffic from the known WAN IP address on the company side of the 5505 connection to the LAN address of the 5505, but that didn’t help so it is gone. I also toggled between the default rule being allow vs deny and that didn’t matter.
Service Passthrough SIP=Standard, H.323=enable, FTP=enable, TFTP=enable and NAT-T=enable

I can offer a bug, and maybe a solution to your issue. It depends on the IPSEC particulars in use. The IPSec passthrough they say has its own hidden rule. It defaults the port 500 UDP part to WAN 1 always. If you have outbound rules they get ignored. But the port 4500 second part (because its NAT-T) of the IPSEC, does follow your rules, or at least the load sharing rules. This means the whole conversation is normally split over two WAN IP’s, and fails every time to connect.

For a test, Unplug WAN 2 and 3, forcing everything onto WAN 1 and see if it works.

Thanks. This will help in the future, but at this point I only have a service on WAN 1. Everything else is on order.

This seems to be working now. My IT group changed some voice settings.

Excellent - thanks for the update.