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.0k 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 @Matt_Sharpe
      last edited by

      Jan 16 14:40:07 charon 75651 12[CFG] policies = 1
      Jan 16 14:40:07 charon 75651 12[CFG] mode = PASS
      Jan 16 14:40:07 charon 75651 12[CFG] ipcomp = 0
      Jan 16 14:40:07 charon 75651 12[CFG] hostaccess = 0
      Jan 16 14:40:07 charon 75651 12[CFG] updown = (null)
      Jan 16 14:40:07 charon 75651 12[CFG] rand_packets = 0
      Jan 16 14:40:07 charon 75651 12[CFG] life_packets = 0
      Jan 16 14:40:07 charon 75651 12[CFG] rekey_packets = 0
      Jan 16 14:40:07 charon 75651 12[CFG] rand_bytes = 0
      Jan 16 14:40:07 charon 75651 12[CFG] life_bytes = 0
      Jan 16 14:40:07 charon 75651 12[CFG] rekey_bytes = 0
      Jan 16 14:40:07 charon 75651 12[CFG] rand_time = 360
      Jan 16 14:40:07 charon 75651 12[CFG] life_time = 3960
      Jan 16 14:40:07 charon 75651 12[CFG] rekey_time = 3600
      Jan 16 14:40:07 charon 75651 12[CFG] child bypasslan:
      Jan 16 14:40:07 charon 75651 12[CFG] conn bypass:
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: load-conn
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: get-conns
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: get-pools
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: get-authorities
      Jan 16 14:40:07 charon 75651 12[CFG] loaded IKE shared key with id 'ike-1' for: '%any', 'CUSTOMER_WAN_IP'
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: load-shared
      Jan 16 14:40:07 charon 75651 12[CFG] loaded IKE shared key with id 'ike-0' for: '%any', 'AZURE_WAN_IP'
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: load-shared
      Jan 16 14:40:07 charon 75651 12[CFG] vici client 1276 requests: get-shared
      Jan 16 14:40:07 charon 75651 14[CFG] vici client 1276 requests: get-keys
      Jan 16 14:40:07 charon 75651 14[CFG] vici client 1276 connected
      Jan 16 14:40:07 charon 75651 07[CFG] vici client 1275 disconnected
      Jan 16 14:40:07 charon 75651 07[CFG] loaded 0 RADIUS server configurations
      Jan 16 14:40:07 charon 75651 07[CFG] loaded 0 entries for attr plugin configuration
      Jan 16 14:40:07 charon 75651 07[CFG] ipseckey plugin is disabled
      Jan 16 14:40:07 charon 75651 07[CFG] vici client 1275 requests: reload-settings
      Jan 16 14:40:07 charon 75651 14[CFG] vici client 1275 connected
      Jan 16 14:40:07 charon 75651 05[IKE] <con2|4> keeping statically configured path PROVIDER_WAN_IP - CUSTOMER_WAN_IP
      Jan 16 14:40:07 charon 75651 05[KNL] 10.199.47.1 appeared on ipsec2
      Jan 16 14:40:07 charon 75651 13[KNL] interface ipsec2 appeared
      Jan 16 14:40:07 charon 75651 13[KNL] interface ipsec2 disappeared
      Jan 16 14:40:07 charon 75651 09[KNL] interface ipsec2 deactivated
      Jan 16 14:40:07 charon 75651 09[KNL] 10.199.47.1 disappeared from ipsec2
      Jan 16 14:40:06 charon 75651 09[IKE] <con1|3> nothing to initiate
      Jan 16 14:40:06 charon 75651 09[IKE] <con1|3> activating new tasks
      Jan 16 14:40:06 charon 75651 09[NET] <con1|3> sending packet: from PROVIDER_WAN_IP[500] to AZURE_WAN_IP[500] (92 bytes)
      Jan 16 14:40:06 charon 75651 09[ENC] <con1|3> generating INFORMATIONAL_V1 request 2819744997 [ HASH N(DPD_ACK) ]
      Jan 16 14:40:06 charon 75651 09[IKE] <con1|3> activating ISAKMP_DPD task
      Jan 16 14:40:06 charon 75651 09[IKE] <con1|3> activating new tasks
      Jan 16 14:40:06 charon 75651 09[IKE] <con1|3> queueing ISAKMP_DPD task
      Jan 16 14:40:06 charon 75651 09[ENC] <con1|3> parsed INFORMATIONAL_V1 request 1404219913 [ HASH N(DPD) ]
      Jan 16 14:40:06 charon 75651 09[NET] <con1|3> received packet: from AZURE_WAN_IP[500] to PROVIDER_WAN_IP[500] (92 bytes)
      Jan 16 14:40:05 charon 75651 09[CFG] vici client 1274 disconnected
      Jan 16 14:40:05 charon 75651 09[CFG] vici client 1274 requests: list-sas
      Jan 16 14:40:05 charon 75651 15[CFG] vici client 1274 registered for: list-sa
      Jan 16 14:40:05 charon 75651 15[CFG] vici client 1274 connected
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> nothing to initiate
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> activating new tasks
      Jan 16 14:40:02 charon 75651 09[ENC] <con1|3> parsed INFORMATIONAL_V1 request 1532146135 [ HASH N(DPD_ACK) ]
      Jan 16 14:40:02 charon 75651 09[NET] <con1|3> received packet: from AZURE_WAN_IP[500] to PROVIDER_WAN_IP[500] (92 bytes)
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> nothing to initiate
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> activating new tasks
      Jan 16 14:40:02 charon 75651 09[NET] <con1|3> sending packet: from PROVIDER_WAN_IP[500] to AZURE_WAN_IP[500] (92 bytes)
      Jan 16 14:40:02 charon 75651 09[ENC] <con1|3> generating INFORMATIONAL_V1 request 1473236439 [ HASH N(DPD) ]
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> activating ISAKMP_DPD task
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> activating new tasks
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> queueing ISAKMP_DPD task
      Jan 16 14:40:02 charon 75651 09[IKE] <con1|3> sending DPD request
      Jan 16 14:40:00 charon 75651 09[CFG] vici client 1273 disconnected
      Jan 16 14:40:00 charon 75651 15[CFG] vici client 1273 requests: list-sas
      Jan 16 14:40:00 charon 75651 11[CFG] vici client 1273 registered for: list-sa
      Jan 16 14:40:00 charon 75651 11[CFG] vici client 1273 connected
      Jan 16 14:39:55 charon 75651 15[CFG] vici client 1272 disconnected
      Jan 16 14:39:55 charon 75651 11[CFG] vici client 1272 requests: list-sas
      Jan 16 14:39:55 charon 75651 08[CFG] vici client 1272 registered for: list-sa
      Jan 16 14:39:55 charon 75651 11[CFG] vici client 1272 connected
      Jan 16 14:39:52 charon 75651 08[IKE] <con1|3> nothing to initiate
      Jan 16 14:39:52 charon 75651 08[IKE] <con1|3> activating new tasks
      Jan 16 14:39:52 charon 75651 08[NET] <con1|3> sending packet: from PROVIDER_WAN_IP[500] to AZURE_WAN_IP[500] (92 bytes)
      Jan 16 14:39:52 charon 75651 08[ENC] <con1|3> generating INFORMATIONAL_V1 request 316903062 [ HASH N(DPD_ACK) ]
      Jan 16 14:39:52 charon 75651 08[IKE] <con1|3> activating ISAKMP_DPD task
      Jan 16 14:39:52 charon 75651 08[IKE] <con1|3> activating new tasks
      Jan 16 14:39:52 charon 75651 08[IKE] <con1|3> queueing ISAKMP_DPD task
      Jan 16 14:39:52 charon 75651 08[ENC] <con1|3> parsed INFORMATIONAL_V1 request 2810856974 [ HASH N(DPD) ]
      Jan 16 14:39:52 charon 75651 08[NET] <con1|3> received packet: from AZURE_WAN_IP[500] to PROVIDER_WAN_IP[500] (92 bytes)
      Jan 16 14:39:50 charon 75651 08[CFG] vici client 1271 disconnected
      Jan 16 14:39:50 charon 75651 16[CFG] vici client 1271 requests: list-sas
      Jan 16 14:39:50 charon 75651 16[CFG] vici client 1271 registered for: list-sa
      Jan 16 14:39:50 charon 75651 16[CFG] vici client 1271 connected
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> nothing to initiate
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> activating new tasks
      Jan 16 14:39:48 charon 75651 11[ENC] <con1|3> parsed INFORMATIONAL_V1 request 1390613614 [ HASH N(DPD_ACK) ]
      Jan 16 14:39:48 charon 75651 11[NET] <con1|3> received packet: from AZURE_WAN_IP[500] to PROVIDER_WAN_IP[500] (92 bytes)
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> nothing to initiate
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> activating new tasks
      Jan 16 14:39:48 charon 75651 11[NET] <con1|3> sending packet: from PROVIDER_WAN_IP[500] to AZURE_WAN_IP[500] (92 bytes)
      Jan 16 14:39:48 charon 75651 11[ENC] <con1|3> generating INFORMATIONAL_V1 request 2462119987 [ HASH N(DPD) ]
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> activating ISAKMP_DPD task
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> activating new tasks
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> queueing ISAKMP_DPD task
      Jan 16 14:39:48 charon 75651 11[IKE] <con1|3> sending DPD request
      Jan 16 14:39:45 charon 75651 11[CFG] vici client 1270 disconnected
      Jan 16 14:39:45 charon 75651 16[CFG] vici client 1270 requests: list-sas
      Jan 16 14:39:45 charon 75651 06[CFG] vici client 1270 registered for: list-sa
      Jan 16 14:39:45 charon 75651 06[CFG] vici client 1270 connected
      Jan 16 14:39:39 charon 75651 06[CFG] vici client 1269 disconnected
      Jan 16 14:39:39 charon 75651 16[CFG] vici client 1269 requests: list-sas
      Jan 16 14:39:39 charon 75651 10[CFG] vici client 1269 registered for: list-sa
      Jan 16 14:39:39 charon 75651 10[CFG] vici client 1269 connected

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

        @Matt_Sharpe said in IPSec DNAT not working:

        Jan 16 14:40:07 charon 75651 12[CFG] remote_ts = 172.16.200.0/24|/0
        Jan 16 14:40:07 charon 75651 12[CFG] local_ts = 172.16.200.0/24|/0

        Did you replace one of these wrongly?
        Remote and local network cannot be the same.

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

          @viragomann It appears in the log several times, can you confirm what line number you're looking at? I have this open in N++

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

            @Matt_Sharpe
            Check your tunnel settings. Both local network or BINAT network must not overlap the remote network.

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

              @viragomann The VTI tunnel is set with a random/unique IP subnet we used for the VTI routing on both sides:

              b166a4f8-7ccf-44a7-94a1-08837888259a-image.png

              This doesn't overlap with any of the local/remote/isolated ranges?

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

                @Matt_Sharpe
                What's with the other tunnel?

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

                  @viragomann The Azure tunnel?

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

                    @Matt_Sharpe
                    No, the one doing NAT.
                    But obviously you've deleted it already. So do you still see these log entries?

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

                      @viragomann the other tunnel has been removed, as it impacts the live IPsec when enabled. If we tweak it to include the ranges in this forum post:

                      172.16.100.1 > IPsec tunnel > 172.16.200.253 (NATs to) 172.16.210.253

                      ae6d6c6e-5c61-4db4-9d59-4ca89068c2f7-image.png

                      V 1 Reply Last reply Reply Quote 0
                      • 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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.