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

    (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP

    Scheduled Pinned Locked Moved IPsec
    55 Posts 4 Posters 8.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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      Ok, but the rule that is creating that state is not '@68' I assume?

      I imagine the WireGuard process has a record of the client IP and source port and start sending traffic back to it. The 'allow everything out' rule will pass that and create a new state. Since that isn't the rule on WAN that doesn't show the traffic.

      If you removed the rule on the server side WAN and then restarted WireGuard or rebooted I would expect it to fail to come back up.

      Steve

      K 1 Reply Last reply Reply Quote 0
      • K
        kevindd992002 @stephenw10
        last edited by kevindd992002

        @stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:

        Ok, but the rule that is creating that state is not '@68' I assume?

        I imagine the WireGuard process has a record of the client IP and source port and start sending traffic back to it. The 'allow everything out' rule will pass that and create a new state. Since that isn't the rule on WAN that doesn't show the traffic.

        If you removed the rule on the server side WAN and then restarted WireGuard or rebooted I would expect it to fail to come back up.

        Steve

        Correct, it's not '@68' for sure because the connection was outbound.

        What you're saying makes sense. Since the client side has an open state, the server can reach it on that client IP and source port outbound. That's actually clever.

        That will be a good test. I will expect it to fail too. I'll try later and report back.

        However, do you have any ideas on the inaccurate "bytes" on the rule state details?

        And why I see the "matchaddr failed" errors on both sides now?

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          @kevindd992002 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:

          matchaddr failed

          Yeah that should not be there. Do you have more that one peer defined?
          https://redmine.pfsense.org/issues/11502

          Steve

          K 1 Reply Last reply Reply Quote 0
          • K
            kevindd992002 @stephenw10
            last edited by

            @stephenw10

            Not at all. I only have one peer serup on both sides.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Hmm ๐Ÿค”

              K 1 Reply Last reply Reply Quote 0
              • K
                kevindd992002 @stephenw10
                last edited by

                @stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:

                Hmm ๐Ÿค”

                Can I file it as a bug?

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Yes, if you have details there and can replicate it.

                  1 Reply Last reply Reply Quote 0
                  • K
                    Kuser @kevindd992002
                    last edited by

                    @kevindd992002

                    I think I'm seeing the same behavior.
                    My setup might be a bit different but I have two netgate appliances: SG-3100 & SG-5100 and site2site wireguard vpn setup according to the howto. After disabling the WAN inbound firewall rules for 51820 on both devices and even killing states the link still comes online.

                    Since disabling the rules didn't work I set an explicit reject instead of allow, but connection still comes up... So it seems wireguard doesn't care about my WAN rules.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by stephenw10

                      That is expected if both sides have a remote IP and there in nothing NATing in between them. Both ends open an outbound UDP state with 51280 as the source and destination port. The traffic arriving from the other side can use that open state to connect.

                      This should be a new thread in the WireGuard or Firewall subs at this point. It's no longer IPSec related at all. ๐Ÿ˜‰

                      Steve

                      K 1 Reply Last reply Reply Quote 1
                      • K
                        Kuser @stephenw10
                        last edited by

                        @stephenw10
                        Thanks for the answer, not my intention to hijack the post. It just seemed relevant to the WG related questions. You are correct both sides have remote IP defined, but also explicit firewall WAN -rules to reject the connection.

                        Is this expected, even though I restarted one of the firewalls (e.g no active states)

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          If the reject rules are inbound they won't do anything over the default block rule. The default outbound allow rules will still allow the state to open on each end letting the traffic enter from the remote side.

                          Steve

                          K 1 Reply Last reply Reply Quote 0
                          • K
                            Kuser @stephenw10
                            last edited by

                            @stephenw10

                            Thanks again for the clarification, so this basically means that the WAN inbound rules as in howto are not necessary at all in this scenario?

                            https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2s.html

                            Wish you a great day.

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              There is no harm in adding them to the specific remote IPs and it may allow the tunnel to come up faster. Without then it can only establish once both sides are sending outbound traffic.

                              Steve

                              K 1 Reply Last reply Reply Quote 0
                              • K
                                kevindd992002 @stephenw10
                                last edited by

                                @stephenw10 said in (IPsec outbound NAT to interface address) Reply traffic destination IP not being translated back to original source IP:

                                There is no harm in adding them to the specific remote IPs and it may allow the tunnel to come up faster. Without then it can only establish once both sides are sending outbound traffic.

                                Steve

                                Does that mean both sides can be behind a CGNAT device (WAN interface is private IP) and the WG tunnel can still be established because both ends will just open a state when they initiate an outbound connection?

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  Unlikely.
                                  It would work as long as they were both using dyndns to give the other something to open a state to and the provider is not using source port randomisation. They probably are though.

                                  Steve

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