UTM to UTM Red problem access web interfaces of devices on other end

Hi, Ralph, and welcome to the UTM Community!

What insights do you get from doing #1 in Rulz?

Cheers - Bob

Yes, I looked at the logs.  I did see that a default drop was happening between the red virtual interface on the remote end of the tunnel and the web enabled device I was trying to reach on port 80.

In my firewall rules I have an any-any rule with both LANs in the both the source and destination boxes.  This is per the instructions cited in my original post.  With these settings I can ping, tracert, remote desktop, vnc, etc. between the two networks, it is just traffic on ports 80 and 443 that seem to be dropped.

I can add the red network (in which the virtual red interfaces reside) into the any-any rules on the UTMs, and that does work. Since every other protocol work OK, and this step is not mentioned in the instructions for setting up UTM to UTM Red tunnels, it seems like this shouldn’t be required.

Is http traffic treated differently by the UTM?  I’d like to understand what the reason is for dropping that specific traffic.

Post the line from the Firewall log file that corresponds to the drop you saw in the Live Log.  Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.

Cheers - Bob

Sorry for letting this slide for several days - we are setting up a new office and it's been kind of busy.

So I still have a question about this, as I would have thought with a UTM to UTM red tunnel, with an Any - Any rule between the internal networks on both ends that no traffic would be dropped between devices on either end of the tunnel.  I am finding that this isn't the case - unless of course I have an error in the configuration.

192.168.71.1 is the Red interface on the Main Office Sophos device, 

192.168.70.202 is the MFP device at the branch office

192.168.71.1 is the Red interface on the Branch office Sophos Device

Here is the live log entry of a failed attemt to open the web interface of a MFP device in a branch office from a PC in the main office:

07:19:37 Default DROP TCP 192.168.71.1:33326 → 192.168.70.202:80 [SYN]len=60 ttl=63 tos=0x00 srcmac=00:93:39:17:93:27 dstmac=00:ec:cb:c8:7e:4b

Here is Firewall log entry for the same event:

2017:06:01-07:19:37 utm-broadway ulogd[4646]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="redc3" outitf="eth0" srcmac="00:93:39:17:93:27" dstmac="00:ec:cb:c8:7e:4b" srcip="192.168.71.1" dstip="192.168.70.202" proto="6" length="60" tos="0x00" prec="0x00" ttl="63" srcport="33326" dstport="80" tcpflags="SYN" 

These are the two rules on the Sophos UTM at the remote site that are involved:

Rule 5 is what the Sophos documentation says is all that's needed to set up the Red tunnel.

If I turn on Rule 5 and turn off rule 6, a lot of packets are dropped between sites, anything on ports 80 and 443, as well as traffic generated by DFSR and our event manager application that I have noticed.

If I tun off rule 5 and turn on rule 6, which adds the Red interface on the device to both sides of the rule, everything works.

Obviously I can just leave the rules like this and forget about it, but it seems something must be wrong since this is not how Sophos recommends configuring this tunnel.

Thanks.

It looks like you've set a default gateway on the RED interface and that traffic captured by Web Filtering (in Transparent mode?) is being sent from "RED INT to JCC (Address)" instead of appearing to come from a device on the internal network.

You can get rid of the default gateway or add "JCCLAN" to the Transparent mode Skiplist.  Or you probably can just add "RED INT to JCC (Address)" to the sources in #5.

Cheers - Bob
PS Great post by the way.  You anticipated my questions.

Thanks for posting a reply.  I did take a look and there is no default gateway on the red interface on either device.  

Adding the interface "RED INT to JCC (Address)" to the sources in #5 did not work, but if I also add the Red interface on the main office it does work, so it seems it needs both.

Similarly, if I remove the interfaces from the firewall rule, and then add "JCCLAN" to the Transparent Mode Skiplist for web filtering it does not work, but if I also add the "Internal (Network)" to the Skiplist then with both networks present things do work.

What I have found it the easiest way to make this all work is in the Firewall rule that allows Any-Any between the internal networks involved in a Red tunnel, to add the associated network that the virtual red interfaces are in to both the sources and destinations, and do this on both devices.

Still not sure why this is necessary.

Well, I don't do these every day, but I don't understand how the IPs of the respective RED tunnel endpoints became the destination in packets between the two UTMs.  I'm obviously not asking the right question...

Cheers - Bob

Well, I don't do these every day, but I don't understand how the IPs of the respective RED tunnel endpoints became the destination in packets between the two UTMs.  I'm obviously not asking the right question...

Cheers - Bob