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

    Policy-based Routing (outbound) and port forwarding (inbound) through WG tunnel

    Scheduled Pinned Locked Moved
    WireGuard
    7
    30
    3.0k
    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.
    • A
      AB5G @kevindd992002
      last edited by

      @kevindd992002 I have exactly the same issue here - https://forum.netgate.com/topic/160335/unsolved-possible-bug-wireguard-routing-weirdly/29
      I'll try your fix and see if it works.

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

        @ab5g said in Policy-based Routing (outbound) and port forwarding (inbound) through WG tunnel:

        @kevindd992002 I have exactly the same issue here - https://forum.netgate.com/topic/160335/unsolved-possible-bug-wireguard-routing-weirdly/29
        I'll try your fix and see if it works.

        Yeah, I did see your thread at one point when I was trying to reaearch on this issue. Let me know if my workaround solves your issue too. If it does, then I'd be inclined to say that this is a bug but I'll try capturing packets on the outer tunnel (WAN) now and see if I notice something there. @jimp one thing to point out here is that I can easily reproduce this behavior from both sides.

        H A 2 Replies Last reply Reply Quote 0
        • H
          hypnosis4u2nv @kevindd992002
          last edited by

          @kevindd992002 https://youtu.be/mXG0RShQbaw

          Not sure if this helps.

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

            @hypnosis4u2nv said in Policy-based Routing (outbound) and port forwarding (inbound) through WG tunnel:

            @kevindd992002 https://youtu.be/mXG0RShQbaw

            Not sure if this helps.

            I just finished watching video but it's not applicable to the issue in this thread. The video explains routing through the tunnel from devices that have IP's in the transit network. This is the same as when I apply the outbound NAT workaround.

            Without the workaround, the source IP's do not get translated (both PBR andport forward issues) and that's where problem comes in. The routing works for only one source IP (the first ones I ever tested with).

            I hope that makes sense.

            H 1 Reply Last reply Reply Quote 1
            • A
              AB5G @kevindd992002
              last edited by

              @kevindd992002 That doesn't work for me. I'll put some more effort on it tomorrow.
              If you remove the /32 NAT rule and capture packets on the WG interface - do you see what I captured on my tcpdump (the source getting translated to the tunnel IP) or you don't even see that ?
              For me the NAT rule seemed to work, just that the packets don't leave the WAN for some reason.

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

                @ab5g said in Policy-based Routing (outbound) and port forwarding (inbound) through WG tunnel:

                @kevindd992002 That doesn't work for me. I'll put some more effort on it tomorrow.
                If you remove the /32 NAT rule and capture packets on the WG interface - do you see what I captured on my tcpdump (the source getting translated to the tunnel IP) or you don't even see that ?
                For me the NAT rule seemed to work, just that the packets don't leave the WAN for some reason.

                Did you mean when keeping the /32 outbound NAT rule?

                1. With the NAT rule in place, yes I do see the source getting translated to the local WG interface IP and leaves the WAN and shows in the remote WG interface. Here's an example:

                Site B open state:

                85df323c-f187-4140-89e5-3b6b6f0bb4fe-image.png

                Site A open state:

                94983edc-1521-4b3f-a149-4c0b0f7b24d6-image.png

                That public IP is an external IP from a torrent peer.

                1. Without it, no SNAT happens and the packets do not leave the WAN interface.

                Site B open state:

                1b0db0cf-ad5e-409f-a334-a4b58dc54609-image.png

                Site A NO open state:

                82331efe-46d9-4cd0-a560-744e6cb3532a-image.png

                However, I noticed that from the same source and to different destination IP's through the tunnel, some are working and some are not! Here's proof of that:

                Site B open state:

                6e9101a3-7a13-44fa-9a3a-6034693fc67d-image.png

                Site A open state:

                efab353a-7e32-4b23-b997-a7ee1194756e-image.png

                So the problem seems to be "selective" or intermittent. It is not only isolated to one source IP working but other source IP's also work for different destination IP's, if that makes sense. And again, this weirdness is all solved with the outbound NAT rule workaround.

                A 1 Reply Last reply Reply Quote 0
                • H
                  hypnosis4u2nv @kevindd992002
                  last edited by

                  @kevindd992002 no problem, and yes if makes sense. Hoping that watching tutorials brings some idea of a what may be causing the issue that your experiencing. I was able track down issues to what I was experiencing due to watching an somewhat unrelated topic turned out to be an option that I didn't enable.

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

                    @hypnosis4u2nv right, thanks. Which option fixed your issue and how did it fix it? I'm curious.

                    H 1 Reply Last reply Reply Quote 0
                    • A
                      AB5G @kevindd992002
                      last edited by

                      @kevindd992002 said in Policy-based Routing (outbound) and port forwarding (inbound) through WG tunnel:

                      So the problem seems to be "selective" or intermittent. It is not only isolated to one source IP working but other source IP's also work for different destination IP's, if that makes sense. And again, this weirdness is all solved with the outbound NAT rule workaround.

                      That seems to be exactly my issue too - I don't know how to replicate it though. If you know how, can you raise a bug report please.

                      1 Reply Last reply Reply Quote 0
                      • H
                        hypnosis4u2nv @kevindd992002
                        last edited by

                        @kevindd992002 They were unrelated to Wireguard. I had connectivity and routing issues with OpenVPN after updating to 2.5.0. Certain settings that got carried over needed additional tweaks and changes to connect. Then I ran into a routing issue where everything was routing through the client even though I had policy based rules set. After watching some videos and reading on some older posts. I found the culprit and fixed it. It may help to read/watch an unrelated topic to point out something you overlooked.

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

                          Ok, I did more testing today and it looks the workaround I did was also hit and miss! It solved the problem with some of my clients but when I add new PBR's and port forwarding rules, they don't work again! And like I said, the problem is not isolated to source IP's. It's also affecting the same client but with different destination IP's. For example, I have this PBR:

                          63c7eb11-5570-4f3d-8b70-3976ee0345c3-image.png

                          When I was troubleshooting a few days ago, this was not working until I implemented that outbound NAT workaround, so I thought all is good. When it worked, the destination Alias had these host entries:

                          plex.tv
                          www.addic7ed.com

                          Today, I added a third host: news.newshosting.com and it never worked. So it's working for the first two but not for the new host. So go figure.

                          @AB5G I'll raise a bug report today.

                          A 1 Reply Last reply Reply Quote 0
                          • A
                            AB5G @kevindd992002
                            last edited by

                            @kevindd992002 try clamping the MSS under the WG interface to 1420 (if you have an Ethernet uplink and see if that improves things). I saw on a unrelated thread that the MSS was causing some sites not to load (It still does not explain why the NAT wouldn't happen) - worth a try. Leave the MTU to default.

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

                              @ab5g I also read about that workaround somewhere when I was researching on this but I thought it was unrelated to my issue. I'll give it a try.

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

                                @AB5G setting the MSS field to 1420 (max mss 1380) in the WG interface on both sides didn't really help. Did it solve anything for you?

                                A 1 Reply Last reply Reply Quote 0
                                • A
                                  AB5G @kevindd992002
                                  last edited by

                                  @kevindd992002 No it didn't - its a hit and miss (just like your's)

                                  1 Reply Last reply Reply Quote 0
                                  • X
                                    xparanoik
                                    last edited by

                                    This is somewhat related, but I changed my OpenVPN client for a wireguard tunnel, and in my PBR policy to route certain LAN clients through VPN I just switched the gateway from the old OpenVPN to the new WG one. Also updated my hybrid outbound NAT rules. Everything works just like it did before with OpenVPN.

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

                                      Filed a bug here.

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

                                        I'm using this WG package in pfsense 2.5.1 now and I have the same exact PBR issue! Do you guys have any progress with this? Or is it a pfsense issue?

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

                                          I solved it! I didn't realize that WG allowed IP's also acted as a firewall for destination IP's for outbound. So if you want to route destination=Internet through the tunnel, you would have to add 0.0.0.0/0 to the allowed IP's on Site B.

                                          WG reference: https://www.wireguard.com/#conceptual-overview

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post