NAT to a server on a different subnet through site-to-site ipsec tunnel

AlexZig
AlexZig Posts: 5  Freshman Member
First Comment Friend Collector
in Security

We have an IPsec tunnel through an ISP running on our ATP 800, connecting through WAN1. Our current setup is:

  • Local policy: 10.0.0.0/23 subnet (with interface 10.0.1.1/24 on LAN5)
  • Remote policy: 10.0.2.0-10.0.255.255 range
  • Policy Route:
    • Incoming: LAN5
    • Source: 10.0.0.0/23 subnet
    • Destination: 10.0.2.0-10.0.255.255 range
    • Next Hop: VPN Tunnel
  • Policy Control: allow 10.0.0.0/23 <> 10.0.2.0-10.0.255.255 range

The remote locations have multiple 10.0.x.0/23 subnets within that range.

My challenge is that I need some remote subnets to reach a server on 172.18.0.10 (with interface 172.18.0.1/24 on LAN1). While setting up another Phase 2 would be ideal, coordinating with our ISP makes this impractical.

I've attempted to set up DNAT on Phase 2 with:

  • Original IP: 10.0.1.10 (dummy IP for server)
  • Mapped IP: 172.18.0.10 (real IP for server)
  • All protocols enabled

I've also added 'allow 10.0.2.0-10.0.255.255 range <> 172.18.0.10' to the policy control.

My understanding was that the DNAT would handle incoming traffic to 10.0.1.10, translate the destination IP to 172.18.0.10, route internally via LAN1, receive response packets to the 10.0.2.0-10.0.255.255 range, translate the source IP, and send it back through the tunnel.

Something isn't working as expected. I've tried adding additional routes and outbound traffic source NAT to Phase 2 settings without success. And also tried adding a virtual server in the NAT settings as well.

Any help would be greatly appreciated!

Thank you in advance, Alex

Accepted Solution

  • PeterUK
    PeterUK Posts: 3,709  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary
    edited March 18 Answer ✓

    so with the above I tested and was able to make it work plus a routing rule

    incoming interface 172.18.0.1/24 on LAN1

    Destination 10.0.2.0-10.0.255.255

    nexthop VPN tunnel

All Replies

  • Zyxel_Melen
    Zyxel_Melen Posts: 3,116  Zyxel Employee
    Zyxel Certified Network Engineer Level 1 - Switch Zyxel Certified Network Administrator - Switch Zyxel Certified Network Administrator - Nebula Zyxel Certified Sales Associate
    edited March 18

    Hi @AlexZig,

    Let me summarize your purpose in short:

    Another site has connected a S2S VPN with ATP800(configuration as you provided). Now you want another site to connect the NAS, in ATP800 LAN1, via the VPN tunnel.

    My question is:

    1. What device is on another site? Can you manage it?
    2. What type of S2S VPN are you using? Route-based VPN or Policy-based VPN?
    3. Why did you add the Policy Route rule? Have you tried to disable it and test the DNAT setting?
    Zyxel Melen


  • AlexZig
    AlexZig Posts: 5  Freshman Member
    First Comment Friend Collector

    Thank you for your quick reply. To clarify:

    1. The devices at the remote sites are fortigates managed by the ISP. I don't have direct management access to them.
    2. We're using a Policy-based IPsec VPN. The tunnel is established and working correctly for the original subnet pairs.
    3. This policy route is required for the VPN tunnel to work
      1. Policy Route:
      2. Incoming: LAN5
      3. Source: 10.0.0.0/23 subnet
      4. Destination: 10.0.2.0-10.0.255.255 range
      5. Next Hop: VPN Tunnel

    My primary goal is to allow specific remote subnets to reach our server on the 172.18.0.10 address (LAN1) through the existing VPN tunnel, without having to request configuration changes from the ISP for all the remote firewalls.

    If there's a better approach than my attempted DNAT solution, I'm very open to suggestions. I can make changes on our ATP 800, but changes to the remote endpoints would require involving the ISP.

    Thanks again for your help.

  • PeterUK
    PeterUK Posts: 3,709  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary

    From what I can make out the problem is the remote end not knowing where your server on 172.18.0.10 is on ATP800 to go down the tunnel which you say your ISP has so its that end that needs to send Destination 172.18.0.1/24 down the tunnel to you.

  • AlexZig
    AlexZig Posts: 5  Freshman Member
    First Comment Friend Collector
    https://community.zyxel.com/en/discussion/comment/75995#Comment_75995

    Thank you Peter, that would easily be solved by having a secondary phase 2 setup on the tunnel allowing data transfer through the 172.18.0.1/24 subnet over the tunnel. But as far as I understand, it's not possible for the remote locations to access that subnet over the current tunnel configuration.

    The remote sites can reach IPs in our 10.0.0.0/23 range, so if I create a DNAT address of 10.0.1.10. And have clients on the remote sites send traffic to that address, the ISP gateways/routers should forward traffic to this address through the tunnel, and then our ATP800 translates this and reroutes to the 172.18.0.10 server.

    That was my understanding, but since it is not working I am obviously missing something.

  • PeterUK
    PeterUK Posts: 3,709  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary
    edited March 18

    But you have to select a incoming interface which will not be the tunnel unless you did VTI which would mean setup on the other side

    On your side you can try but don't think it will work is to go to your Phase 2 setting click Advanced at the bottom and use Destination NAT if Original IP is 10.0.1.1 or virtual interface to map to 172.18.0.10 maybe it might work?

    Or subnet your 10. for the server in range of the tunnel setup?

  • PeterUK
    PeterUK Posts: 3,709  Guru Member
    100 Answers 2500 Comments Friend Collector Seventh Anniversary
    edited March 18 Answer ✓

    so with the above I tested and was able to make it work plus a routing rule

    incoming interface 172.18.0.1/24 on LAN1

    Destination 10.0.2.0-10.0.255.255

    nexthop VPN tunnel

  • AlexZig
    AlexZig Posts: 5  Freshman Member
    First Comment Friend Collector

    Thank you very much Peter, the routing rule was the part I was missing, everything working as expected now! Have a great evening

Categories

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）