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

    IPSec DNAT not working

    Scheduled Pinned Locked Moved NAT
    47 Posts 2 Posters 5.1k 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.
    • M
      Matt_Sharpe @viragomann
      last edited by

      @viragomann is there any other way we can achieve this? With native NAT rather than a profile on the IPSEC?

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

        @Matt_Sharpe
        I reread your intention. If your only aim is to access 172.16.210.253 from the remote site via RDP, it should also work with a simple NAT rule. You can add the rule to IPSec on pfSense like this:
        interface: IPSec
        source: may be limited to the remote network
        destination: 172.16.200.253
        redirect target: 172.16.210.253

        You can also limit it to RDP by stating
        protocol: TCP/UDP
        dest. and target port: RDP

        It should also be possible to add this rule to the VTI IPSec interface instead.

        If packets are coming in on IPSec interfaces addressed to the destination IP pfSense will redirect them to the target. The source IP in response packets will be translated back to the origin destination address due to the state table entry.
        However, access in the other direction would not work this way, even not with NAT 1:1 or outbound NAT.

        "Any" for interface as you mentioned above is not available in pfSense, however, you can create interface groups and apply rules to them. So the rules will be applied to all member interfaces of the group.

        M 1 Reply Last reply Reply Quote 0
        • M
          Matt_Sharpe @viragomann
          last edited by

          @viragomann I'm pretty sure I've already tried this as it's the most obvious solution:

          e45e98ff-19f0-48ed-a62e-8fb80a61332a-image.png

          5a27edf1-afea-443a-8dbe-ab36a6716bb7-image.png

          How do we create interface groups?

          M 1 Reply Last reply Reply Quote 0
          • M
            Matt_Sharpe @Matt_Sharpe
            last edited by

            @Matt_Sharpe found a deny in the logs from target NAT to source range IP. (Changed to our masked IPs in this forum post)

            7e1477be-ac6b-42bb-9b91-515cc4ee20db-image.png

            I do not have ANY deny rules set in IPsec interface, so why is it blocked??

            M 1 Reply Last reply Reply Quote 0
            • M
              Matt_Sharpe @Matt_Sharpe
              last edited by

              @viragomann also TCP:SA packets blocked by same rule.

              8f2cd067-0be6-4336-91fe-1c36baac8bd2-image.png

              We have TCP IPv4 allowed in both directions, so why would it be blocked...

              110b5858-57f9-4aae-93ba-b30d7a0e96d3-image.png

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

                @Matt_Sharpe
                Obviously pfSense has no proper state for the response. Search for it in Diagnostic > States.

                Is the RDP server on a remote site or is local?

                How do we create interface groups?
                Interfaces > Interface Groups

                I assume, you won't use a group rule for this case?

                M 1 Reply Last reply Reply Quote 0
                • M
                  Matt_Sharpe @viragomann
                  last edited by

                  @viragomann The RDP server (the target of the NAT rule) is in the same site as the PFsense we're applying it on.

                  No, not used for this case. Just curious for future use.

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

                    @Matt_Sharpe said in IPSec DNAT not working:

                    The RDP server (the target of the NAT rule) is in the same site as the PFsense we're applying it on.

                    Then I'm wondering, why a respond packet from the RDP server is shown up as entering IPSec.

                    So I'm out of ideas, what could be the reason for this blocks.
                    But you can probably circumvent it with a sloppy state rule (I don't like this):
                    action: pass
                    interface: IPSec
                    source: RDP server
                    source port RDP
                    destination: remote network
                    destination port: any
                    open the Advanced Options
                    at State type select Sloppy

                    I don't like it, but it should work.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      Matt_Sharpe @viragomann
                      last edited by

                      @viragomann is that a NAT or FW rule?

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

                        @Matt_Sharpe
                        A firewall rule. A NAT rule ever needs a target...

                        M 1 Reply Last reply Reply Quote 0
                        • M
                          Matt_Sharpe @viragomann
                          last edited by

                          @viragomann I have created an isolated lab for this. Slightly different ranges.

                          Source site = 172.16.43.0/24
                          Target site = 172.16.200.0/24
                          Isolated network on target side = 172.16.210.0/24

                          IPSEC Interface
                          FW rules any/any on IPV4.
                          Also enabled sloppy mode.
                          No joy.

                          4929c874-460c-4515-8f2c-aa337c71baac-image.png

                          I was tinkering with Outbound NAT rules for the interfaces to be able to route between each other which led to different results on a picture capture. Not sure if any specific outbound NAT would be required here:

                          48f545fb-1a9d-4de9-853c-1d6257f94cc4-image.png

                          273b324f-1ed5-4c5f-9f3f-14e71c51df30-image.png

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