Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 31 replies
  • Subscribers 7 subscribers
  • Views 9911 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos UTM - IPv4/IPv6 Issue - IPSec

Sophos User438

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!



This thread was automatically locked due to age.
Parents
  • 0

    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
  • 0 in reply to BAlfson

    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

  • 0 in reply to Sophos User438

    I don't think IPv6<-->4 translation is needed, Constantin, but I would be interested in learning what your test shows.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

    sure, no problem. I will post my results here - I just hate it if people ask stuff in the forums and never follow up on their discoveries to enlighten all the people (like you) involved. Friday I will drive to Branch1 and put their Zyxel Speedlink 5501 in Bridgemode (I ordered a static IP a few minutes ago).

    The problems I described above seem trivial now, since I have been told this morning that the data plan with static IPv6, "Deutsche Telekom" offered me is not able to activate the "DayFlat Unlimited" for unlimited traffic. The plan has "higher levels", but they only provide 15GB + 5GB, which is definitely not enough for us, since that crappy Vodafone connection sometimes goes offline for several DAYS, if you can believe it.

    My last option now is a big phone plan with unlimited traffic, so it wouldnt be necessary to activate DayFlat Unlimited, and then put the static IPv6 on that plan. Its expensive, but I will suggest to the boss that we split it 3 ways, since the whole group is using it, more or less.

     

    Best regards,

    Constantin

  • 0 in reply to BAlfson

    Hi Bob,

    I'm back - setting up the IPv6 stuff not as easy as I thought :) But that was more my fault than anything else. For anyone interested - if you plan something similar and you are using a Mikrotik device with routerOS and an R11e LTE modem - dont forget under "Interfaces -> LTE -> APN Profiles" to switch the protocol in the APN profile to IPv6 - that was my mistake. Disable "GSM" in the "lte1" interface as well.

    And when you are in there, you can comfortably activate the passthrough mode (if you still want to reach the GUI, you need to set up at least one VLAN interface since you only have on RJ45 port - passthrough/bridge lte1 to that vlan interface).

    Activating the IPv6 functionality on that SIM card worked, but they provide a whole /64 prefix, not just an address. Anyway - I have now on one side (Branch1) a dualstack DSL connection with static IPs (IPv4 and 6) and on our side a Mikrotik LHG LTE6 in passthrough mode, which is directly connected to eth7 on the UTM. The eth7 gets directly the IPv6 address, under "IPv6" I can see that the UTM detected "Native over LTE_Backup: 2a01:598:XXXX:XXXX:XXXX:XXXX:XXXX".

    Latency is a bit high, but to be fair, I have the antenna inside here in my office. IPv6 ping test from a 3rd party website can ping both the IPv6 WAN address of Branch1 and the eth7 on our Sophos. I can ping via UTM->Support-> Tools-> Ping check -> IP Version 6/Ping over Interface "LTE Backup" directly onto the UTM of Branch1. I guess its safe to say that connectivity is provided.

     

    Ok - lets get to it. I created new IPSec configurations in both UTMs - in Branch1 I set the mode to respond to make things easier.

    In our UTM I set them up as usual or almost the same as the IPv4 counterparts, except of course the gateway in which I put a new host definition as IPv6 address (the WAN interface of Branch1). And I bound the tunnel to the "LTE Backup" interface, so it would use the IPv6 connection. So far so good. When I start up the tunnel, it doesnt connect though.

    If you want I can post the whole live log Im getting, but I think I saw something in the log that is important:

     

    ERROR: "S_KH-IP6-Test" #36: sendto on eth7 to 2003:a:17f:XXXX:XXXX:XXXX:6618:855b:500 failed in main_outI1. Errno 1: Operation not permitted

    and

    ipsec_starter[4197]: no default route - cannot cope with %defaultroute!!!

     

    What could that be? I searched a little myself, but the people in threads I found were all talking about bugs in the UTM firmware...

    Any input is appreciated!

     

    Thanks and best regards,

    Constantin

  • 0 in reply to Sophos User438

    We're getting closer, Constantin...

    If either endpoint is behind a NAT, that could cause the problem.  If not, we need a new extract from the IPsec log.  Do the following:

    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 the error.  Or through the line containing "IPsec SA established."

    Also, please show pictures of the Edits of the IPsec Connection and Remote Gateway for both sides.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hey Bob,

    thanks for the reply. Bob you are scaring me with the NAT idea :). I specifically asked the sales rep that he forwards my question, if they allow IPSec connections through their LTE network, to their technicians and they confirmed. If there is something in the way from their side, Im going to be extremely disappointed.

    I gathered everything you wanted. I deactivated the other IPSec tunnels as well and purged the logs. Then I started up the IPv6 tunnel for clean results. But first the configurations:

     

    Branch Office:

     

     

    Headquarters:

     

    Log from Branch 1:

     

    2020:07:18-09:34:57 fw pluto[10315]: shutting down
2020:07:18-09:34:57 fw pluto[10315]: forgetting secrets
2020:07:18-09:34:57 fw pluto[10315]: "S_REF_IpsSitSim_3": deleting connection
2020:07:18-09:34:57 fw pluto[10315]: "S_REF_IpsSitSim_2": deleting connection
2020:07:18-09:34:57 fw pluto[10315]: "S_REF_IpsSitSim_1": deleting connection
2020:07:18-09:34:57 fw pluto[10315]: "S_REF_IpsSitSim_0": deleting connection
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface lo/lo ::1
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface ppp0/ppp0 2003:a:17f:XXXXXXX:855b
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface lo/lo 127.0.0.1
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface lo/lo 127.0.0.1
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface eth3/eth3 10.2.2.254
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface eth3/eth3 10.2.2.254
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface eth0/eth0 10.2.1.254
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface eth0/eth0 10.2.1.254
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface ppp0/ppp0 XXX.XXX.XXX.148
2020:07:18-09:34:57 fw pluto[10315]: shutting down interface ppp0/ppp0 XXX.XXX.XXX.148
2020:07:18-09:34:57 fw ipsec_starter[10308]: pluto stopped after 20 ms
2020:07:18-09:34:57 fw ipsec_starter[10308]: ipsec starter stopped
2020:07:18-09:52:54 fw ipsec_starter[16478]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
2020:07:18-09:52:54 fw pluto[16491]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
2020:07:18-09:52:54 fw ipsec_starter[16484]: pluto (16491) started after 20 ms
2020:07:18-09:52:54 fw pluto[16491]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve 
2020:07:18-09:52:54 fw pluto[16491]:   including NAT-Traversal patch (Version 0.6c)
2020:07:18-09:52:54 fw pluto[16491]: Using Linux 2.6 IPsec interface code
2020:07:18-09:52:54 fw pluto[16491]: loading ca certificates from '/etc/ipsec.d/cacerts'
2020:07:18-09:52:54 fw pluto[16491]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaSigVpnSigniCa.pem'
2020:07:18-09:52:54 fw pluto[16491]: loading aa certificates from '/etc/ipsec.d/aacerts'
2020:07:18-09:52:54 fw pluto[16491]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2020:07:18-09:52:54 fw pluto[16491]: Changing to directory '/etc/ipsec.d/crls'
2020:07:18-09:52:54 fw pluto[16491]: loading attribute certificates from '/etc/ipsec.d/acerts'
2020:07:18-09:52:54 fw pluto[16491]: adding interface ppp0/ppp0 XXX.XXX.XXX.148:500
2020:07:18-09:52:54 fw pluto[16491]: adding interface ppp0/ppp0 XXX.XXX.XXX.148:4500
2020:07:18-09:52:54 fw pluto[16491]: adding interface eth0/eth0 10.2.1.254:500
2020:07:18-09:52:54 fw pluto[16491]: adding interface eth0/eth0 10.2.1.254:4500
2020:07:18-09:52:54 fw pluto[16491]: adding interface eth3/eth3 10.2.2.254:500
2020:07:18-09:52:54 fw pluto[16491]: adding interface eth3/eth3 10.2.2.254:4500
2020:07:18-09:52:54 fw pluto[16491]: adding interface lo/lo 127.0.0.1:500
2020:07:18-09:52:54 fw pluto[16491]: adding interface lo/lo 127.0.0.1:4500
2020:07:18-09:52:54 fw pluto[16491]: adding interface ppp0/ppp0 2003:a:17fXXXXXXXXXXXXX:855b:500
2020:07:18-09:52:54 fw pluto[16491]: adding interface lo/lo ::1:500
2020:07:18-09:52:54 fw pluto[16491]: loading secrets from "/etc/ipsec.secrets"
2020:07:18-09:52:54 fw pluto[16491]: listening for IKE messages
2020:07:18-09:52:54 fw pluto[16491]: added connection description "S_REF_IpsSitSim6_0"
2020:07:18-09:52:54 fw pluto[16491]: added connection description "S_REF_IpsSitSim6_1"
2020:07:18-09:52:54 fw pluto[16491]: added connection description "S_REF_IpsSitSim6_2"
2020:07:18-09:52:54 fw pluto[16491]: added connection description "S_REF_IpsSitSim6_3"

     

    Logs Headquarters:

    2020:07:18-09:52:57 fw-2 ipsec_starter[9373]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
2020:07:18-09:52:57 fw-2 pluto[9386]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
2020:07:18-09:52:57 fw-2 ipsec_starter[9379]: pluto (9386) started after 20 ms
2020:07:18-09:52:57 fw-1 ipsec_starter[20927]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
2020:07:18-09:52:57 fw-1 ipsec_starter[20927]: no default route - cannot cope with %defaultroute!!!
2020:07:18-09:52:57 fw-1 pluto[20940]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
2020:07:18-09:52:57 fw-1 ipsec_starter[20933]: pluto (20940) started after 20 ms
2020:07:18-09:52:58 fw-2 pluto[9386]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve 
2020:07:18-09:52:58 fw-2 pluto[9386]:   including NAT-Traversal patch (Version 0.6c)
2020:07:18-09:52:58 fw-2 pluto[9386]: Using Linux 2.6 IPsec interface code
2020:07:18-09:52:58 fw-1 pluto[20940]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve 
2020:07:18-09:52:58 fw-1 pluto[20940]:   including NAT-Traversal patch (Version 0.6c)
2020:07:18-09:52:58 fw-1 pluto[20940]: Using Linux 2.6 IPsec interface code
2020:07:18-09:52:58 fw-2 pluto[9386]: HA system enabled and listening on interface eth6
2020:07:18-09:52:58 fw-2 pluto[9386]: Initial HA switch to master mode
2020:07:18-09:52:58 fw-2 pluto[9386]: loading ca certificates from '/etc/ipsec.d/cacerts'
2020:07:18-09:52:58 fw-2 pluto[9386]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu.pem'
2020:07:18-09:52:58 fw-2 pluto[9386]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu2.pem'
2020:07:18-09:52:58 fw-2 pluto[9386]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaSigVpnSigniCa.pem'
2020:07:18-09:52:58 fw-2 pluto[9386]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerNextcVerifCa.pem'
2020:07:18-09:52:58 fw-2 pluto[9386]: loading aa certificates from '/etc/ipsec.d/aacerts'
2020:07:18-09:52:58 fw-2 pluto[9386]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2020:07:18-09:52:58 fw-2 pluto[9386]: Changing to directory '/etc/ipsec.d/crls'
2020:07:18-09:52:58 fw-2 pluto[9386]: loading attribute certificates from '/etc/ipsec.d/acerts'
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface tun0/tun0 10.1.16.1:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface tun0/tun0 10.1.16.1:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.112/lag0.112 10.1.12.1:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.112/lag0.112 10.1.12.1:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.114/lag0.114 10.1.14.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.114/lag0.114 10.1.14.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.113/lag0.113 10.1.13.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.113/lag0.113 10.1.13.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.102/lag0.102 10.1.2.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.102/lag0.102 10.1.2.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.105/lag0.105 10.1.5.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.105/lag0.105 10.1.5.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.104/lag0.104 10.1.4.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.104/lag0.104 10.1.4.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.106/lag0.106 10.1.6.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.106/lag0.106 10.1.6.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.103/lag0.103 10.1.3.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.103/lag0.103 10.1.3.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.110/lag0.110 10.1.10.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.110/lag0.110 10.1.10.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.111/lag0.111 10.1.11.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.111/lag0.111 10.1.11.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.140/lag0.140 192.168.40.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.140/lag0.140 192.168.40.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.101/lag0.101 10.1.1.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0.101/lag0.101 10.1.1.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0/lag0 10.1.99.254:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lag0/lag0 10.1.99.254:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth6/eth6 198.19.250.2:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth6/eth6 198.19.250.2:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth5/eth5 10.1.21.1:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth5/eth5 10.1.21.1:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth4/eth4 XXX.XXX.XXX.57:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth4/eth4 XXX.XXX.XXX.57:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lo/lo 127.0.0.1:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lo/lo 127.0.0.1:4500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface eth7/eth7 2a01:598:XXXXXXXXXXXXXXf0:4007:500
2020:07:18-09:52:58 fw-2 pluto[9386]: adding interface lo/lo ::1:500
2020:07:18-09:52:58 fw-2 pluto[9386]: loading secrets from "/etc/ipsec.secrets"
2020:07:18-09:52:58 fw-2 pluto[9386]: listening for IKE messages
2020:07:18-09:52:58 fw-2 pluto[9386]: added connection description "S_REF_IpsSitKh6_0"
2020:07:18-09:52:58 fw-2 pluto[9386]: "S_REF_IpsSitKh6_0" #1: initiating Main Mode
2020:07:18-09:52:58 fw-2 pluto[9386]: ERROR: "S_REF_IpsSitKh6_0" #1: sendto on eth7 to 2003:a:17f:XXXXXXXXXXXXX:855b:500 failed in main_outI1. Errno 1: Operation not permitted
2020:07:18-09:52:58 fw-2 pluto[9386]: added connection description "S_REF_IpsSitKh6_1"
2020:07:18-09:52:58 fw-2 pluto[9386]: added connection description "S_REF_IpsSitKh6_2"
2020:07:18-09:52:58 fw-2 pluto[9386]: added connection description "S_REF_IpsSitKh6_3"
2020:07:18-09:52:58 fw-2 pluto[9386]: HA System: pluto already is in master mode
2020:07:18-09:52:58 fw-1 pluto[20940]: HA system enabled and listening on interface eth6
2020:07:18-09:52:58 fw-1 pluto[20940]: loading ca certificates from '/etc/ipsec.d/cacerts'
2020:07:18-09:52:58 fw-1 pluto[20940]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerNextcVerifCa.pem'
2020:07:18-09:52:58 fw-1 pluto[20940]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu.pem'
2020:07:18-09:52:58 fw-1 pluto[20940]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaSigVpnSigniCa.pem'
2020:07:18-09:52:58 fw-1 pluto[20940]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaThu2.pem'
2020:07:18-09:52:58 fw-1 pluto[20940]: loading aa certificates from '/etc/ipsec.d/aacerts'
2020:07:18-09:52:58 fw-1 pluto[20940]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2020:07:18-09:52:58 fw-1 pluto[20940]: Changing to directory '/etc/ipsec.d/crls'
2020:07:18-09:52:58 fw-1 pluto[20940]: loading attribute certificates from '/etc/ipsec.d/acerts'
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.112/lag0.112 10.1.12.1:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.112/lag0.112 10.1.12.1:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.114/lag0.114 10.1.14.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.114/lag0.114 10.1.14.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.113/lag0.113 10.1.13.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.113/lag0.113 10.1.13.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.102/lag0.102 10.1.2.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.102/lag0.102 10.1.2.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.105/lag0.105 10.1.5.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.105/lag0.105 10.1.5.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.104/lag0.104 10.1.4.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.104/lag0.104 10.1.4.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.106/lag0.106 10.1.6.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.106/lag0.106 10.1.6.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.103/lag0.103 10.1.3.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.103/lag0.103 10.1.3.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.110/lag0.110 10.1.10.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.110/lag0.110 10.1.10.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.111/lag0.111 10.1.11.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.111/lag0.111 10.1.11.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.140/lag0.140 192.168.40.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.140/lag0.140 192.168.40.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.101/lag0.101 10.1.1.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0.101/lag0.101 10.1.1.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0/lag0 10.1.99.254:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lag0/lag0 10.1.99.254:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth6/eth6 198.19.250.1:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth6/eth6 198.19.250.1:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth5/eth5 10.1.21.1:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth5/eth5 10.1.21.1:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth4/eth4 XXX.XXX.XXX.57:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface eth4/eth4 XXX.XXX.XXX.57:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lo/lo 127.0.0.1:500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lo/lo 127.0.0.1:4500
2020:07:18-09:52:58 fw-1 pluto[20940]: adding interface lo/lo ::1:500
2020:07:18-09:52:58 fw-1 pluto[20940]: loading secrets from "/etc/ipsec.secrets"
2020:07:18-09:52:58 fw-1 pluto[20940]: HA System: not master, won't listen for IKE messages
2020:07:18-09:52:58 fw-1 pluto[20940]: added connection description "S_REF_IpsSitKh6_0"
2020:07:18-09:52:58 fw-1 pluto[20940]: added connection description "S_REF_IpsSitKh6_1"
2020:07:18-09:52:58 fw-1 pluto[20940]: added connection description "S_REF_IpsSitKh6_2"
2020:07:18-09:52:58 fw-1 pluto[20940]: added connection description "S_REF_IpsSitKh6_3"
2020:07:18-09:52:58 fw-1 pluto[20940]: Pluto is now in slave mode

     

    Again I see the "Operation not permitted", but not the default route error from yesterday - probably something to do with not having the other tunnels active?

    Anyway - can you make something out of it? Ohh, Im getting a sinking feeling...

     

    Thanks and best regards,

    Constantin

  • 0 in reply to Sophos User438

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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

  • 0 in reply to Sophos User438

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to Sophos User438

    Hi Constantin,

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

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to BAlfson

    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

Reply
  • 0 in reply to BAlfson

    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

Children
No Data
Unfiltered HTML