hey guys, i guess it isn't a common problem. i think i fixed it by changing the MSS and MTU to 1420 on the Wireguard interface. hope this may help someone in the future.

@bob-dig I will use wireguard as the primary with failover to openvpn and setup a setup openvpn to deal with the country exception. shame, seems wireguard does perform better on the same h/w are access

Ok - disregard the above post. If I could delete it, I would. It it turns out what I am trying to achieve works flawlessly. I had another problem in my wg config (with the firewall rules) that was causing my icmp pings to not return, which I assumed was a wg issue.

@jarhead that did it. added the RoadWarrior tunnel ip to the allowed ip on parents peers. thanks man, that was easy!!

@keyser said in Wireguard Site-to-Site Setup - Errors on Interface:

@tman222 Just out of curriosity: What boxes are on either end of that tunnel? I’m looking for what throughput can be expected for the SG-2100 ARM based boxes, but no-one seems to know :-)
(With 900mbps+ I know you are not 😂)

Hi @keyser - hardware on both sides fairly powerful (at least as far as firewalls concerned): System on one side is driven by a Xeon D-1518 CPU, System on the other side has a Intel Core i3 10100 CPU. Bear in mind that those results are from a single stream iperf3 test using default settings (i.e. large 1500 byte packets) and that the site to site latency is only a few milliseconds.

The service has nothing to do with the contents of the firewall state table.

Look over all the links in my previous reply, it's all explained there. It's not a WireGuard issue it's a fundamental aspect of stateful firewall behavior.

@nomad0 said in State of Wireguard package?:

I would love to know what the projected timeline for making this a production-worthy package is.

pfSense package experimental do not mean underlying WireGuard is experimental.
Please correct me someone if I'm wrong.

OpenVPN isn't necessarily "constant" in that way, it occasionally has to renegotiate as well.

WireGuard does not work the way you imply. It is for all intents and purposes connectionless. There may be a handshake but it's completely transparent. The VPN is always "active" and any packet that tries to use it will handle that negotiation in the background if it hasn't had a recent handshake and so on.

There isn't any sense of it being "disconnected" where traffic would take some other path.

Ok, it's working now, I forgot to add a rule on the appropriate LAN interface to allow connections on the Wireguard port.

I'm sorry about that.

@knightzhang625 gfw blocked wireguard

@thondwe said in Wireguard Firewall Rules:

Assume the benefit of assigning would come into play with multiple tunnels with a need for different rules then? e.g. Test + Production? Or when using a site-to-site setup??

Exactly. And how often do you have multiple remote access tunnels on the same system? Usually one would just make one RA tunnel with a big enough subnet for however many users they would need. So no real need for an interface.
But site to sites definitely benefit from the separate rules.

@sprout0002 the same thing is occuring with me trying to set it up with NordVPN. Wireguard generates the wrong public key for the private key I'm entering. Did you find a fix or way to enter your public key from proton?

@reza-mnp - settings / enable wireguard - that is it done.

@koenh No problem.
Glad you got it fixed and believe me, the Wireguard wording is confusing at best!