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

Wireguard Remote access : impossible to connect a 2nd user

Scheduled Pinned Locked Moved WireGuard
25 Posts 11 Posters 5.8k 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.
  • G
    Griffo @manicmoose
    last edited by Griffo Feb 20, 2021, 9:23 AM Feb 20, 2021, 7:28 AM

    I get the same thing.

    With the below config, nothing will flow. Delete the second peer, and peer 1 starts to work straight away.

    interface: wg1
      public key: 6iEV/lkOxZTe7naSF3LvLl+M9KfMDqdxxxxx=
      private key: (hidden)
      listening port: 51821
    
    peer: 6GfLrKXZ8K1RMQGuh7ewJS7jaOj4K9wFz8fxxxxx=
      allowed ips: 192.168.70.67/32
    
    peer: tKr3Dow7LN9FWWAmBU1za9PHN2fiPANUUuxxxxx=
      allowed ips: 192.168.71.66/32
    
    
    1 Reply Last reply Reply Quote 0
    • Q
      quasides @p1erre
      last edited by Feb 20, 2021, 11:13 AM

      @jimp
      your answer while technically correct created some confusion as the whole proposition is wrong.

      people think allowed IPs in the peerlist are equivalent to pushroutes in openvpn.

      THIS IS NOT THE CASE

      wireguard dont push routes (it cant) it also has no server or clients, it sees everything as a peer - even tough we see PFsense as a server and clients as clients.

      to clarify: allowed IPs in the peerlist is a routing table, route allowed ips to this peer.
      that also means every client that wants to route 0.0.0.0 via your pfsense (server) needs to set allwoed ips 0.0.0.0 in his local peerlist while the allowed ips on pfsense stays emtpy

      yes for connecting site to site this is a nightmare as you would need to set all subnets of all peers you wanna route from and to into every peer list of all clients.
      and you as a server have no control what client is doing.
      no push anything

      1 Reply Last reply Reply Quote 0
      • A
        AB5G @noconnor
        last edited by Feb 20, 2021, 11:58 AM

        @noconnor Check

        • System > Routing > Default gateway IPv4 is set to WAN_DHCP (or whatever you are using)
        • Have you created the WG interface by going to Interface > Assignments and selecting wg0 tunnel ?
        • Next on this newly created interface. Goto Firewall > Rules > WG > select source WG interface then destination any allow. P.S you'll see another Menu for WireGuard when you goto Firewall > Rules. Don't enter rules there - leave that blank
        • Lastly for NAT - goto Firewall > NAT > outbound > select Hybrid Outbound NAT > Add new rule
          Interface WG, source LAN subnet of Firewall source port any dest any dest port any Nat address WG address

        4e188361-beb9-4a79-a054-9514dbf339e5-image.png

        N 1 Reply Last reply Feb 20, 2021, 6:55 PM Reply Quote 1
        • N
          noconnor @AB5G
          last edited by Feb 20, 2021, 6:55 PM

          @ab5g Thanks!

          I set the gateway and created the interface. Fwiw, I think it also seems to work if the FW rules are set on the "WireGuard" tab too. My understanding is that the "Wireguard" tab rules apply to all WG interfaces, and the WG# interface rules apply just to that interface/tunnel. For one tunnel I haven't seen a difference in function.

          Thanks for elaborating on the NAT rule. Helped a lot!

          1 Reply Last reply Reply Quote 0
          • B
            bruor @jimp
            last edited by bruor Mar 3, 2021, 2:30 PM Mar 3, 2021, 2:30 PM

            @jimp Just to make sure I don't get surprised by a change in config validation. In wireguard right now I've got 3 sites connected.

            in order to get things working, each peer's allowed list has: <peer_ip>/32,0.0.0.0/0

            Is this considered an invalid configuration?

            @jimp said in Wireguard Remote access : impossible to connect a 2nd user:

            You cannot have multiple peers when one is using 0.0.0.0/0 and/or ::/0 -- It's an invalid configuration as WireGuard has no way to tell what traffic goes to which peer.

            Input validation will prevent this in future releases: https://redmine.pfsense.org/issues/11465

            1 Reply Last reply Reply Quote 0
            • J
              jimp Rebel Alliance Developer Netgate
              last edited by Mar 3, 2021, 2:42 PM

              One tunnel with multiple peers on pfSense can't have 0.0.0.0/0 in the peer entries on the pfSense tunnel configuration.

              The remote peer configurations (not pfSense, but whatever the remote clients are) can each have 0.0.0.0/0 in their configurations to send all traffic through their VPN.

              The "Allowed IPs" list is "which IP address can I reach through this VPN?"

              It is not "What should this peer be told to reach though this VPN" since WireGuard has no mechanism to push settings to clients or tell them how to operate.

              A lot of people get confused by that last part since they are used to how OpenVPN and IPsec operate in various modes where they list things that get pushed to clients, but WireGuard doesn't work that way.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              H 1 Reply Last reply Mar 3, 2021, 4:39 PM Reply Quote 1
              • H
                HuskerDu @jimp
                last edited by HuskerDu Mar 3, 2021, 4:39 PM Mar 3, 2021, 4:39 PM

                @jimp Thanks, that was my misunderstanding.

                I've finally managed to setup remote access for several peers with one "instance" of wg on pFsense.

                Remote config file look like this

                [Interface]
                PrivateKey = PrivateRemote1234567890+++
                Address = 172.16.2.2/32
                DNS = 10.0.0.1
                
                [Peer]
                PublicKey = PublicPfSense0987654321----
                PresharedKey = PreSharedPfSense0987654321----
                AllowedIPs = 0.0.0.0/0
                Endpoint = 8.9.10.11:51820
                

                Centrally, the associated Allowed IP is

                172.16.2.2/32
                
                1 Reply Last reply Reply Quote 0
                • L
                  luisaraujo
                  last edited by Mar 15, 2021, 1:07 AM

                  Sorry guys, im stuck here also.
                  after creating more than one peer, on console if i query wg the answer is:

                  Unable to access interface wg0: Cannot allocate memory
                  

                  also just able to transfer data with the 1st peer, all the others, the client connects to pfSense WG server, but doesnt transfer any data between client and pfSense network.

                  changing the allowed ips to 0.0.0.0/0 on the client its a no go for me because i just want to forward the Pfsense subnet traffic and nothing else, over the tunnel. Even so doesnt work also.

                  Who has more than a peer working, can please help, to explain, how did solved this?

                  thanks in adance, help is appreciated.

                  G 1 Reply Last reply Mar 15, 2021, 2:28 AM Reply Quote 0
                  • G
                    Griffo @luisaraujo
                    last edited by Mar 15, 2021, 2:28 AM

                    @luisaraujo Can you show the configs on pfsense of the peers? Normally it errors when people have overlapping "allowed IP" ranges on different peers.

                    L 1 Reply Last reply Mar 15, 2021, 10:26 AM Reply Quote 0
                    • L
                      luisaraujo @Griffo
                      last edited by Mar 15, 2021, 10:26 AM

                      @griffo thank you for the reply:

                      server side:

                      interface: wg0
                        public key: xw+fQgc**************Hi7b2WRNVuGpnc=
                        private key: (hidden)
                        listening port: 51820
                      
                      peer: OuQlCN2OTy********************epbr8kGIJhA=
                        allowed ips: 192.168.168.0/24
                      
                      peer: fBgCDQejJDET***********************4/YD4=
                        allowed ips: 192.168.0.0/24
                      

                      client side:

                      [Interface]
                      PrivateKey = qJec0SvTJ4**********************Um3bQ5W4=
                      Address = 192.168.168.2/32
                      DNS = 1.1.1.1
                      
                      [Peer]
                      PublicKey = xw+fQgcFPC***********************uGpnc=
                      AllowedIPs = 192.168.0.0/24
                      Endpoint = aaaaaaaaaaa.ddns.net:51820
                      PersistentKeepalive = 20
                      
                      Q 1 Reply Last reply Mar 19, 2021, 2:14 AM Reply Quote 0
                      • Q
                        quasides @luisaraujo
                        last edited by Mar 19, 2021, 2:14 AM

                        @luisaraujo
                        aaaaaaaaaaa.ddns.net is wrong thats my address

                        not but seriously

                        how often we have to write this here.
                        allowed IP´s is A ROUTING TABLE (crypto routing by wg) nad its a security table (both at the same time)

                        so that means: everting you put in allowed ips on the peer section will be routed to that peer.

                        so the client should have in his allowed IP list only the subnets on server side (0.0.0.0 only if server should also be internet gateway)
                        and on the server side you put only allowed IPs you want to go on the client side.

                        so lets say server has 192.168.0.x/24 subnet
                        peer (client) A has 172.16.20.x/24 subnet
                        peer (client) B has 172.16.50.x/24 subnet

                        so if we want all subnet communicating with each other we would have to put it like

                        server

                        peer: OuQlCN2OTy********************epbr8kGIJhA= (peer A)
                          allowed ips: 172.16.20.0/24
                        
                        peer: fBgCDQejJDET***********************4/YD4= (peer B)
                          allowed ips: 172.16.50.0/24
                        

                        client A

                        [Peer]
                        PublicKey = xw+fQgcFPC***********************uGpnc= (server)
                        AllowedIPs = 192.168.0.0/24, 172.16.50.0/24
                        Endpoint = aaaaaaaaaaa.ddns.net:51820
                        PersistentKeepalive = 20
                        

                        client B

                        [Peer]
                        PublicKey = xw+fQgcFPC***********************uGpnc= (server)
                        AllowedIPs = 192.168.0.0/24, 172.16.20.0/24
                        Endpoint = aaaaaaaaaaa.ddns.net:51820
                        PersistentKeepalive = 20
                        
                        Q 1 Reply Last reply Mar 19, 2021, 2:21 AM Reply Quote 0
                        • Q
                          quasides @quasides
                          last edited by quasides Mar 19, 2021, 2:23 AM Mar 19, 2021, 2:21 AM

                          @quasides
                          just a future warning, as we can see we basically define a static routing table on wireguard level.
                          that also means any change in topology has to be manually updated on each and every client.

                          automated updated of routing tables like with OSFP dont work, WG has still no implementation for that and while OSFP could change routers (pfsense) it would be overwritten or at least meaningless as WG is gonna override it and or at least use it internally based on manual config

                          edit: i do understand the confusion tough. not only is WG concept with like no pushiung config a very wierd one, but the naming of the parameter allowed IP is beyond stupid.
                          just translate it to something sane like "remote network" which what it basically means

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                            This community forum collects and processes your personal information.
                            consent.not_received