By default, if an interface is configured as dhcp, VyOS gets the default gateway and updates the system route table. “dhcp-options no-default-route” can avoid this.
Is it somehow possible to still create this default gateway but not in the main routing table but somewhere else?
Background: I need source routing (packets from certain address range should go over a different default gateway). To implement this nicely, main main routing table (which includes OSPF routes, static routes, interface routes etc) should NOT have a default gateway set. I place the default gateways in separate routing tables and then set up a policy that first attempts the main routing table and then the respective table with the default route – based on the condition. If I would know the gateway (if it would be static) I would just manually put it into a table. However, since it’s an unknown IP I can’t just “dhcp-options no-default-route” option.
Hope my issue is clear.
Hi @c-po Thanks again. While this works, it actually creates lots of headaches. I was thinking it would place the default route into another routing table (which I can later reference) and that’s it. But it seems VRFs are way more far-reaching than I thought (isolating interfaces, processes etc).
Now, if I assign my WAN interface to “vrf_dsl” as you suggested, my SSH server and wireguard connection are not longer accessible because they are in the default VRF
For SSH I could at least do set service ssh vrf vrf_dsl … but then SSH is not accessible from other interfaces any longer. And for other local processes, including the wireguard tunnel I cannot even specify a VRF.
For SSH and some other services (SNMP) you can use vrf bind-to-all. For wireguard I’m not seeing a way to bind it to a particular interface. I’m assuming it is an unbound service so it should listen on all interfaces/vrfs. Do a netstat to see how it is listening.
Thanks @acosgrove ! Phew, this indeed makes things work! Not only SSH but also wireguard.
In this moment I am happy … but I’m sure very soon I will realize something else is broken …
What does set vrf bind-to-all to exactly and in particular? Does it have any impact on which routing tables are chosen?
EDIT: Ok it would have been too nice…
Now pings and stuff work but I cannot connect to any host on the internet via TCP. How can that be? And given I have no firewall configured yet, how can there be a difference between ping and, say, telnet?
Do you see any issues with my config below if I want to achieve:
DSL uplink on eth0.2 with dynamic IP assignment and NAT
A wireguard tunnel 192.0.2.227/31 peertopeer 192.0.2.226/31 which routes various PUBLIC subnets within 192.0.2.0/24
All traffic (local and forwarded!) should first consult routes from attached interfaces, static routes and OSPF
All traffic which does not have a source from 192.0.2/24 should be routed via DSL default gateway
All traffic which does have a source from 192.0.2/24 should use a default gateway back via the wireguard tunnel (“next-hop 192.0.2.226”)
set interfaces ethernet eth0 vif 2 address 'dhcp'
set interfaces ethernet eth0 vif 2 vrf 'vrf_dsl'
set interfaces ethernet eth0 vif 3 address '10.227.79.2/24'
set interfaces loopback lo
set interfaces wireguard wg0 address '192.0.2.227/31'
set interfaces wireguard wg0 ip ospf authentication md5 key-id 1 md5-key '***********'
set interfaces wireguard wg0 ip ospf cost '100'
set interfaces wireguard wg0 ip ospf dead-interval '40'
set interfaces wireguard wg0 ip ospf hello-interval '10'
set interfaces wireguard wg0 ip ospf network 'point-to-point'
set interfaces wireguard wg0 ip ospf priority '1'
set interfaces wireguard wg0 ip ospf retransmit-interval '5'
set interfaces wireguard wg0 ip ospf transmit-delay '1'
set interfaces wireguard wg0 peer vultr0 address '***********'
set interfaces wireguard wg0 peer vultr0 allowed-ips '0.0.0.0/0'
set interfaces wireguard wg0 peer vultr0 port '51821'
set nat source rule 100 outbound-interface 'eth0.2'
set nat source rule 100 translation address 'masquerade'
set policy local-route rule 101 destination '0.0.0.0/0'
set policy local-route rule 101 set table 'local'
set policy local-route rule 102 destination '0.0.0.0/0'
set policy local-route rule 102 set table 'main'
set policy local-route rule 103 destination '0.0.0.0/0'
set policy local-route rule 103 set table '171'
set policy local-route rule 103 source '192.0.2.0/24'
set policy local-route rule 104 destination '0.0.0.0/0'
set policy local-route rule 104 set table '170'
set protocols ospf area 0.0.0.0 network '192.0.2.0/24'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '10.227.1.2'
set protocols ospf passive-interface 'eth0.2'
set protocols static table 171 route 0.0.0.0/0 next-hop 192.0.2.226
set system config-management commit-revisions '100'
set system conntrack modules ftp
set system conntrack modules h323
set system conntrack modules nfs
set system conntrack modules pptp
set system conntrack modules sip
set system conntrack modules sqlnet
set system conntrack modules tftp
set system console device ttyS0 speed '115200'
set system host-name 'TestGate1'
set system syslog global facility all level 'info'
set system syslog global facility protocols level 'debug'
set system time-zone 'America/Los_Angeles'
set vrf bind-to-all
set vrf name vrf_dsl table '170'
This seems to work but I was often already at the point where I thought it’s working and then something else broke / stopped working …
Also, what I am somewhat confused is set policy local-route. It seems this generates rules visible in ip rule show. That should apply to all traffic, not just local one! Is this a mistake in the documentation?
I would suggest setting allowed-ips to those exact public subnets instead of 0.0.0.0/0 (unless you are in control of the other side as well).
Policy and nat rule numbers are not related so you don’t have to sequence them together, that might help keeping you from confusing yourself (and others ).
On the local-route rule numbers become important though. These do correspond to the kernel ip rule table:
Your rule 101 and 102 are actually already in the kernel’s ip ruleset as 32765 and 32766, but you are effectively moving it up to the top and everything is going to match on these two without anything else being evaluated. These are treated like firewall rules, first match wins.
).