@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

Generally speaking, you can configure it as a peer to a remote provider. It's all in how you set it up. See https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html for an example.

I haven't tried using those values so I'm not certain if they would actually work as expected. I'd rather err on the side of caution and make users enter them.

@vbman213 That link helps, appreciate it!

@vbman213 said in Routing Issue when Using 'WireGuard' interface group versus individual wireguard interfaces: For testing purposes I have a simple pass all rule on both WG0 and WG1 OPT interfaces. However, when I created a test remote access wireguard tunnel and created a generic pass all rule on the built-in WireGuard Interface Group, this broke the scenario above. As soon as I delete the generic pass all rule on the WireGuard interface group, the scenario above starts working again. I can work around this by creating a more specific rule in the WireGuard interface group rules to only pass traffic sourced from the remote access tunnel subnet, but I still find it weird that a pass all rule in the wireguard group breaks things, but a pass all rule in the individual WG OPT interfaces doesn't. Rules on the group tab don't get reply-to so return routing follows the routing table. Rules on the assigned interface tab get reply-to so packets matching those rules will exit back out the interface they entered. That's how it's always worked on any interface type, not new to WireGuard.

@dem said in Wireguard S2S Tunnel Gateway IP?: @jimp It sounds like the field can only take one address, either IPv4 or IPv6, since "address" and "gateway" are singular in the description. I noticed that after I replied. I changed it to say "addresses" and added "(comma separated)" which should help.

Yeah there is nothing like that in the wg output on FreeBSD. Not that I've seen yet anyhow.

WireGuard is a learning experience for all of us! We're still refining the GUI labels and documentation to hopefully make all this more clear.

How it works with HA is still a bit up in the air -- we're still testing/refining that. See my notes on https://redmine.pfsense.org/issues/11302#note-3 for example

OK don't blame VirtualBox, blame me. I think the issue was that I didn't have "Hardware Clock in UTC Time" set in VirtualBox so the system clock was jumping when NTP kicked in which disrupted something, perhaps crypto-related. Sorry for my error.

@vbman213 said in Specify outbound interface (priority) for WG: Would policy routing This Firewall in a floating rule be used to push WG tunnel traffic over a preferred gateway or gateway group? There seems to be some discussion on Reddit suggesting that this is also possible too instead of changing the default gateway. Maybe, but that's always been a bit iffy -- It's worth trying, but if you do, carefully check the state table and packet captures to ensure that the traffic is exiting the correct interface with the correct address. A problem you might get into there is that it leaves, say, WAN2 with the source set to WAN1. Outbound NAT could work around that if it happens, but it's kinda ugly. The problem is that pf policy routing influences packets that are already fully formed and on an interface, whereas the routing table also influences source address selection for UDP packets. So sure policy routing can change how a packet exits, but it can't change the address from which WireGuard sends the packet.

wg interface config ipv4 and ipv6 address, eg: 10.0.0.102/32, 2a0d:2400:12:c::102/128 but the interface only has ipv4.

'Real soon now!' But yeah, it is close. We had to disable the public snapshots while we got all the changes in order and there are still a few things the need to be resolved. Steve

Yes. With multiple peers you need to set Allowed-IPs to determine which peer WG routes to. https://www.wireguard.com/#cryptokey-routing But to avoid confusion 'Endpoint' is a WG term the defines the external IP. Steve

Hello! I am testing on : 2.5.0-DEVELOPMENT (amd64) built on Mon Jan 25 09:13:15 EST 2021 FreeBSD 12.2-STABLE Using Firefox 84.0.1 (64-bit) I dont see any form field validation happening and the code in wg_validate_post and wg_validate_peer will let you enter just about anything you want. I made a redmine issue with some stopgap code that might help. https://redmine.pfsense.org/issues/11311 John

@griffo said in [what speeds can you get with WG on a On my old Celeron based test router, I always hit a limit of ~110mbits on OpenVPN. So far i've gotten up to 200mbit by switching to Wireguard. see https://redmine.pfsense.org/issues/10311