OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: Gauss23 on September 27, 2020, 02:15:14 pm
-
I was testing a new OPNsense installation (20.7.3). On the WAN interface there are 2 IPs, one via DHCP and one statically added as virtual IP.
Configurred WireGuard on port 51820.
Added a firewall rule to allow incoming packets to port 51920 on the WAN interface.
When I connect to the primary IP connection is coming up.
Connecting to the virtual IP is not successful. I see an incoming packet to the virtual IP on the WAN interface (port 51820), which is accepted. But WireGuard then seems to answer with the wrong IP. I see the outgoing packet from the primary IP and source port 51820. This is of course not accepted by the other side.
Is there a chance to set the interface WireGuard should listen to/answer from?
Thank you.
Edit: tried to fix it with outbound NAT, rewriting connections coming from the primary ip on port 51820 to the virual ip. But this doesn´t work either. Tried with and without tatic port checked.
-
Ok, solved it now by adding an inbound NAT rule (port forward).
Forwarding incoming connections destined to the virtual IP to the primary IP with the same port.
In any case it would be nice to use WireGuard with virtual IPs without this port-forward.
-
There is currently no solution for FreeBSD, sorry
-
Thank you for your feedback.
By using the inbound port forward I achieve what I wanted to.
-
And what about packets leaving the Firewall in other direction?
-
Of course this only works for my road-warrior setup. Site-2-Site won´t work with a virtual-ip as source. Hope to see that in the future.
OPNsense seems to be smart enough to track incoming packets handled by this port forward and is sending out returning packets from the virtual-ip
-
Ok, solved it now by adding an inbound NAT rule (port forward).
Forwarding incoming connections destined to the virtual IP to the primary IP with the same port.
In any case it would be nice to use WireGuard with virtual IPs without this port-forward.
This should be in the default settings once the wizard is there. Took me many hours to figure this out and yet the solution is so simple. Why is it so difficult for WG to work with VIPs while OpenVPN has no trouble (and no special NAT rules)?
-
Because the go port has an own implementation of interface handling.
Let's see how it works different when kernel implementation is out
-
Thanks for explaining the right direction. Yep, there was also many hours of investigation "what is wrong" on my side. Seems that it's still not working out of the box right now (Oct-2021: WireGuard kernel module seems to be submitted to FreeBSD 13.1 or 14.x and there is pfSense "still" on FreeBSD 12.1).
-
But you can install it on opnsense, and if you do, it seems to work.
-
Yeah, the package can be installed by:
pkg install wireguard-kmod
Note of course the warnings about it being under development and still “experimental” at this stage
Unfortunately development seems to have stalled for the last few months: https://git.zx2c4.com/wireguard-freebsd/
-
I cannot add the inbound port forwarding in case of a HA cluster. The rule would need to read
Virtual-Address:51820 --> WAN_Address:51820
But I can only enter literal addresses or pick aliases in the UI.
I would expect if I create the rule like that, both HA cluster members would get their respective WAN_Address in that rule.
Kind regards,
Patrick