Sophos UTM - IPv4/IPv6 Issue - IPSec

Hallo and welcome to the UTM Community!

I'm not familiar with the Mikrotik - can it do IPv6-to-IPv4?  Do you have UTMs in the branches, or are these other brands?

Cheers - Bob

Hi Bob!

Thanks for the reply - almost lost hope :)

Sorry, should have been more clear on that:

Main office: SG135 UTM

Branch1: SG125 UTM

Branch2: SG115 UTM

The Mikrotik antenna has the so called "routerOS", but I activated the passthrough mode (similar to the bridge mode on a router), so the Mikrotik only uses the built-in LTE modem to forward the public IP - this has been tested and confirmed by me.

Thanks and best regards

Constantin

What happens if you de-select 'Bind tunnel to interface' in the headquarters IPsec Connection definition?  Selecting that requires you to provide routing manually.  That should only be necessary if you want to have both tunnels established by following the Tutorial [DE] that I linked to above.

Ich drucke mir die Daumen, Constantin !

Cheers - Bob

Hey Bob,

this is strange - I didnt get any notification that you replied, otherwise I would have answered asap. Since this has grown into a full blown obsession, I played around with all the settings on the weekend and...

Now comes the strange part - this only works with the following conditions:

Branch1 -      Initiate
Branch1 -      PresharedKey
Branch1 -      VPN ID type / IP Address

HQ - Respond 
HQ - PresharedKey
HQ - VPN ID Type / IP Address

Any other constellation (RSA key, switched initiate/respond, VPN ID type hostname) will not work.

While Im SO relieved that the sales rep wasnt lying (:D) and it is working, Im a little confused why it works only with the aforementioned settings. Dont get me wrong - Im glad it does, but I would rather use RSA than PSK.

Im also observing the subnets taking an usual long time to establish. I suspect the LTE connection (the antenna is inside my office, as mentioned before) - quick ping test from UTM to UTM:

5 packets transmitted, 2 received, 60% packet loss, time 4022ms

While the connection itself is established (why only this way needs to be investigated further by me, but that can wait a little), I cant ping through the tunnel. Two questions for you Bob:

- How can I streamline the performance of the tunnel? Adjusting MTU etc.?
- Could performance of the tunnel be so bad that I dont get anywhere with Ping tests through the tunnel (If I do tracert from both sides, there is only timeout after the first gateway.)? Im still afraid I have to deploy some kind of routing here, since Branch1 is a dualstack DSL etc. - I have no idea.

Thanks and best regards,

Constantin

Almost there, Constantin...

Do you have 'Support path MTU discovery' selected in the 'Advanced' section of the Remote Gateways?  Are pings then faster?

I'm glad you found a combination to make it work.  Is either UTM behind a NATting router?

Cheers - Bob

Hi Constantin,

just curious: why do you use LTE on both ends?

Hey Bob.

No, before I started to the deploy the tunnels etc. I went to Branch1 and put their Zyxel 5501 into Bridgemode, letting the UTM PPPoE connect. On our side is the Mikrotik LHG LTE6 antenna also in bridgemode, which gives eth7 ("LTE_Backup" interface) the IPv6 address through DHCP.

The MTU discovery feature was not activated on both ends - I will test today and post my results.

@Philipp

Hi. The LTE connection is only on our side as a backup, if and when that damn Vodafone cable connection fails again. On the branch side we have a regular DSL (dualstack) connection.

Best regards,

Constantin

Hey Bob,

I activated the Path MTU Discovery on the Remote Gateways in both UTMs. It did not help at all. When the IPv6 tunnel is up, no pings are going through - I just get timeouts. I thought it might be something with the packetfilter, but the automatic firewall rules are activated on both sides. I did create the IPv6 tunnel the same way than its IPv4 counterpart and the working RDP connection is proof that there is nothing in the way.

How could I zero in on this problem? Do we have to tcpdump on eth7? Im not sure what else I could check. 

Thanks and best regards,

Constantin

Hint: maybe it would be much more simple/reliable when not using LTE on BOTH ends?

What was the reason for doing it like this?

Hi Philipp,

did you not read my earlier reply? Only on our end (headquarters) is the LTE antenna. In Branch1 one is, as I said before, a regular DSL connection.

Best regards,

Constantin

OK - I see!

Did you check the firewall log, Constantin, to see if pings are blocked there?  If they are, see #2 in Rulz (last updated 2019-04-17).

Cheers - Bob

Did you check the firewall log, Constantin, to see if pings are blocked there?  If they are, see #2 in Rulz (last updated 2019-04-17).

Cheers - Bob

Hey Bob,

I observed on both sides the Live Log of the firewall and there are no drops of any kind when I try to ping (I also turned off IPS and ATP), only timout:

Not sure what else we could do. Can we listen "inside" the tunnel with tcpdump? So we know that the ping at least went into the tunnel?

Thanks and best regards,

Constantin

First, we need the REF_ of the tunnel.  If "Branch 1" is the name of the IPsec Connection, which we can find with:

cc get_object_by_name ipsec_connection site_to_site 'Branch 1'|grep \'ref

That will return something like REF_IpsSitBranch1.

To watch the traffic in the tunnel:

espdump -n --conn REF_IpsSitBranch1 -vv

Cheers - Bob

Hey Bob,

now Im really confused. The ping clearly goes into the tunnel and is even noticed on the other side.

Branch1:

HQ:

Not sure what else to do here. I checked all the logs - firewall, IPS, ATP - in the end I turned off intrusion prevenion and atp but that didnt help in any way.

Do you have another approach?

Thanks and best regards,

Constantin