Network Extension via two UTMs

Are these two separately managed network?
Or shall it be centrally managed (DHCP, etc. only on one site)?

I'm just asking because if these are separately managed networks you will soon run into IP address conflicts. In that case a 1:1 NAT with transfer networks would be the way.

What did not work with the solution in the thread you mentioned?

I will be managing the extended network from one UTM only; for simplicity let's call it UTM A, with the remote as UTM B.

Before trying to span the same network, I attempted using two different networks with UTM A managing the network on UTM B with the following configurations:

UTM A eth1: 192.168.0.1/24 with DHCP, NAT for local clients
          reds1 (to UTM B): 192.168.10.1/24 with DHCP server
          FW rule allow 192.168.0.0/24 to 192.168.10.0/24
          
UTM B br0 (bridging eth1 and redc1): 192.168.10.2/24
          static route 192.168.0.0/24 via 192.168.10.1
          FW rule allow 192.168.10.0/24 to 192.168.0.0/24

I can ping from a client on UTM A (192.168.0.100) to br0 on UTM B (192.168.10.2) but not to a statically configured client (192.168.10.5) on UTM B. The UTM A reds1 (192.168.10.1) has the same pinging results.

Update:

I have bridged the internal interface on both UTMs (eth1 and redxX) and configured as follows:

UTM A: br0 192.168.0.1/24 with DHCP and masquerade  br0 network to eth0

UTM B: bro 192.168.0.2/24 
            DHCP relay from br0 network to 192.168.0.1

DHCP works well so I know the L2 tunnel is up but still unable to ping from the client on UTM B to the gateway (192.168.0.1) on UTM A. Am I missing a firewall rule somewhere? I have checked the logs with no luck.

You need te create firewall rules for all traffic that goes through the UTM, so in this case you would need something like:

192.168.0.0/24 -> 192.168.0.0/24 any allow

I added that rule for both UTMs just now and still no ping between clients on either end or from a client on UTM A to the br0 interface of UTB B. Maybe static routes are needed, though I don't see why as this is all one network?

Hi, goosen8r, and welcome to the User BB!

In a situation with two UTMs, my preferred solution is a RED tunnel between the two with a bridge on each end as in my coach story.  For more discussion that might help you, read Routing the same subnet accross vpn.

A correctly configured VPN should need no static routes, and they can't be used except for routing traffic that has left the tunnel.  Firewall rules are necessary to allow traffic to pass through a bridge.

Even with an "Any" Allow rule, pinging probably (haven't tried it) requires an allow rule on each side allowing pings from the other side - watch the Firewall Live Log.

Cheers - Bob

I read through that post and it seems I am attempting to accomplish the same thing, however it's not seeming as easy. I have tried watching the live firewall feed with the rules on and off and don't even see the host attempting a ping - or any other protocol I have sent across - tried SSH, FTP, HTTP, HTTPS, nothing shows up in the the logs.

I did SSH into the UTM and grab some packets caps, but all that shows up - and this may be helpful - is ARP requests for the hosts on the other side of the tunnel, but no replies. The host attempting communication is 192.168.0.100 on the UTM A side trying to reach 192.168.0.17 on the UTM B side. The UTM B br0 interface is 192.168.0.2 and is the only host responding to ARP requests, but I cannot communicate with it either. I did add 'ping' to the list of allowed services, which includes 'Any' as well.

To be more clear, what I DO see on the firewall of UTM B is this: 

192.168.0.100  :  60737 →  224.0.0.252  :  5355

but it seems any traffic bound for the local net does not hit the firewall or the br0 interface of the UTM (verified via packet captures from shell).

So it seems that since DHCP and multicast are passing that any broadcast traffic will pass, leading me to think that layer 2 is up, however attempting connections between hosts on either side is showing that it's not.

Please click on [Go Advanced] below and attach pictures of your firewall rule and of the RED definition on the server side open in Edit mode.

The only tool I've used to watch the actual packets is tcpdump, with an occasional packet cap that I've analyzed with Wireshark.

Cheers - Bob

Bob,

I have a Retina screen so screenshots are rather large and cannot be attached. I have posted them on my OwnCloud server here. Note that I haven't got around to having our IT department generate a proper SSL cert so you will get that beloved untrusted prompt.