Correction #14511
open
Dynamic Routing over WireGuard
0%
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
| 12_33_pm.png (112 KB) 12_33_pm.png | |||
| 12_34_pm_Eastern.png (102 KB) 12_34_pm_Eastern.png | |||
| ping test.png (48.9 KB) ping test.png |
Updated by Jim Pingle 10 months 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.
Updated by Mike Moore 10 months 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.
Updated by Jim Pingle 10 months 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)?
Updated by Mike Moore 10 months 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.
Updated by Mike Moore 10 months 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
Updated by Mike Moore 10 months 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
Updated by Mike Moore 10 months ago
- 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
Updated by Mike Moore 10 months ago
Hi Jim,
Did you manage to test my thesis in a lab?