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

    Site-to-Site + Synology Diskstation = Problems

    Scheduled Pinned Locked Moved IPsec
    2 Posts 1 Posters 2.3k 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.
    • S
      strigona
      last edited by

      Hi,

      I've got a seemingly bizarre issue that I can't seem to wrap my head around.
      Network Setup

      • LAN (office): 10.0.0.1/24

      • IPsec (site-to-site to Azure): 10.1.0.0/16

      • OpenVPN (remote users): 10.0.100.0/24

      After a hardware failure, we move our DC to a VM in Azure (10.1.1.6).

      I upgraded our remote users to use pfSense's OpenVPN using RADIUS authentication. I ran into a problem that RADIUS auth requests to 10.1.1.6 were going out on the WAN instead of across the IPsec tunnel. I found this pfSense doc to create a static route to help pfSense generated traffic make its way across the tunnel - problem solved.

      After applying this change, my Synology DiskStation DS415+ can no longer properly communicate to any devices across the IPsec tunnel. It'll reply to ICMP/ping requests, however as soon as I try browsing to the DiskStation's network share via Windows Explorer, the DiskStation start's ARP'ing the DC's IP - which makes no sense as they're in different subnets.

      At this point I figured the DiskStation hated communicating to devices outside of its own subnet. However, OpenVPN clients (10.0.100.0/24) are able to communicate just fine.

      I started reversing pfSense config changes until I got to the static route used to get RADIUS working. Now I'm stuck choosing between OpenVPN RADIUS or DiskStation being on the domain.

      Here's an album of the config's that I believe are relevant: http://imgur.com/a/v20O0

      1 Reply Last reply Reply Quote 0
      • S
        strigona
        last edited by

        The plot thickens a bit more and I get more and more out of my depth of field.

        I have toggled the following value:

        net.inet.ip.redirect = 0 (default 1)

        and communication between the Diskstation and Azure has been restored.

        Have I set myself up for more problems by altering the above flag?

        Thanks in advance!

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