Sophos UTM - IPv4/IPv6 Issue - IPSec

Hi guys,

I have searched myself silly and dont get anywhere, so I come before you.

 

A little preface:

We are a small group of companies (headquarter/main company and 2 daughtercompanies/branches). There are 2 IPSec Site-2-Site tunnels established between the two branches and the headquarter (we, the HQ, are on respond since the branches dont have static IP's yet) - they work on a RDS/Terminalserver in our infrastructure.

We have just the worst WAN connection (Vodafone cable) - atrocious. Its on and off again - major disruptions etc. We are so remote that we dont have any alternatives like fiber (the DSL connection is solely for our VPN connection to the hosted cloud VoIP PBX of Deutsche Telekom), so we are stuck with Vodafone. It wasnt always as bad as now, but I have to provide redundancies now since 3 companies are affected.

I asked our mobile provider for a data plan and they can offer me a LTE data plan with a static, public IPv6 address. According to the sales rep I spoke to, it will allow incoming connections as well, but I need to verify with one of their technicians directly - lets assume it is.


I planned something like this:

 

I really dont want to establish a full blown IPv6 network in parallel to the IPv4. I saw here and there some blog posts and comments on the net (and Sophos forum) explaining the translation of IPv6 traffic to IPv4 and vice versa. 

How would I realise that on the UTM? With a DNAT rule?

Im eternally grateful for any input.

Thanks!

Parents
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

  • 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?

    Mit freundlichem Gruß, Regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

  • 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!

    Mit freundlichem Gruß, Regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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

  • I read right past the key log line last week, Constantin.  The error occurs immediately after initiate Main Mode.

    That tells me that the IP address on LTE_Backup is not the same as the one on the public interface of the Mikrotik.

    Try the following:

    1. In both branches, change the 'VPN ID type' to "IP address" and leave the 'VPN ID (optional)' empty.
    2. In the HQ, change the 'VPN ID type' to "IP address" and set the 'VPN ID (optional)' to the IP on the LTE_Backup interface.

    Any better luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • I read right past the key log line last week, Constantin.  The error occurs immediately after initiate Main Mode.

    That tells me that the IP address on LTE_Backup is not the same as the one on the public interface of the Mikrotik.

    Try the following:

    1. In both branches, change the 'VPN ID type' to "IP address" and leave the 'VPN ID (optional)' empty.
    2. In the HQ, change the 'VPN ID type' to "IP address" and set the 'VPN ID (optional)' to the IP on the LTE_Backup interface.

    Any better luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • Hey Bob,

    sorry for the delay. The guy in the branch office went on holiday and turned his computer off. Phantastic. Drove there last night and turned it on again. Anyway, I was under the impression that the Mikrotik antenna would just "forward" the received public IP address when in passthrough mode.

    When I try to set the IP in the HQ I get the following message:

     

    Thanks and best regards,

    Constantin

  • Probably not related, but wanted to update the running configuration so we are all on the same page at all times.

    It bugged me, that I couldnt get the tunnel with RSA running, so I played around with the settings. When I changed this setting to IP Address instead of hostname:

    and here to:

     The tunnel was finally established:

     

    I know its not relevant, but I wanted to keep the thread up2date.

    Best regards,

    Constantin

  • Hey Bob,

    just to definitely rule out firewall drops, I logged the automatic rule for the IPSec tunnel, but alas no luck, i.e. no ICMP drops in the log. I looked at another protocol and tried nslookup for a change:

     

    09:48:15.514701 IP6 (hlim 64, next-header ESP (50) payload length: 104) 2003:a:XXXXXXXXXXXXXXXXX > 2a01:598:XXXXXXXXXXXXXXX: ESP(spi=0xc73de4ae,seq=0x5), length 104: IP (tos 0x0, ttl 127, id 51386, offset 0, flags [none], proto UDP (17), length 68)
    10.2.1.15.60868 > 10.1.4.13.53: [udp sum ok] 1+ PTR? 13.4.1.10.in-addr.arpa. (40)

    I checked the firewall logs at branch office and I saw:

    09:50:06 Auto-generated rule #2 UDP  
    10.2.1.15 : 57798
    10.1.4.13 : 53
     
    len=75 ttl=127 tos=0x00 srcmac=90:1b:0e:39:5a:c0 dstmac=7c:5a:1c:69:4e:a0

    This is just bizarre. Any other ideas?

     

    Thanks and best regards,

    Constantin

  • Well, Constantin, if the packet capture shows the request packet going through the tunnel, but doesn't show the response packet returning through the tunnel, the only thing left is the firewall settings on the device you're trying to ping - ni't?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    sure, but the exact same pinging action works through the usual IPv4 IPSec tunnel, which was also created with automatic firewall rules and routing. 

    Phew, I have no idea what else I could do... I guess that means the project failed.

    Thanks anyway for your time and effort!

     

    Best regards,

    Constantin

  • @ Constantin

    Sorry to hear about your problem. Hope that I can help looking into a bit if it is not too late

  • Hello Duc,

    thanks for the reply - I would be grateful for any further suggestions how I can tackle this. The "damage is done" you might say (about 177 bucks for that Mikrotik antenna - of course it could be put to other use), but it still bugs me that it would not work, even though it should!

    Thanks and best regards,

    Constantin

  • Hi Constantin,

    You are right, it should work.

    Sure I can give a good try (quite busy at the moment); but no guarantee that I will find anything useful.

    Anyway, Can we take this conversation private?

    Thx