Nick Howitt wrote:

Your traceroutes are completely wrong as nothing is going through the tunnel. You should not see any hops between the IPsec endpoints. If you want to check the tunnel working you should be doing a traceroute to the remote ClearOS LAN IP directly, From A do a traceroute to rightsourceip=192.168.10.1 or any non-Windows device on the remote LAN. The problem with Windows is its firewall, where it may reject pings and other connections from outside its own LAN. You would need to check its settings.

That's likely because I did external interface to external interface. Doing internal to internal looks like this:

Firewall up and down are identical in this case (site A to site B, from 192.168.3.1 internal LAN):


Doing the reverse also works identical with firewall up or down (site B to site A, from 192.168.10.1 internal LAN)



These are both router to router trace routes, so the tunnel is up and the two end points are responding. Going onto a client at site A and doing a trace route to a known good running machine at site B gets me this:



However I cannot access any services on that machine (192.168.10.5) through the tunnel - the firewall appears to be blocking all of them.

If I do the inverse and trace route a machine on site A from a machine on site B I get the following:



In both cases, the firewall being on/off has no impact to the trace route results. But I can't actually access any services on any machines on the opposite side of the tunnel.

As soon as I turn off the firewall at both sites, my tunnel works as expected, but now my NAT/forwarding doesn't work at either site (which is expected). So there is a config in iptables that is taking precedent over the tunnel and blocking communications. At this point that is pretty clear because when it is removed from the equation everything works. What I can't figure out is what that setting is or what it is happening the way it is.

Nick Howitt wrote:
Similarly if you want to access a web server at B from A, the FQDN at A should resolve to a LAN IP at B and vice versa. This is achieved through the DNS Server settings (or the hosts file)

It isn't a DNS issue. As I said earlier, completely eliminating DNS 100% from all configs and using only IPs results in the exact same behavior under the same tests. That said, I have full working forward/reverse DNS at both sites for the LANs.