Wireguard tunnel with parts in different VRFs

General questions
,
1

Hi,

I’m trying to set up a wireguard tunnel with a tunnel terminating in one VRF but tunnel entry points in another. Is this a supported configuration in 1.3?

Version:          VyOS 1.3-rolling-202104120642
Release Train:    equuleus

Built by:         autobuild@vyos.net
Built on:         Tue 13 Apr 2021 03:42 UTC
Build UUID:       1058c7ab-3226-41b3-a5b1-ba014c8a413d
Build Commit ID:  e0a176ba819b4a

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  PC Engines
Hardware model:   apu2
Hardware S/N:     1119436
Hardware UUID:    Unknown

Copyright:        VyOS maintainers and contributors

I was using a similar setup in Junos/SRX with GRE tunnels and trying to achieve the same result with wireguard in VyOS.

here is an example of the config:

interfaces {
    ethernet eth1 {
        description WAN
        duplex auto
        hw-id XX:XX:XX:XX:XX:31
        speed auto
        vif 35 {
            description PROVIDER1-DSL
        }
    }
    pppoe pppoe0 {
        authentication {
            password xxxxxx
            user xxxxxx
        }
        default-route none
        description PROVIDER1-PPPOE
        no-peer-dns
        source-interface eth1.35
        vrf ISP-PROVIDER1
    }
    wireguard wg23 {
        address fe80::23/64
        address xxxx:xxxx:6000:fff9::a/64
        address xxx.xxx.128.120/31
        description tun-r2-r3
        ip {
            ospf {
                dead-interval 40
                hello-interval 10
                network point-to-point
                priority 1
                retransmit-interval 5
                transmit-delay 1
            }
        }
        mtu 1412
        peer r3 {
            address xxx.xxx.221.227
            allowed-ips ::/0
            allowed-ips xxx.xxx.0.0/0
            port 51820
            pubkey 9hM1lGIzCvsqM7s+9vqLvymljrNAqt3xKsJNo+g0X3w=
        }
        port 51820
        private-key default
    }
}
policy {
    route-map OSPF-DIST {
        rule 10 {
            action permit
            match {
                interface eth0
            }
        }
        rule 20 {
            action permit
            match {
                interface wg23
            }
        }
    }
}
protocols {
    bfd {
        peer xxxxx.tld {
            source {
                address xxx.xxx.128.120
            }
        }
        peer xxxx:xxxx:6000:fff9::b {
            source {
                address xxxx:xxxx:6000:fff9::a
            }
        }
    }
    ospf {
        area 0 {
            network xxx.xxx.128.0/24
        }
        log-adjacency-changes {
        }
        parameters {
            abr-type cisco
            rfc1583-compatibility
            router-id xxx.xxx.128.130
        }
        redistribute {
            connected {
                metric-type 2
                route-map OSPF-DIST
            }
        }
    }
    ospfv3 {
        area 0 {
            interface eth0
            interface wg23
        }
        parameters {
            router-id xxx.xxx.128.130
        }
	 redistribute {
		 connected
	}
    }
    static {
        route xxx.xxx.128.0/24 {
            blackhole {
            }
        }
        route6 xxxx:xxxx:6000::/48 {
            blackhole {
            }
        }
    }
    vrf ISP-PROVIDER1 {
        static {
            interface-route xxx.xxx.0.0/0 {
                next-hop-interface pppoe0 {
                }
            }
            interface-route xxx.xxx.221.224/29 {
                next-hop-interface pppoe0 {
                }
            }
            interface-route6 ::/0 {
                next-hop-interface pppoe0 {
                }
            }
            interface-route6 xxxx:xxxx:1001:2a::/64 {
                next-hop-interface pppoe0 {
                }
            }
            route6 xxxx:xxxx:f00f:aa00::/56 {
                blackhole {
                }
            }
        }
    }
}
vrf {
    name ISP-PROVIDER1 {
        table 200
    }
    name mgmt {
        table 100
    }
}

The goal is to isolate/hide static routes for tunnel endpoints from the main routing table. Essentially, the pppoe0 interface is in one VRF but wg23 is in another.

I was unable to make it work so far.

Thanks

2

This is the same type of setup I was asking about a couple of weeks ago for openconnect (ocserv) VPN. It’s often referred to as fvrf (frontdoor-vrf) and ivrf (inside-vrf).

I haven’t experimented with it though. Have you tried leaking routes between VRF’s?

3

I tried leaking routes but to no avail. For as long as both interfaces, i.e. inner and outer are in the same VRF it is no different than not having VRF at all. I ended up with a snowflake setup with a bunch of policies that gets me halfway through. But now I’m seriously thinking about scrapping it and going back to the solution with SRX and GRE tunnels. The idea with VyOS was about having a dynamic address on one end of the wireguard tunnel and that would let me upgrade the speed of my links but this idea is on hold for now.