Page 1 of 2 12 LastLast
Results 1 to 10 of 15
  1. #1
    Newbie
    Join Date
    Feb 2020
    Posts
    9

    Default Daily Connection Drops

    Hi, I would love some help\input on a IPsec VPN connection running between two untangles. The VPN works fine but drops at least once a day, it does reconnect itself if left but not always very quickly. As an example if I ran a constant ping over the tunnel for 24 hours yesterday, that stats were nearly perfect from 8:30am-10:20pm ish. When I then checked again this morning, I lost over 5000 pings overnight (33% loss, it was at 0% before). That said the tunnel was up when I checked this morning and pings are running fine again. Neither untangle has rebooted and nether has any failed WAN tests, it was physical machine on one side and a VM on the other. The VM did reboot due to windows updates but wasn't offline for the 4+ hours the ping test shows.

    The settings look like:

    Connection Type: Tunnel
    IKE Version: IKEv2
    Connect Mode: Always Connected (also tried connect on demand)
    Interface: Defined WAN on each device as they have 3xWAN connections each
    Remote Host: Correct WAN IP
    Local Identifier: Blank
    Remote Identifer: Blank
    Local Network: 178.16.5.0/24
    Remote Network: 178.16.1.0/24
    Shared Secret: Well thats a secret
    DPD Interval: 30
    DPD Timeout: 120
    Ping Address: blank
    Ping interval 0
    Phase 1: unticked on defaults
    Phase 2: unticked on defaults

    I have the VPN Log from last night but can't find a way to share it, it's too large to post and to large as an attachment (currently saved as a txt file). I can't post links as I've just joined and don't have 5 posts yet. Happy to share with anyone who can help by reviewing it, just with the WAN IPs removed.
    Last edited by andyatthowe; 02-16-2020 at 02:10 AM.

  2. #2
    Untangle Ninja
    Join Date
    May 2008
    Posts
    1,090

    Default

    I would also run a ping to something reliable like maybe google on both sides. Then you can see if the isp goes down. Do you have static ip on both sides?

    MTR is also a good tool to watch. It is like "trace route" but runs continuously.
    Last edited by donhwyo; 02-16-2020 at 08:48 AM.

  3. #3
    Newbie
    Join Date
    Feb 2020
    Posts
    9

    Default

    Quote Originally Posted by donhwyo View Post
    I would also run a ping to something reliable like maybe google on both sides. Then you can see if the isp goes down. Do you have static ip on both sides?

    MTR is also a good tool to watch. It is like "trace route" but runs continuously.
    Thanks Donhwyo, itís not an ISP going down. I get no failed WAN failover tests and they are running every 60secs. Will take a look at the MTR tool.

  4. #4
    Newbie
    Join Date
    Feb 2020
    Posts
    9

    Default

    Can anyone translate from this log what is going on? It feels like I have a timeout issue with the VPN, both WAN IPs have been omitted.

    Feb 16 08:03:18 Steeles-Diss charon: 07[IKE] CHILD_SA closed
    Feb 16 08:03:18 Steeles-Diss charon: 07[IKE] received DELETE for ESP CHILD_SA with SPI cd638f7c
    Feb 16 08:03:18 Steeles-Diss charon: 07[ENC] parsed INFORMATIONAL response 3 [ D ]
    Feb 16 08:03:18 Steeles-Diss charon: 07[NET] received packet: from WAN1[4500] to WAN2[4500] (68 bytes)
    Feb 16 08:03:18 Steeles-Diss charon: 12[NET] sending packet: from WAN2[4500] to WAN1[4500] (68 bytes)
    Feb 16 08:03:18 Steeles-Diss charon: 12[ENC] generating INFORMATIONAL request 3 [ D ]
    Feb 16 08:03:18 Steeles-Diss charon: 12[IKE] sending DELETE for ESP CHILD_SA with SPI ce36f68b
    Feb 16 08:03:18 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{197} with SPIs ce36f68b_i (0 bytes) cd638f7c_o (0 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:03:18 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{197} with SPIs ce36f68b_i (0 bytes) cd638f7c_o (0 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:03:18 Steeles-Diss charon: 12[IKE] CHILD_SA UT3_Norwich{206} established with SPIs c78a22a7_i cd79aee5_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:03:18 Steeles-Diss charon: 12[IKE] CHILD_SA UT3_Norwich{206} established with SPIs c78a22a7_i cd79aee5_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:03:18 Steeles-Diss charon: 12[ENC] parsed CREATE_CHILD_SA response 2 [ SA No KE TSi TSr ]
    Feb 16 08:03:18 Steeles-Diss charon: 12[NET] received packet: from WAN1[4500] to WAN2[4500] (452 bytes)
    Feb 16 08:03:18 Steeles-Diss charon: 09[NET] sending packet: from WAN2[4500] to WAN1[4500] (200 bytes)
    Feb 16 08:03:18 Steeles-Diss charon: 09[NET] sending packet: from WAN2[4500] to WAN1[4500] (1248 bytes)
    Feb 16 08:03:18 Steeles-Diss charon: 09[ENC] generating CREATE_CHILD_SA request 2 [ EF(2/2) ]
    Feb 16 08:03:18 Steeles-Diss charon: 09[ENC] generating CREATE_CHILD_SA request 2 [ EF(1/2) ]
    Feb 16 08:03:18 Steeles-Diss charon: 09[ENC] splitting IKE message with length of 1388 bytes into 2 fragments
    Feb 16 08:03:18 Steeles-Diss charon: 09[ENC] generating CREATE_CHILD_SA request 2 [ N(REKEY_SA) SA No KE TSi TSr ]
    Feb 16 08:03:18 Steeles-Diss charon: 09[IKE] establishing CHILD_SA UT3_Norwich{1}
    Feb 16 08:03:18 Steeles-Diss charon: 09[IKE] establishing CHILD_SA UT3_Norwich{1}
    Feb 16 08:03:18 Steeles-Diss charon: 14[KNL] creating rekey job for CHILD_SA ESP/0xcd638f7c/WAN1
    Feb 16 08:02:40 Steeles-Diss charon: 09[NET] sending packet: from WAN2[4500] to WAN1[4500] (68 bytes)
    Feb 16 08:02:40 Steeles-Diss charon: 09[ENC] generating INFORMATIONAL response 14 [ D ]
    Feb 16 08:02:40 Steeles-Diss charon: 09[IKE] CHILD_SA closed
    Feb 16 08:02:40 Steeles-Diss charon: 09[IKE] sending DELETE for ESP CHILD_SA with SPI ce970b1a
    Feb 16 08:02:40 Steeles-Diss charon: 09[IKE] closing CHILD_SA UT3_Norwich{195} with SPIs ce970b1a_i (0 bytes) c1e4443c_o (0 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:40 Steeles-Diss charon: 09[IKE] closing CHILD_SA UT3_Norwich{195} with SPIs ce970b1a_i (0 bytes) c1e4443c_o (0 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:40 Steeles-Diss charon: 09[IKE] received DELETE for ESP CHILD_SA with SPI c1e4443c
    Feb 16 08:02:40 Steeles-Diss charon: 09[ENC] parsed INFORMATIONAL request 14 [ D ]
    Feb 16 08:02:40 Steeles-Diss charon: 09[NET] received packet: from WAN1[4500] to WAN2[4500] (68 bytes)
    Feb 16 08:02:40 Steeles-Diss charon: 14[NET] sending packet: from WAN2[4500] to WAN1[4500] (452 bytes)
    Feb 16 08:02:40 Steeles-Diss charon: 14[ENC] generating CREATE_CHILD_SA response 13 [ SA No KE TSi TSr ]
    Feb 16 08:02:40 Steeles-Diss charon: 14[IKE] CHILD_SA UT3_Norwich{205} established with SPIs c8131400_i ce5e5a75_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:40 Steeles-Diss charon: 14[IKE] CHILD_SA UT3_Norwich{205} established with SPIs c8131400_i ce5e5a75_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:40 Steeles-Diss charon: 14[ENC] parsed CREATE_CHILD_SA request 13 [ N(REKEY_SA) SA No KE TSi TSr ]
    Feb 16 08:02:40 Steeles-Diss charon: 14[ENC] received fragment #2 of 2, reassembling fragmented IKE message
    Feb 16 08:02:40 Steeles-Diss charon: 14[ENC] parsed CREATE_CHILD_SA request 13 [ EF(2/2) ]
    Feb 16 08:02:40 Steeles-Diss charon: 14[NET] received packet: from WAN1[4500] to WAN2[4500] (200 bytes)
    Feb 16 08:02:40 Steeles-Diss charon: 08[ENC] received fragment #1 of 2, waiting for complete IKE message
    Feb 16 08:02:40 Steeles-Diss charon: 08[ENC] parsed CREATE_CHILD_SA request 13 [ EF(1/2) ]
    Feb 16 08:02:40 Steeles-Diss charon: 08[NET] received packet: from WAN1[4500] to WAN2[4500] (1248 bytes)
    Feb 16 08:02:32 Steeles-Diss charon: 12[NET] sending packet: from WAN2[4500] to WAN1[4500] (68 bytes)
    Feb 16 08:02:32 Steeles-Diss charon: 12[ENC] generating INFORMATIONAL response 12 [ D ]
    Feb 16 08:02:32 Steeles-Diss charon: 12[IKE] CHILD_SA closed
    Feb 16 08:02:32 Steeles-Diss charon: 12[IKE] sending DELETE for ESP CHILD_SA with SPI c25a84ce
    Feb 16 08:02:32 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{200} with SPIs c25a84ce_i (896856 bytes) cc583399_o (667651 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:32 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{200} with SPIs c25a84ce_i (896856 bytes) cc583399_o (667651 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:32 Steeles-Diss charon: 12[IKE] received DELETE for ESP CHILD_SA with SPI cc583399
    Feb 16 08:02:32 Steeles-Diss charon: 12[ENC] parsed INFORMATIONAL request 12 [ D ]
    Feb 16 08:02:32 Steeles-Diss charon: 12[NET] received packet: from WAN1[4500] to WAN2[4500] (68 bytes)
    Feb 16 08:02:32 Steeles-Diss charon: 09[NET] sending packet: from WAN2[4500] to WAN1[4500] (452 bytes)
    Feb 16 08:02:32 Steeles-Diss charon: 09[ENC] generating CREATE_CHILD_SA response 11 [ SA No KE TSi TSr ]
    Feb 16 08:02:32 Steeles-Diss charon: 09[IKE] CHILD_SA UT3_Norwich{204} established with SPIs cd341fc9_i c9bf2872_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:32 Steeles-Diss charon: 09[IKE] CHILD_SA UT3_Norwich{204} established with SPIs cd341fc9_i c9bf2872_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:02:32 Steeles-Diss charon: 09[ENC] parsed CREATE_CHILD_SA request 11 [ N(REKEY_SA) SA No KE TSi TSr ]
    Feb 16 08:02:32 Steeles-Diss charon: 09[ENC] received fragment #2 of 2, reassembling fragmented IKE message
    Feb 16 08:02:32 Steeles-Diss charon: 09[ENC] parsed CREATE_CHILD_SA request 11 [ EF(2/2) ]
    Feb 16 08:02:32 Steeles-Diss charon: 09[NET] received packet: from WAN1[4500] to WAN2[4500] (200 bytes)
    Feb 16 08:02:32 Steeles-Diss charon: 08[ENC] received fragment #1 of 2, waiting for complete IKE message
    Feb 16 08:02:32 Steeles-Diss charon: 08[ENC] parsed CREATE_CHILD_SA request 11 [ EF(1/2) ]
    Feb 16 08:02:32 Steeles-Diss charon: 08[NET] received packet: from WAN1[4500] to WAN2[4500] (1248 bytes)
    Feb 16 08:01:42 Steeles-Diss charon: 12[NET] sending packet: from WAN2[4500] to WAN1[4500] (68 bytes)
    Feb 16 08:01:42 Steeles-Diss charon: 12[ENC] generating INFORMATIONAL response 10 [ D ]
    Feb 16 08:01:42 Steeles-Diss charon: 12[IKE] CHILD_SA closed
    Feb 16 08:01:42 Steeles-Diss charon: 12[IKE] sending DELETE for ESP CHILD_SA with SPI ca2d646a
    Feb 16 08:01:42 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{198} with SPIs ca2d646a_i (50 bytes) ce2fe11c_o (52 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:01:42 Steeles-Diss charon: 12[IKE] closing CHILD_SA UT3_Norwich{198} with SPIs ca2d646a_i (50 bytes) ce2fe11c_o (52 bytes) and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:01:42 Steeles-Diss charon: 12[IKE] received DELETE for ESP CHILD_SA with SPI ce2fe11c
    Feb 16 08:01:42 Steeles-Diss charon: 12[ENC] parsed INFORMATIONAL request 10 [ D ]
    Feb 16 08:01:42 Steeles-Diss charon: 12[NET] received packet: from WAN1[4500] to WAN2[4500] (68 bytes)
    Feb 16 08:01:42 Steeles-Diss charon: 08[NET] sending packet: from WAN2[4500] to WAN1[4500] (452 bytes)
    Feb 16 08:01:42 Steeles-Diss charon: 08[ENC] generating CREATE_CHILD_SA response 9 [ SA No KE TSi TSr ]
    Feb 16 08:01:42 Steeles-Diss charon: 08[IKE] CHILD_SA UT3_Norwich{203} established with SPIs c621311d_i c8c654db_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:01:42 Steeles-Diss charon: 08[IKE] CHILD_SA UT3_Norwich{203} established with SPIs c621311d_i c8c654db_o and TS 178.16.5.0/24 === 178.16.1.0/24
    Feb 16 08:01:42 Steeles-Diss charon: 08[ENC] parsed CREATE_CHILD_SA request 9 [ N(REKEY_SA) SA No KE TSi TSr ]
    Feb 16 08:01:42 Steeles-Diss charon: 08[ENC] received fragment #2 of 2, reassembling fragmented IKE message
    Feb 16 08:01:42 Steeles-Diss charon: 08[ENC] parsed CREATE_CHILD_SA request 9 [ EF(2/2) ]
    Feb 16 08:01:42 Steeles-Diss charon: 08[NET] received packet: from WAN1[4500] to WAN2[4500] (200 bytes)
    Feb 16 08:01:42 Steeles-Diss charon: 09[ENC] received fragment #1 of 2, waiting for complete IKE message
    Feb 16 08:01:42 Steeles-Diss charon: 09[ENC] parsed CREATE_CHILD_SA request 9 [ EF(1/2) ]
    Feb 16 08:01:42 Steeles-Diss charon: 09[NET] received packet: from WAN1[4500] to WAN2[4500] (1248 bytes)
    Feb 16 08:00:05 Steeles-Diss charon: 10[NET] sending packet: from WAN2[4500] to WAN1[4500] (68 bytes)
    Feb 16 08:00:05 Steeles-Diss charon: 10[ENC] generating INFORMATIONAL response 8 [ D ]
    Feb 16 08:00:05 Steeles-Diss charon: 10[IKE] CHILD_SA closed

  5. #5
    Master Untangler Sam Graf's Avatar
    Join Date
    Feb 2016
    Location
    Michigan
    Posts
    927

    Default

    I apologize that I don't have an answer for you and it's been years since I used an IPsec VPN (during the days of Linksys VPN routers, in fact; I'm guessing many of us use OpenVPN for Untangle-to-Untangle VPNs), but I did a little digging and see that the VM might be a clue:

    we finally found the root cause. Despite having a public ip communicating directly with the vpn, the machine, being a virtual machine, was forced to go through the firewall. The DPD requests are sent from a different port than the VPN packets, therefore the connection for them, when idle for too long, was closed by the firewall.
    Digging around produced a pretty large set of solutions to connection drops from a pretty large set of apparent causes, but this particular comment from a StackExchange thread seemed worth passing along.

  6. #6
    Newbie
    Join Date
    Feb 2020
    Posts
    9

    Default

    Thanks Sam, this could well be it . Thinking out loud the connection drops seem to be overnight when there would be no activity. I see I can define a local IP to ping on the IPSec settings so my instinct is to try that next. Do you think that seems like a sensible idea?

    I did try the OpenVPN connection instead but could only get one way traffic going with it. The server side couldn't get onto the client side (I exported the networks on each side), untangle to untangle I could ping devices on both sides. On the client side I could access things on the server side. I just couldn't get from a machine on the server side to the client side. Seems like a route issue

  7. #7
    Master Untangler Sam Graf's Avatar
    Join Date
    Feb 2016
    Location
    Michigan
    Posts
    927

    Default

    That does seem like a sensible idea. Let us know how that goes.

    Hmm, it's been awhile since I had traffic from the server side to the client side (three years and more maybe). From memory of when I was working with two branch offices and a main office, the only access that didn't work was branch to branch (which wasn't needed). My memory of it all is a little unclear, though, and along the way we transitioned to virtual desktops, which muddies the waters. Even then, though, if a branch office was running a virtual desktop served at the main office, the printer (for example) would still be at the branch. The virtual desktop itself would be communicating with the thin client at the branch. Etc. But how specifically that was all configured (other than we were using OpenVPN connections) I can't recall (thought it would have all been done through the UI).

  8. #8
    Master Untangler
    Join Date
    Dec 2018
    Posts
    165

    Default

    Does the Uptime of Untangle reset as well?

    Is it down for about a minute at a time?

    ETA: I and others have found that having Site-to-Site as well as client IPSec tunnels would cause UVM to crash.

    I moved all users to OpenVPN connections and have kept Site-To-Site as IPSec connections and am now stable.
    Last edited by jlficken; 02-17-2020 at 02:41 PM.

  9. #9
    Newbie
    Join Date
    Feb 2020
    Posts
    9

    Default

    Quote Originally Posted by jlficken View Post
    Does the Uptime of Untangle reset as well?

    Is it down for about a minute at a time?

    ETA: I and others have found that having Site-to-Site as well as client IPSec tunnels would cause UVM to crash.

    I moved all users to OpenVPN connections and have kept Site-To-Site as IPSec connections and am now stable.
    Thanks jlficken it must be going down for longer than a minute, the uptime of the untangle itself is stable at several days which is correct. The VPN stats do reset when it drops and tend to get stuck at a small amount of traffic. Since it went overnight last night its been spot on today (about 15 hours and counting). I have added in the ping on both sides of the tunnel so will monitor that and see how we go. I'm also not running OpenVPN on either device or any client VPN connections, its just the IPSec site to site live.

  10. #10
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    1,712

    Default OpenVPN

    Quote Originally Posted by andyatthowe View Post
    I did try the OpenVPN connection instead but could only get one way traffic going with it. The server side couldn't get onto the client side (I exported the networks on each side), untangle to untangle I could ping devices on both sides. On the client side I could access things on the server side. I just couldn't get from a machine on the server side to the client side. Seems like a route issue
    If you want to pursue OpenVPN, I have some experience making it work. But I will have questions. So post a new thread in the OpenVPN forum, if you like.

    One thing you shouldn't do is 'export the network' that exists on the client side, that is a no-no. From: https://community.openvpn.net/openvpn/wiki/HOWTO?
    Code:
    Before setup, there are some basic prerequisites, which must be followed:
    The client LAN subnet must not be exported to the VPN by the server or any other client sites that are using the same subnet.
    Every subnet which is joined to the VPN via routing must be unique.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2