"Recent posts
#1
Virtual private networks / Re: Wireguard VPN on mobile wh...
Last post by vimage22 - Today at 06:37:03 PMIn addition to the answer above, here is what is working on my side, with Wi-Fi connected or not. I do get a delay to one particular service on the LAN, but it is an unusual service.
Following this, Road Warrior, using Step 4(a).
And this for fdxx... ULA Generator
For "Instance", set:
In config on Peer GENERATOR:
Firewall: Rules [new]
Firewall: Settings: Normalization
Turn logging on everywhere and the use: Firewall: Log Files: Live View
In the earlier post, I meant to say "Allowed IPs", not "Endpoint address". In the setup above, I am not routing all traffic, just LAN. Also, DNS was important. For example, I could not simple resolve 'host', 'host.internal' was required. There might be a setting for this in the config, but not sure.
Following this, Road Warrior, using Step 4(a).
Code Select
Interfaces: [wg0] = true
And this for fdxx... ULA Generator
For "Instance", set:
Code Select
Tunnel address =
10.10.1.1/24 (different than LAN)
fdxx:xxxx:xxxx::1/64 (unique to LAN) (starts with fd, not fe, see ULA above)
In config on Peer GENERATOR:
Code Select
Endpoint: As you have already, vpn.domain
Allowed IPs:
x.x.x.x/24 (LAN)
10.10.1.1/24 (WG)
fdxx:xxxx:xxxx::/64
[ISP Prefix]::/64 (not sure if this is required)
Address
10.10.1.2/32
fdxx:xxxx:xxxx::2/128
DNS: fdxx:xxxx:xxxx::1
Firewall: Rules [new]
Code Select
Description: WG_FW_Rule
Invert: Unchecked
Interface: WAN
Quick: Checked
Action: Pass
Direction: in
Version: IPv4+IPv6
Protocol: UDP
Invert Source: Unchecked
Source: any
Source Port: any
Invert Destination: Unchecked
Destination: "WAN address"
Destination Port: 51820
Code Select
Description: WG_Router_Rule_wg0
Invert: Unchecked
Interface: wg0
Quick: Checked
Action: Pass
Direction: in
Version: IPv4+IPv6
Protocol: any
Invert Source: Unchecked
Source: "wg0 net"
Source Port: any
Invert Destination: Unchecked
Destination: "LAN net", "wg0 net"
Destination Port: any
Firewall: Settings: Normalization
Code Select
Description: "WireGuard MSS Clamping v4-v6"
Interface: wg0
Direction: any
Protocol: any
Source: any
Source Port: any
Destination: any
Max mss: 1360
Turn logging on everywhere and the use: Firewall: Log Files: Live View
In the earlier post, I meant to say "Allowed IPs", not "Endpoint address". In the setup above, I am not routing all traffic, just LAN. Also, DNS was important. For example, I could not simple resolve 'host', 'host.internal' was required. There might be a setting for this in the config, but not sure.
#2
26.1 Series / Re: Rules [new] && Rules?
Last post by Monviech (Cedrik) - Today at 06:30:41 PMAt least when 26.7 is out, then you can remove it.
#3
26.1 Series / Re: Rules [new] && Rules?
Last post by olluz - Today at 06:17:16 PMthanks for the reply, but sorry that I don't understand fully understand what you mean.
I've migrated all old rules to the new.
Now I have an empty "rules" entry and rules [new] containing all the rules.
How and when can I remove the old entry ?
I've migrated all old rules to the new.
Now I have an empty "rules" entry and rules [new] containing all the rules.
How and when can I remove the old entry ?
#4
26.1 Series / Re: Rules [new] && Rules?
Last post by Monviech (Cedrik) - Today at 05:49:50 PMOn the roadmap there is a rules plugin so you can remove the old rules at some point:
https://opnsense.org/roadmap/
https://opnsense.org/roadmap/
#5
26.1 Series / Re: Options to stabilize prefi...
Last post by Monviech (Cedrik) - Today at 05:43:19 PMI use my own daemon for this, which proxies the router advertisements from the ISP.
That means there is no truth besides the ISP, but it also means you won't have IA_PD and DHCPv6. You proxy the same SLAAC on-link prefix to all interfaces. (only SLAAC means no DHCPv6 quirks)
I never have any issues even if the WAN is flakey since it's transparent.
https://docs.opnsense.org/manual/ndp-proxy-go.html
Just an alternative approach to this all.
That means there is no truth besides the ISP, but it also means you won't have IA_PD and DHCPv6. You proxy the same SLAAC on-link prefix to all interfaces. (only SLAAC means no DHCPv6 quirks)
I never have any issues even if the WAN is flakey since it's transparent.
https://docs.opnsense.org/manual/ndp-proxy-go.html
Just an alternative approach to this all.
#6
26.1 Series / Rules [new] && Rules?
Last post by olluz - Today at 05:42:41 PMWhat are the plans regarding the two menu entries?
Will these be merged to one and when?
Wouldn't it have made sense to remove the old entry once the rules are migrated?
Thanks in advance.
Will these be merged to one and when?
Wouldn't it have made sense to remove the old entry once the rules are migrated?
Thanks in advance.
#7
26.1 Series / Re: Options to stabilize prefi...
Last post by OPNenthu - Today at 05:19:17 PMtl/dr; we are missing an option to prevent RA daemons from prematurely deprecating a prefix that is still active but has been temporarily dropped from interfaces due to some power loss event or modem reboot.
#8
26.1 Series / Options to stabilize prefix fr...
Last post by OPNenthu - Today at 05:15:05 PMI thought I'd revisit this topic in 26.1 to see if any new developments (maybe in and around dhcp6c?) can help here.
WAN is set to DHCPv6 with "Request prefix only" for IPv6. This gets distributed via RAs to clients doing SLAAC.
Problem: When either the lease is lost or the WAN flaps, this causes the RA daemon (radvd or dnsmasq) to send a message with preferred lifetime=0 to deprecate the prefix. The issue is that in many cases the prefix is not actually lost. It's just that the ISP has issued a reboot command to the modem, such as for periodic maintenance. When the modem comes back up and we get a new or renewed lease, the same prefix is given to OPNsense.
The problem now is that clients have already marked the prefix as invalid so even if they receive subsequent RAs for the same with new valid & preferred lifetimes, they refuse to generate new temporary addresses and the latest one remains in 'deprecated' state. The client falls back to the stable GUA for outbound connections, if it's available, else would lose IPv6 connectivity altogether.
A new temporary address is never created until/unless the client interface is reset or the client is rebooted.
'radvd' has an option 'DeprecatePrefix' which can be turned off, but this doesn't help in this scenario. It only prevents the prefix deprecation when the RA daemon (or OPNsense) is being shut down or restarted.
OPNsense has an option under Interfaces->Settings (advanced mode)->Prevent release, but this only tells the ISP to hold the lease.
My question is, does 26.1 bring any additional capabilities that we can leverage to stabilize the prefix on WAN for transient events like modem power loss or reboots? I'm thinking we could have an option to tell the system that it should not drop prefixes from the interfaces within some configurable interval, say 5 minutes, in case the same prefix is seen again shortly? That way the RA daemons won't notice its temporary loss and won't send a deprecation event.
Thoughts?
WAN is set to DHCPv6 with "Request prefix only" for IPv6. This gets distributed via RAs to clients doing SLAAC.
Problem: When either the lease is lost or the WAN flaps, this causes the RA daemon (radvd or dnsmasq) to send a message with preferred lifetime=0 to deprecate the prefix. The issue is that in many cases the prefix is not actually lost. It's just that the ISP has issued a reboot command to the modem, such as for periodic maintenance. When the modem comes back up and we get a new or renewed lease, the same prefix is given to OPNsense.
The problem now is that clients have already marked the prefix as invalid so even if they receive subsequent RAs for the same with new valid & preferred lifetimes, they refuse to generate new temporary addresses and the latest one remains in 'deprecated' state. The client falls back to the stable GUA for outbound connections, if it's available, else would lose IPv6 connectivity altogether.
A new temporary address is never created until/unless the client interface is reset or the client is rebooted.
Code Select
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:xx:xx:xx:77:cd brd ff:ff:ff:ff:ff:ff
inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute br0
valid_lft 74228sec preferred_lft 74228sec
inet6 2601:xx:xxxx:3163:423d:7f49:624f:8fb2/64 scope global temporary deprecated dynamic
valid_lft 86379sec preferred_lft 0sec
[...]
inet6 2601:xx:xxxx:3163:xxxx:xxx:xxxx:xxx/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86379sec preferred_lft 86379sec
inet6 fe80::xxxx:xxxx:xxxx:fb89/64 scope link noprefixroute
valid_lft forever preferred_lft forever
'radvd' has an option 'DeprecatePrefix' which can be turned off, but this doesn't help in this scenario. It only prevents the prefix deprecation when the RA daemon (or OPNsense) is being shut down or restarted.
OPNsense has an option under Interfaces->Settings (advanced mode)->Prevent release, but this only tells the ISP to hold the lease.
My question is, does 26.1 bring any additional capabilities that we can leverage to stabilize the prefix on WAN for transient events like modem power loss or reboots? I'm thinking we could have an option to tell the system that it should not drop prefixes from the interfaces within some configurable interval, say 5 minutes, in case the same prefix is seen again shortly? That way the RA daemons won't notice its temporary loss and won't send a deprecation event.
Thoughts?
#9
26.1 Series / Re: Can the Aliases be shown a...
Last post by Monviech (Cedrik) - Today at 05:00:18 PMThat is already fixed on master and will be released soon.
#10
26.1 Series / Re: Can the GUI stop refreshin...
Last post by Monviech (Cedrik) - Today at 04:59:46 PMIf it is in Rules [new] that will be fixed at some point.
