Site to Site ipsec vpn in dual wan environment, fails to start on 2nd wan interface

https://community.sophos.com/products/unified-threat-management/f/vpn-site-to-site-and-remote-access/80314/ipsec-site-to-site-vpn-passes-no-traffic-after-updating-to-9-406-3

It seems that the issue i'm encountering is very similar to the above thread.

I contacted my isp on 25th sept 2017 regarding this issue, 

I think the closest update was

2017:09:22-23:16:44 mail auisys[19496]: id="371Z" severity="info" sys="system" sub="up2date" name="Successfully installed Up2Date package" status="success" action="install" package_version="9.25312" package="aptp"

in anycase, i got my isp to change the upstream routing on 20/11/2017 but i still cannot get things working.

cannot cope with %defaultroute!!!

That makes me think there's an issue with the PSK and the VPN ID.  What if you redo those?

I don't understand why you included the 2singtel Remote Gateway picture.  What happens if you use a full FQDN for Hostname in "RemoteGateway" or you choose 'VPN ID type: IP Address' and leave 'VPN ID' blank?

With debug activated, the log is too long to read further.  I've not seen an issue here in ten year that was resolved through using debug.  If you still haven't resolved this problem:

1. Confirm that Debug is not enabled.
2. Disable the IPsec Connection.
3. Start the IPsec Live Log and wait for it to begin to populate.
4. Enable the IPsec Connection.
5. Show us about 60 lines from enabling through the error.

Cheers - Bob

I've already tried rebuilding both links. here's the current setup using vpn id = ip address

initially the myrepublic connection was on eth5, but as a process of elimination i changed it to eth4 and rebuilt the interface. (also, its not dynamic, so its not the dhcp mtu bug i think)

you can see the 2singtel connection is up. 

remote gateway is common for both

the 1myrepublic ipsec connection. (note auto firewall rules are off but there are firewall rules to allow both wan and lan connections in both directions)

the 2singtel connection. the only difference between this one and the myrepublic connection is the local interface

here is the live log with all debug off. it never proceeds past that

if debugging is on.

there is no issue pinging or traceroute via eth4

--after remote session with sophos support--

This is a quick mail regarding what we have troubleshot during the remote session.

> We have already checked the ipsec configuration, it seems fine.

> You are not able to generate the ipsec tunnel from the Republic ip.

> We took the ssh of both the side and tried to initiate connection from the Singapore side to the china side.

Singapore IP: 103.224.165.xx
China ip: 180.168.60.xxx

> We grep the ipsec logs, but not able to get any thing.



> We have also grep the tcpdump with the source ip on port 500 and 4500, but not able to get any packet.



> We grep the tcpdump on singapore side.


> We are able to see the traffic is going out from the UTM but not reaching towards the remote side.

> We suggest you to please check with the ISP.

> You are able to telnet from the internal machine on port 500 and 4500.

> We informed you that when traffic is going out from the UTM it`s not reaching to the destination network so we can investigate further from our end.

Please check with your ISP by initiating the traffic of port 500 and 4500.

so basically initiating the ipsec connection on the router for myrepublic doesn't detect any packets at the remote router. yet i can initiate tcp packets on a pc behind the router 

just in case, because i don't know what those error -101 mean

Try looking at the traffic going through the tunnel, Chris.  First, you need the REF_ of the IPsec Connection:

cc get_object_by_name 'ipsec_connection' 'site_to_site' '1MyRepublic'|grep 'ref'

Assuming that that gives you REF_IpsSit1myrepublic, you can watch inside the tunnel with:

espdump -n --conn REF_IpsSit1myrepublic -vv

Do you learn anything from that?

Cheers - Bob

PS I wouldn't worry about those -101 errors.  I see them everywhere, so I just assumed it was a debugging switch that the developer forgot to turn off when they compiled the production module.