IPSec site to site tunneling not able to see computers on remote side

After making another attempt at RDP, I have grabbed a screenshot of the threats on the Dashboard

Opening the Firewall log, a search for 192.168.38.250 shows no entry for that action.

I have looked through Rules 3/3.1 and I can't see anything that would apply to me: don't have 2-NICs on same subnet, have not added any interfaces, as there is only the single WAN and single LAN interface enabled.

The request just seems to go into the ether .. bad joke.

So, are we down to the firewall on the server you're trying to reach?

Cheers - Bob

It seems that way.

So just to confirm:

Site-to-Site IPsec SAs established with settings as shown from office network to services network

RDP connection attempt from office to services network fails

While still site-to-site connected, connect to services network using the Sophos SSL VPN client.

RDP connection to services server is successful.

Disconnect SSL VPN client causes the RDP session to fail.

So how do the routing values change between the 2 connections?

I had been using the SSL client as the primary connection in the past and had always been able to RDP connect to desired computers on the services network.

Thanks again for following up on this.

Cheers,

So I can ping the computer that I am trying to reach from the Initiator side but I cannot reach the computers from the Responder side. I did not think it was necessary to specify a service for the network - as I mentioned, the SSL works without any additional service definitions.

Is that how the connection should work or should the connection be seamless (that is how I expected it once the connection is established)?

So I have 2 home office connections, 1 fixed IP and 1 DHCP connection to my provider.

My frustrating tests have all been attempts to test the site to site connection between these 2 connections, which is still failing.

Using the same UTM routers, I have successfully made a site to site connection between my fixed IP UTM router and an associates fixed IP UTM router.

No additional changes were made to my end of the settings. I am able to RDP to their server and everything is as it is expected to be.

Question - why the difference? Should the UTM realize that one end of the connection is an IP address that was DHCP generated and treat it differently than if the IP address was fixed? Why would it need to know and why would it treat it differently?

Or is this totally not related?

Again, I suspect the firewall in the server you're unable to RDP into.  It evidently blocks traffic not from its subnet or the "VPN Pool (SSL)" subnet.

Cheers - Bob

Does it make sense that the router that is letting me make an RDP connection out would at the same time block coming in? I believe all my firewall rules are symmetrical to the service that they are allowing.

So I just SSL client logged onto my associates network which has the site to site connection to my network that I am trying to connect to.

I RDP'd to a computer on the network and opened an RDP to my server that I had been trying to connect to and it worked.

Current desktop (local) --> Sophos SSL VPN Client --> Associate site 1 <-site to site--> Local remote site 2 --> Remote server

The only difference thus far has been the external DHCP IP on my local network.

I logged in directly to the system on the network here and am still able to RDP to the remote system on my associates network connected only by the site-to-site connection.

So I thought I would close out this thread at this time.

I did solve the problem with the network behind the router that did not seem to be working with the site-to-site IPsec.

In the end, it was a routing issue and not the firewall.

A while back, we had a problem with wiring and had to re-route the gateway to a temporary secondary router and the DHCP parameters were still set to the alternate gateway. After I hard coded the UTM gateway to the system, I was able to RDP out to another site.

Thanks for your patience and assistance. Sorry it was a bit of a goose chase for everyone.

Cheers