Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC is giving package errors in "Middle" subnet

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 399 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      Redbob
      last edited by Redbob

      Hi,

      We have the following scenario:Captura de tela de 2024-01-18 19-34-58.png
      We have the following IPSEC:
      Phase 1:

      • IKEv2
        Phase 2:
      • Local Subnet: 172.24.44.0/22
      • Remote Subnet: 172.16.0.0/12

      Look, the local firewall (172.24.44.0/24) is within 172.24.44.0/22 subnet, as 172.14.1.3/22 (remote firewall) is within 172.16.0.0/12.

      So there is a static route within 172.24.44.70 to fix IPSEC routing:

      172.16.0.0/12 via 172.24.44.2 (172.24.44.0/22 gw)
      

      It's funny that when 172.24.44.51 pings to 172.24.3.1 (at same subnet of FW 172.24.1.3) it returns serveral package errors:

      Ping statistics for 172.24.3.1:
          Packets: Sent = 41, Received = 15, Lost = 26 (63% loss),
      Approximate round trip times in milli-seconds:
          Minimum = 59ms, Maximum = 59ms, Average = 59ms
      

      meanwhile when it pings 172.16.3.1, that at other side of a MPLS (WAN link), it does not so many package errors:

      Ping statistics for 172.16.3.1:
          Packets: Sent = 75, Received = 74, Lost = 1 (1% loss),
      Approximate round trip times in milli-seconds:
          Minimum = 74ms, Maximum = 107ms, Average = 79ms
      

      It's weird! I added a static route like this:

      172.24.0.0/16 via 172.24.44.2 
      

      but it not solve this issue.

      That's 172.16.3.1 route:

      Tracing route to SRVDC1-TRF1.trf1.gov.br [172.16.3.1]
      over a maximum of 30 hops:
      
        1     *        *        *     Request timed out.
        2    <1 ms    <1 ms    <1 ms  fw-bag.jfmt.jus.br [172.24.44.70]
        3    59 ms    59 ms    58 ms  172.24.1.3
        4    60 ms    60 ms    60 ms  172.24.0.2
        5    59 ms    59 ms     *     router-eth1.mt.trf1.gov.br [172.24.1.1]
        6     *        *        *     Request timed out.
        7     *        *        *     Request timed out.
        8    74 ms    79 ms    88 ms  172.16.180.22
        9    76 ms    94 ms    76 ms  SRVDC1-TRF1.trf1.gov.br [172.16.3.1]
      

      and that's 172.24.3.1 route:

      Tracing route to SRVDC1-MT.mt.trf1.gov.br [172.24.3.1]
      over a maximum of 30 hops:
      
        1     *        *        *     Request timed out.
        2    <1 ms    <1 ms    <1 ms  fw-bag.jfmt.jus.br [172.24.44.70]
        3    58 ms    58 ms    58 ms  172.24.1.3
        4     *        *       59 ms  SRVDC1-MT.mt.trf1.gov.br [172.24.3.1]
      

      Any ideas?

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @Redbob
        last edited by

        @Redbob said in IPSEC is giving package errors in "Middle" subnet:

        We have the following IPSEC:
        Phase 1:

        IKEv2
        Phase 2:
        Local Subnet: 172.24.44.0/22
        Remote Subnet: 172.16.0.0/12
        

        These subnets are overlapping.

        You can configure BINAT to circumvent collisions though, but is there really a /12 needed at the remote site?

        R 1 Reply Last reply Reply Quote 0
        • R
          Redbob @viragomann
          last edited by Redbob

          @viragomann It wasn't necessary. The issue was happening at the other peer, a Blockbit with two boxes, but the slave box, though operating, has not the redundancy enabled (cabling). When we turned off the slave box, the problem was solved.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.