Hi,
I've got a Wireguard Connection working just fine. I am trying to limit the source to the whole network. The IP public addresses are provided via dyndns. IPv4 is fine as its the gateway anyway, but for IPv6 I get 2001:DB8:1:2:a:b:c:d/128. Is there a way to create an alias to get 2001:DB8:1:2::/64. I know about the alias type IPv6 Host, but that's the interface and not the network part.
Would be a bit easier for the dyndns update part.
An alias of type "Network(s)" takes addresses with prefix lengths.
I'll check this out. Does they strip the interface from an address given by dyndns?
Quote from: HolgerKuehn on March 01, 2025, 06:03:45 PMDoes they strip the interface from an address given by dyndns?
I don't understand that question. An alias of type "Network(s)" takes entries like 192.168.0.0/24 or 2001:DB8:1:2::/64. That's all there's to it. No idea how that might relate to dyndns. You place the networks manually into the alias. That's what aliases do and what I thought you asked about.
Hi,
what I mean is the following.
I've an DynDNS entry for IP 2001:DB8:1:2:a:b:c:d/128.
I want to use this in a rule, BUT ONLY the network portion 2001:DB8:1:2::/64 of it. This seems to be missing in Aliases as far my tests show.
I've one client that updates the dyndns, but want all devices from that network access, so I can not use the specific IPv6-IP from the updating device.
Or am I missing something obvious here?
If that DynDNS entry is internal to your OpnSense (i.e. not any external DNS name), then it will have to be something that is attached to one of your interfaces. There are internal, automatic aliases for the networks connected to those interfaces named __interface_network, which contain both the respective IPv4 and the IPv6 networks. You could use those internal aliases in rules. Then again, that is equivalent to allowing or blocking anything that is related to that specific interface, anyway.
However, usually you would use a more specific "Dynamic IPv6 Host" in firewall rules. You can use a specific host part in firewall aliases and also in Dynamic DNS entries (advanced -> Dynamic ipv6 host). This applies to inbound connections.
The only case, where an unspecific alias like the one you ask for would be needed, is when you want an outbound rule (e.g. for privacy extensions), but that automatically applies to any host on the same subnet as well, so no need for a DynDNS alias, either.
What you cannot do is refer to any DNS name outside of your OpnSense, i.e. use an external DNS name with a mask applied in a firewall rule.
That would be a typical scenario for a VPN.
What type of rule do you want to create / what is your use-case? The reason I ask is that I do not see any.
Quote from: meyergru on March 02, 2025, 09:41:51 AMWhat you cannot do is refer to any DNS name outside of your OpnSense, i.e. use an external DNS name with a mask applied in a firewall rule.
That would be a typical scenario for a VPN.
What type of rule do you want to create / what is your use-case? The reason I ask is that I do not see any.
To limit the source of WireGurad Peer to one known network, eg. /64 mask. Setting it in Endpoint address of the WireGuard Peer config.
The same goes for services like Plex or Jellyfin exposed over reverse proxy to family. There I know the network address (from the dyndns entry of the router) and want limit the source of any appropriate rules to those known networks (e.g. all devices behind the known router) and not the entire internet.
Quote from: HolgerKuehn on March 02, 2025, 03:06:34 PMTo limit the source of WireGurad Peer to one known network, eg. /64 mask.
Then create an alias of type "Network(s)" with that network as content and use that in your firewall rule permitting e.g. 51280 in.
When you think about it, you will find that this is probably a bit paranoid:
If you allow "the whole internet" to access a VPN endpoint, a potential attacker still must have a key to connect. But I get that you do not want anybody to try that in the first place. There are other ways you can have that:
1. You can use ASN aliases to limit access at least to the IP ranges of the (known) ISP legitimate connections will originate from. That way, you rule out big percentages of "the whole internet".
2. If the VPN partner is on "real" IPv4 (i.e. not CG-NAT), you could use a DynDNS entry as alias, because you do not have to mask the address. For this purpose, it might even work if the partner is behind CG-NAT - you only do not rule out other ISP customers who use the same outlet IPv4.
3. If the VPN partner is on IPv6, then how would anyone even find your (single) Wireguard IPv6? Even if an attacker knows your prefix, you have full control over the lower 64 bits of the IPv6 using "request prefix only" and specifying the interface id on your WAN interface. That is the main reason why there are no IPv6 port scans (BTW: the port is arbitrary as well). The only thing you have to make sure is that the DNS name pointing to your IPv6 stays hidden.
The reason I bring up the last point is because of these pitfalls:
a. do not host public services on the same IP / DNS name. If you need other services, use other interface IPv6s for those by letting them pass from WAN. Plus, use another DNS entry.
b. use Wildcard certificates when a reverse proxy is in use. That way, you can use any host name without having LetsEncrypt leaking specific names, thereby enabling differentiating between public and hidden names.