see https://redmine.pfsense.org/issues/11302

@periko said in Peer for each mobile client?(SOLVED): @virgiliomi thanks, question answer. Maybe that feature will for pf+, I had seen that feature on Linux groups. That has nothing to do with plus or not, the QR code logic is already there. Just read the posts from jimp: https://forum.netgate.com/post/960960 Long story short, they are working on it, but it's not that "simple" as just create a QR code as WG treats every peer the same so it's not just a "client export" thingy but the exporter has to be flexible as to the settings the user wants the device to have.

Thanks @virgiliomi, setting DNS to 10.6.210.1 has resolved the issue. Though I'm still seeing CLOSED:SYN_SENT against Transmission, but this I guess something else.

@ab5g Sounds good, thanks!

I copied this from the WireGuard documentation: This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT. I think by saying “a keepalive packet is sent to the server endpoint” they must mean the public IP address because on the pfSense GUI the Endpoint address is the public one and the Peer WireGuard Address is used to describe the peers tunnel address.

@dhiru Yes, agreed - and similar to the link above from @AB5G. There is a way to do this in the webConfigurator as well (you can set MSS inside the interface). I tried it, and it works ... and also fixes my issue, thanks! What's very odd, I can see the MSS webConfigurator setting works (based on tcpdump captures). But when I upgraded from 2.5-RC to 2.5 => it no longer seems to be needed. Huh? Thanks!

@beachbum2021 disregard, apparently there's already a thread on this subject.

@p1erre That's pretty cool. I don't have a WireGuard endpoint to play with so thanks for testing it. It kind of negates the point of using WireGuard for slight it's speed benefit over openVPN, but still that's pretty cool.

Please create a bugreport: https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html

Well I'm an idiot. You CAN use a FQDN in the peer configuration. Way to go Netgate!

https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2s.html In General Values Tunnel Subnet should be 10.15.210.0/24 not 10.6.210.0/24 ? -Rico

@ab5g I went through all the rules again and found an incorrect interface specified. All is working now, thanks a lot for the help. Now that it's working, I played around a bit an noticed I don't actually need the NAT rule to talk to my LAN (just the WireGuard firewall rule seems to be enough). Is there some additional reason for me to add the NAT as well?

@stephenw10 Thank you, before I do anything going to run the new 2.5RC build "as is" a few days just to to make sure there is no fall out from the upgrade. Currently up with new build just under 5 hours and not seeing any issues but still would like to give it a day or two before attempting the WG transition. Thank you again for the info

@chuckm2000 If the Wireguard tunnel is up then its routing on the pi. What you need to do it to NAT the remote clients on the pi such that for the local LAN it looks like the traffic is coming from the pi. For instance I have the following on my pi . cat /etc/wireguard/wg0.conf [Interface] Address = 10.100.100.50/32 PrivateKey = xxxxxxxxx= PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] PublicKey = Pxxxxxc= AllowedIPs = 10.100.100.0/24,192.168.1.0/24 Endpoint = 58.182.47.98:51820 P.S: I am not on QRZ.

@jimp said in "Service" Restart Button, Auto Restart (WireGuard): Going to need a lot more information than "it doesn't work". Completely understand ... LOL! Just wanted to mention it, to see if you had also observed the same thing. I'll try to check routes, etc. the next time I reboot, get that info to you (unfortunately, can't reboot right now). Thanks!

@jimp I was in fact talking about having pfsense present a qr code you could scan on your phone. But it would be handy to have that same data as something you can cut/paste in a text format for joining two pfsense boxes. I have less of an idea what that would look like.

Policy based routing, one of the most asked questions on this forum, suggest you do a search. https://forum.netgate.com/search?term=policy%20based%20routing&in=posts&matchWords=all&sortBy=relevance&sortDirection=desc&showAs=posts https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html?highlight=policy#

Adding 0.0.0.0/0 in WG Allowed IP for the Peers does not add it to the routing table and will not interfere with the routing table. You can validate this by looking at Diagnostics > Routes. https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/routing.html

@ab5g Will do, thanks!

It's because in this particular case we had been testing Wireguard internally before it was announced on CE. The bug was noted there and a report opened. Steve