Correction #14511: Dynamic Routing over WireGuard - pfSense Docs - pfSense bugtracker

Actions

Copy link

Correction #14511

open

Dynamic Routing over WireGuard

Added by Mike Moore over 1 year ago. Updated over 1 year ago.

Status:

Feedback

Priority:

Normal

Assignee:

Category:

WireGuard

Target version:

Start date:

Due date:

% Done:

Estimated time:

Description

https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/routing.html#dynamic-routing

Please add a note that when performing dynamic routing the Allowed IPs need to be set to 0.0.0.0/0. If not you will be busy adding remote LANs which defeats the purpose of using a routing protocol.
What is interesting about setting the allowed IP to 0/0 is that the pfsense route table doesnt modify and start pointing the default to the WG gateway. On other platforms, you have to take care when doing this.

Files

Download all files

12_33_pm.png (112 KB) 12_33_pm.png		Mike Moore, 06/27/2023 04:35 PM
12_34_pm_Eastern.png (102 KB) 12_34_pm_Eastern.png		Mike Moore, 06/27/2023 04:35 PM
ping test.png (48.9 KB) ping test.png		Mike Moore, 06/27/2023 04:36 PM

History
Notes
Property changes

Actions

Copy link

Updated by Jim Pingle over 1 year ago

Status changed from New to Feedback

Unless something changed, if there is only one peer on the tunnel it used to assume that since it didn't have to decide where to send traffic with only one peer around (e.g. you didn't need any Allowed IPs entries at all).

It's possible something changed since the docs were written/tested, but it's worth testing with no entries at all (which is what the docs suggest there), even if you have the peer address in there that shouldn't be needed with a single peer so you can try removing it.

Actions

Copy link

Updated by Mike Moore over 1 year ago

Its possible things have changed.
This is a site2site tunnel with a configuration with only 1x peer. I am doing BGP
When I put the peer address only I cannot route across. The routes appear in the BGP Rib table so we know the remote is advertising. But it never makes it into the pfsense route table.
Once i place the 0/0 allowed IP in there it seems the logic allows those routes to be sent from frr (bgp) and into the pfsense route table.

Actions

Copy link

Updated by Jim Pingle over 1 year ago

Mike Moore wrote in #note-2:

Its possible things have changed.
This is a site2site tunnel with a configuration with only 1x peer. I am doing BGP
When I put the peer address only I cannot route across. The routes appear in the BGP Rib table so we know the remote is advertising. But it never makes it into the pfsense route table.
Once i place the 0/0 allowed IP in there it seems the logic allows those routes to be sent from frr (bgp) and into the pfsense route table.

What about if you remove both 0/0 and the peer address (so zero entries for allowed IPs)?

Actions

Copy link

Updated by Mike Moore over 1 year ago

File 12_34_pm_Eastern.png 12_34_pm_Eastern.png added
File 12_33_pm.png 12_33_pm.png added
File ping test.png ping test.png added

Routing fails. I am uploading the pics to show.
Moving back to 0.0.0.0/0 restores connectivity.

Actions

Copy link

Updated by Mike Moore over 1 year ago

Another post.
As you can see the routes exist within the BGP dameon process

sh ip bgp neighbors 10.6.106.2 received-routes
BGP table version is 174, local router ID is 192.168.50.254, vrf id 0
Default local pref 400, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
> 172.25.0.0/24    10.6.106.2               1             0 65520 ?
> 192.168.70.0/24  10.6.106.2               1             0 65520 ?

But pfSense route table has no idea about it.

/root: netstat -rn
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 162.193.210.1 UGS ix3
9.9.9.9 link#23 UHS ovpnc2
10.6.106.0/30 link#25 U tun_wg2
10.6.106.1 link#10 UHS lo0
10.6.106.5 link#10 UHS lo0
10.6.106.6 link#21 UH ipsec3
10.6.106.9 link#10 UHS lo0
10.6.106.10 link#22 UH ipsec4
10.10.10.1 link#10 UH lo0
10.11.112.0/24 link#23 U ovpnc2
10.11.112.127 link#10 UHS lo0
10.28.169.0/24 link#24 U ovpns1
10.28.169.1 link#10 UHS lo0
10.30.1.0/24 10.6.106.10 UG1 ipsec4
10.30.1.0/24 10.6.106.6 UG1 ipsec3
10.30.2.0/24 10.6.106.10 UG1 ipsec4
10.30.2.0/24 10.6.106.6 UG1 ipsec3
69.117.27.120 162.193.210.1 UGHS ix3
71.131.58.25 162.193.210.1 UGHS ix3
127.0.0.1 link#10 UH lo0
162.193.210.0/23 link#8 U ix3
162.193.210.96 link#10 UHS lo0
172.25.0.0/24 10.6.106.2 UG1 tun_wg2
172.26.0.0/24 link#13 U tun_wg1
172.26.0.1 link#10 UHS lo0
172.27.0.0/24 link#27 U tun_wg0
172.27.0.1 link#10 UHS lo0
172.28.0.5 link#26 UH ipsec2
172.28.0.6 link#10 UHS lo0
192.168.3.0/24 link#20 U lagg0.3
192.168.3.1 link#10 UHS lo0
192.168.11.0/24 link#18 U lagg0.11
192.168.11.1 link#10 UHS lo0
192.168.14.0/24 link#16 U lagg0.14
192.168.14.1 link#10 UHS lo0
192.168.15.0/24 link#17 U lagg0.15
192.168.15.1 link#10 UHS lo0
192.168.17.0/30 link#19 U lagg0.17
192.168.17.1 link#10 UHS lo0
192.168.23.0/24 link#15 U lagg0.23
192.168.23.1 link#10 UHS lo0
192.168.50.0/24 link#1 U igc0
192.168.50.100 link#10 UH lo0
192.168.50.254 link#10 UHS lo0
192.168.70.0/24 10.6.106.2 UG1 tun_wg2
192.168.100.0/24 172.28.0.5 UG1 ipsec2
193.122.161.56 162.193.210.1 UGHS ix3
193.122.174.109 162.193.210.1 UGHS ix3

Actions

Copy link

Updated by Mike Moore over 1 year ago

Correction. The route just made it in there when i did my screencap. I reverted back to 0.0.0.0/0 in Allowed IP

Actions

Copy link

Updated by Mike Moore over 1 year ago

The only other caveat i have found is if the tunnel is up using a non-zero allowed IP address and you have established a dynamic routing neighborship and then you change to 0/0 allowed IP, you must clear the bgp neighbor peering.

clear ip bgp 10.6.106.2

Even though the routes learned of the remote LAN is in the BGP dameon and its not in the pfsense route table, once you clear the neighbor and it comes back UP, everything operates normally.

Maybe this can be coded differently but thats another ticket. For now, the documentation should reflect that in order to pass all traffic (rely on dynamic routing routes) the allowed IP should be set to 0.0.0.0/0

Actions

Copy link

Updated by Mike Moore over 1 year ago

Hi Jim,
Did you manage to test my thesis in a lab?

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

pfSense » pfSense Docs