Post by: Kieeps on January 17, 2021, 08:56:21 am
And will the plugin currently in opnsense move from userspace to kernel when it gets implemented? :-)
Post by: Greelan on January 17, 2021, 09:24:25 am
Post by: Kieeps on January 17, 2021, 09:26:59 am
Keep upnthe great work!
Post by: Greelan on January 17, 2021, 09:29:22 am
It will definitely have better performance
Post by: Greelan on January 17, 2021, 09:31:02 am
Post by: chemlud on January 17, 2021, 09:36:11 am
Post by: mimugmail on January 17, 2021, 11:24:50 am
Post by: franco on January 17, 2021, 04:29:33 pm
https://redmine.pfsense.org/issues/8786
;)
Cheers,
Franco
Post by: Greelan on January 17, 2021, 08:21:04 pm
Post by: JeGr on January 20, 2021, 01:13:58 am
With a new snapshot of pfSense 2.5pre incoming tomorrow and as it's based on 12.2 I suspect the Kernel module if_wg is (al)ready (to be) backported? So it shouldn't take long to bring it further to HardenedBSD I suspect :)
Looking forward to a new kernel space implementation and read speed benchmarks :D
Post by: mimugmail on January 20, 2021, 06:24:57 am
Post by: chemlud on January 20, 2021, 08:54:28 am
Post by: mimugmail on January 20, 2021, 08:56:26 am
Post by: JeGr on January 20, 2021, 02:45:26 pm
* It operates completely in the kernel
* Configuration is placed directly on the interfaces
* It has no concept of connections or sessions
* There is no “status” of the VPN (e.g. it isn’t considered up or down, it has no visible timers, etc.)
* It has no facilities for user authentication
* There is no service daemon to stop or start
* There is only minimal logging from the kernel
* It does not bind to a specific interface or address on the firewall, it accepts traffic to any address on the firewall on its specified port
As it is virtually "service- and status-less" logging would be hard to implement besides errors/messages from the kernel(module) itself. But that's only my understanding, mimugmail may be deeper into that :D
Post by: Patrick M. Hausen on January 20, 2021, 03:15:23 pm
Quote
* It has no concept of connections or sessionsThat's a feature.
* There is no “status” of the VPN
"Look, a packet matching my tunnel policy" --> Encrypt with peer's public key, encapsulate in UDP, send to peer instead. Is the peer alive? How the heck should I know?
"Look an encrypted packet" --> Does it come from a configured peer? Does it decrypt with my private key? OK, decrypt, de-encapsulate, throw into ip_input() again.
It's definitely more like GRE or IPIP than, say, OpenVPN. You can do something similar with IPSec, throw away all of ISAKM/IKE and phase 1 and just statically configure phase 2 SAs and keys. Similar result.
Post by: JeGr on January 20, 2021, 03:37:26 pm
I assumed it is ;) But I'm not so deep into the implementation itself to say "more logging is possible" :)
Post by: mimugmail on January 20, 2021, 03:43:33 pm
Post by: chemlud on January 20, 2021, 03:44:23 pm
https://www.wireguard.com/#conceptual-overview
... only option might be to log all packages for the FW-rule. Tried for the allow rule for the tunnel IP on the wiregurad FW-rules tab, but see nothing in live view.
PS: now I enabled logging for the allow rule on Wireguard FW-rules tab for one of the remote nets and I see the traffic flow.
But where to see these "keepalive = 10" packages? They should be going back and forth between the tunnel network IPs, or?
Post by: JeGr on January 20, 2021, 06:02:04 pm
It's a killer for CARP ... enterprise integration will be low .. lower than low :)
Ah because it binds on the interface instead of an actual IP? Makes sense, failover possibility is nonexistent that way.
Post by: Patrick M. Hausen on January 20, 2021, 06:39:56 pm
But I may stand corrected with respect to my last statement. There is this "last handshake" information, so there must be a little bit of keepalive checking, nonetheless. Possibly one can use that amount of state to force a CARP failover if necessary.
The rest can be pretty simple, IMHO, just use two boxes on both sides and two tunnels. Clients on either side throw their packets at the active node that forwards it through *its* tunnel to the other side. Provided that a keepalive check and failover is possible, there is no need to have *one* redundant tunnel as long as there is redundant connectivity.
Post by: mimugmail on January 20, 2021, 07:32:27 pm
Post by: Patrick M. Hausen on January 20, 2021, 07:37:39 pm
My idea was
Code: [Select]
Box 1a ------------ Tunnel 1 ------------ Box 1b
| |
| |
LAN a --- CARP Address CARP Address --- LAN b
| |
| |
Box 2a ------------ Tunnel 2 ------------ Box 2b
But back to the road warrior scenario.
There is not really a "client" and a "server" in WG. So the client would accept that packet from any IP address as long as the keys match. In that case the problem lies with the NAT gateway which will be in front of the "client" in most cases.
But if on the "server" side incoming packets to the CARP address are taken care of, why not NAT WG packets originating from the interface address to the CARP address?
Post by: JeGr on January 20, 2021, 10:30:45 pm
Ah ... I wasn't thinking road warrior, because without user authentication and IP address pool management this is not going to fly in a corporate environment, anyway.
My idea wasCode: [Select]Box 1a ------------ Tunnel 1 ------------ Box 1b
| |
| |
LAN a --- CARP Address CARP Address --- LAN b
| |
| |
Box 2a ------------ Tunnel 2 ------------ Box 2b
But back to the road warrior scenario.
There is not really a "client" and a "server" in WG. So the client would accept that packet from any IP address as long as the keys match. In that case the problem lies with the NAT gateway which will be in front of the "client" in most cases.
But if on the "server" side incoming packets to the CARP address are taken care of, why not NAT WG packets originating from the interface address to the CARP address?
Or put the routes out of WG and use the wg interfaces in a FRR/OSPF Setup with both sides watching their "other side" gateway IP so if one is down (because Box1a/b/WAN1 is down) then FRR should route via #2 - AFAIR that should be possible as long as one configures the WG interface as "non broadcasting" and add a manual entry for the Neighbor using the WireGuard interface address of the appropriate peer?
Post by: mimugmail on January 21, 2021, 07:05:46 am
I already had small success with outbound nat, but no chance to test on a ha cluster due to homeoffice :)
Post by: chemlud on January 21, 2021, 08:31:40 am
There is not really a "client" and a "server" in WG.
Yes and no, the client is the one who has no allow rule on WAN, so he has to initiate the traffic in outbound direction to make the tunnel happen
So the client would accept that packet from any IP address as long as the keys match.
No, the receiver checks both, key and IP to identify legitimate traffic:
"Once decrypted, the plain-text packet is from 192.168.43.89. Is peer LMNOPQRS allowed to be sending us packets as 192.168.43.89?"
https://www.wireguard.com/#conceptual-overview
Post by: JeGr on February 04, 2021, 10:38:54 pm
The problem is, there is no daemon to bind an interface. So when you send a packet to the client, you cant decide if the source is whether IP of Interface or CARP IP
@mimugmail: Just a heads up - perhaps one could have a look into the patched kernel module in Netgates Redmine Thread.
-> https://redmine.pfsense.org/issues/11354
Seems the patched ko actually recognizes and respects the destination address so incoming traffic e.g. on WAN1 will be responded via WAN1, WAN2 will get answers via WAN2 and packages to CARP IP seem to respond via CARP IP. Only problem open seems that a manually demoted CARP master (that's still active otherwise) is still sometimes getting packages but the other failover scenarios look good. So when implementing the kernel module mode - that could also bring a fix for using CARP and MultiWAN - or let's say for most cases. :)
Post by: mimugmail on February 04, 2021, 10:43:15 pm