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

    IPSec DNAT not working

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

      @Matt_Sharpe
      This looks well for what you try to achieve.

      And I cannot find a hint for the disconnection of the other tunnel in the log.
      But maybe there is an issue if you route the remote subnet over the VTI and also state it in the policy-based tunnel as remote network.

      M 1 Reply Last reply Reply Quote 0
      • 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.