Feature Request: Wireguard over VRF

RouterOS General
1

According to VRF’s supported features list Wireguard is not yet supported.
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328206#VirtualRoutingandForwarding(VRF)-Supportedfeatures

I would like to request to add support for Wireguard to be able to use a VRF on the peer endpoint address, much like L2TP Tunnels using the ip@vrf_name format.

A use-case for such functionality would be for example when having two uplinks (eg DSL modem/routers) with conflicting IPs, that you cannot control/change their subnets (ie: both are in the 192.168.1.0/24 range with both gateways being .1 ). With VRFs you could do Wireguard tunnels on both uplinks without any conflicts.

Request ticket id: SUP-134306

2

Sweet, without VRF, there appears to be anarchy in the wireguard world, I support getting rid of anarchy, with chaos :slight_smile:

3

VRF support for Wireguard would be very appreciated.

4

Yes, please add VRF support for Wireguard!

I am not sure is this is 100% the same issue but I am seeing something odd:

  • I place one internet connection (interface + default route) into a VRF, say “wwan”
  • I add mangle+snat rules to force a specific wireguard endpoint (for tunnel “wg-wwan”) into this VRF
  • Now while the traffic doe this tunnel endpoint is in VRF wwan, I’d expect that the interface itself (wg-wwan) is in the main VRF
  • However, it seems wg-wwan is now also in VRF wwan which is completely undesired. I can ping the other address of the tunnel by adding “vrf=wwan” but when doing a normal ping or “vrf=main” I am getting a timeout
5

VRF support for Wireguard Interfaces! Please!

Wireguard - access from VRF
6

Why, network better – dont create overlapping subnets…
Wireguard works just fine, if done properly.
(caveat home user, dont support real work)

7

and also here … it does not have to do something with overlapping networks.
don’t always assume stuff without properly knowing any background.

8

Why post better – don’t post useless stuff just for the sake of posting…

If you don’t need VRF support in wireguard, good for you. Nobody cares for your non-needs.

Instead of being a wise-ass, either post a real working solution to my use case or GTFO.

It really gets on my nerves when people shit on others feature requests, when those requests won’t affect ANYTHING on their workflow.

I remember the same kind of behavior of other idiots when I was one of the first to ask for IPv6 NAT support.
In the end MikroTik did add it. Where are all those opposing it? Did it cause any problems to them? No. They were just being arrogant for “knowing better” for “IPv6 is all about end to end connectivity” and other bs like that.

If you don’t care about Wireguard VRF support, and if you don’t have valid criticism why it shouldn’t be implemented, please, stay away from my thread.

9

Tongue in cheek Chaos, of course you guys (real IT and not homeowners) are stuck with dealing with such stupid setups such as below:
A use-case for such functionality would be for example when having two uplinks (eg DSL modem/routers) with conflicting IPs, that you cannot control/change their subnets (ie: both are in the 192.168.1.0/24 range with both gateways being .1 ). With VRFs you could do Wireguard tunnels on both uplinks without any conflicts.

It would seem like a no brainer to be able to combine VRF and wireguard, but is the limiting factor that wireguard is NOT like other VPNs and doesnt have the flexibility to be used for VRF??
I dont know… but if your experience and knowledge says it should be fairly easy then one would expect MT to do so SOONEST, as it provides a unique capability that makes the competitive advantage of MT RoS, that much greater.

Time will tell… have you got an answer on your SUP yet???

10

14/Nov/23 11:01 AM

Hello,

Thank you for contacting MikroTik Support.
Its not supported, we will see if that could be implemented in the future.

Best regards,

11

so we wait.

cummulus (and therefore linux) is able to do that

12

This isn’t about “stupid setups” but rather about real-world problems that one inevitably encounters. Even though I only use VPNs personally - some for for work-related purposes - I’ve also faced the issue of overlapping subnets. However, that was neither stupid on my part nor on the part of the remote admin in any way.

I’d like to express my +1 for this feature request.

13

…or if one has “n” customers on a CCR cluster and customers are in their own VRF respectively
so in no case whatsoever it is remotely stupid

14

7.21beta2 seems to bring (limited, CLI only) support.
Who cares to make a test case ? :face_with_peeking_eye:

15

I would say Chaos is a likely candidate, he seemed very passionate about the capability. :slight_smile:
I would volunteer but I dont know how to create an overlapping subnet scenario, its not in my homeowner IT genes. :stuck_out_tongue:

16

I am not sure how this supposed to work. There’s not an explicit VRF setting available and the documentation hasn’t been updated yet.

/interface/wireguard/peers> set 7 [tab]
allowed-address     client-dns          client-keepalive       comment      endpoint-address     interface     persistent-keepalive     private-key     responderclient-address      client-endpoint     client-listen-port     disabled     endpoint-port        name          preshared-key            public-key

Going by how it’s configured on other places (ie: ip@vrf) it seems to be the correct way but it doesn’t recognize my VRF.

/interface/wireguard/peers> /ip vrf/print
Flags: X - disabled; * - builtin
0    name="dsl1" interfaces=ether3-dsl1
1  * name="main" interfaces=all

/interface/wireguard/peers> set 7 endpoint-address=xxx.xxx.xxx.xxx@dsl1
invalid or unexpected vrf or routing table value
17

I think this cannot be set on the individual peers, but is to be selected when you create / edit the WireGuard interface. Currently only with CLI because in WinBox the field is read-only:

image
image883×551 20.4 KB

With how WG works (the endpoint-address and endpoint-port of a peer is totally optional and can be fully overridden by whatever remote IP/port was used to perform the lastest handshake) I don't think that these two properties are the right place to choose the VRF.

It's probably only selectable per WG interface.

18

Doh! You are right. I agree, it doesn’t make sense to have VRF per peer, only per interface.

I am trying it now, but it seems that it ignores the return (Rx) packets (while they actually arrive to the router). Maybe it’s a config error on my side, since the router I am trying it on has a fairly complex config.

19

Ok, after recreating the interface from scratch, it worked.

Nice! :slight_smile:

1 Like
20

Clearly MT saw the business case for this and it was not difficult to implement/test. Impressive turn around time .