Site-to-Site VPN between UTM9 and Ubiquiti Unifi Security Gateway

ok I got the tunnel working. Connection is established.

But I can't access hosts in the foreign network.

Must I set a static route to the foreign network? 

In the Firewall are no entries to the vpn destination while I'm testing.

ok I got the tunnel working. Connection is established.

But I can't access hosts in the foreign network.

Must I set a static route to the foreign network? 

In the Firewall are no entries to the vpn destination while I'm testing.

Hallo Philipp and welcome to the UTM Community!

Please show a picture of the Edits of your IPsec Connection and your Remote Gateway.  Also, say if DPD and NAT-T are enabled on both sides.  Static Routing doesn't work inside an IPsec tunnel - it only works when the tunnel is bound to the interface.

Are you saying that the Firewall log doesn't show any lines where an IP in your BO LAN was blocked from reaching an IP in the HO LAN?

Do we know that the hosts in the HO have the other IPsec endpoint as their default gateway?

Cheers - Bob

Hi Bob, 

my UTM9 config:

Config Homeoffice (Ubiquiti USG3):

The VPN type is IPSec (not shown in the screenshots)

Both gateways are direct attached to the internet. Without NAT.

thanks in advance

Philipp

First some comments about how to build a configuration that fits better with the "culture" around this tool, Philipp.  Firewall rule #5 has no effect since WebAdmin builds that rule implicitly and the implicit rule is considered before your manual rule (see #2 in Rulz).  If you select 'Automatic firewall rules' in the IPsec Connection, rules #6 and #7 become likewise redundant.

Since you say you have an established connection, I assume the following questions are answered "yes" ...  We can't see if DPD and NAT-T are enabled on both sides - are they?  We can see the Phase 1 settings for the other side, but not the IKE SA and IPsec SA lifetimes - do those correspond to the Policy chosen in WebAdmin?

At the top of the other configuration, we see "! //192.168.178.178:8443" - what does that represent?  This makes me think that there's an error in the definition of the local subnet in the Ubiquiti.  If that's not it, do the following in the UTM:

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 any error or the end of the establishment of the tunnel.

Cheers - Bob

Hi Bob,

the IP shown in the black screenshots "192.168.178.178:8443" is the Controllersoftware of 
my Ubiquiti Security Gateway at my HomeOffice. 192.168.178.0/24 is my subnet at home.

Company subnet where the UTM9 is running: 192.168.2.0/24

I can't configure the  IKE SA and IPsec SA Lifetimes in my Unifi Security Gateway.
But they should be the ones which I configured in the UTM9

Thanks! 

Philipp

Live Log:

That log looks like everything is fine, Philipp.

I'm still concerned about the routes the UTM and the Ubiquity are building.  You said, "the IP shown in the black screenshots "192.168.178.178:8443" is the Controllersoftware of 
my Ubiquiti Security Gateway at my HomeOffice. 192.168.178.0/24 is my subnet at home."  Are you sure that the Ubiquity has 192.168.178.0/24?

Cheers - Bob

Hi Bob,

sure!

My subnet at home is 192.168.178.0/24
The Controllersoftware (Ubiquiti CloudKey) = 192.168.178.178

The Security Gateway LAN Port = 192.168.178.10
The Security Gateway WAN Port = 37.24.37.86

cheers

I still think the issue is in the Ubiquity because it complains "! //192.168.178.178:8443" at the top of both screens.  To completely rule out the UTM as the source of the problem, do #2 in Rulz.

Cheers - Bob

Hi Bob,

yesterday I've troubleshoot the issue with Ubiquiti Support and we've found the issue!

The Sophos does not support dynamic routing!

Turning dynamic routing off and traffic is being routet and everything works.

Disgusting...

So, this thread is solved!

cheers

Philipp

In fact, Philipp, the UTM does support OSPF, and it works well.  In this case, I agree that the simplest solution was to disable it on the Ubiquity for this connection.

Cheers - Bob