Wireguard Remote access : impossible to connect a 2nd user

noconnor

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

Create a outbound NAT rule to NAT local LAN to the tunnel IP

Could you elaborate on that NAT rule? I've got an Android phone peer that will connect (I can see rx/tx packets) and I can see its DNS requests hit my firewall/tunnel IP but no connections ever return so I think that rule could be the key.

manicmoose

@jimp Aha! Thanks Jim!

Griffo

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

quasides

@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

AB5G

@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

noconnor

@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!

bruor

@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

jimp

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.

HuskerDu

@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

luisaraujo

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.

Griffo

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

luisaraujo

@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

quasides

@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

quasides

@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