"Recent posts
#1
26.1, 26,4 Series / NAT Migration Tool
Last post by Burthouse4563 - Today at 04:40:25 PMI just upgraded to 26.1.11_5 and performed firewall rule migration without issues. I went ahead and started looking at the NAT migration. I'm using manual NAT outbound rule currently. I exported my rules without issue. When I attempt to import, though, I get validation failed for every rule with the following error.
@uuid;"Invalid UUID offered (;1;0;0;1;wan...
I added a single manual rule to see what it was expecting and upon export got
1bdd4169-e821-40ba-98b0-83fdc10c8378;1;0;0;100;lan...
So clearly the new NAT rules are expecting more than what the old ones are exporting with regard to UUID.
Is this a known error, or will it be fixed in an upcoming release? I'd prefer not to manually input all rules; I will if I have to, but if this is going to get fixed, I'll wait.
Thanks to the team for what you do.
@uuid;"Invalid UUID offered (;1;0;0;1;wan...
I added a single manual rule to see what it was expecting and upon export got
1bdd4169-e821-40ba-98b0-83fdc10c8378;1;0;0;100;lan...
So clearly the new NAT rules are expecting more than what the old ones are exporting with regard to UUID.
Is this a known error, or will it be fixed in an upcoming release? I'd prefer not to manually input all rules; I will if I have to, but if this is going to get fixed, I'll wait.
Thanks to the team for what you do.
#2
General Discussion / swanctl config ok?
Last post by tbk49 - Today at 04:38:02 PMHaving some trouble with vpn where I'm running gre over ipsec, keep going back and forth between devices, have fully run out of ideas. Ipsec always establishes SAs, sometimes gre tunnels come up, most times they don't. I don't understand why. Anybody spot any obvious issues with swanctl.conf?
Also, I am setting the MTU in opsense to the MTU value reported by the gre tunnel in the peer device so they match. Also I add the MSS value as the same as MTU value (the help text says opnsense will do the subtraction automatically so you repeat the MTU value in the MSS field for auto clamping).
EDIT:
If I disable opnsense firewall, the gre tunnels come up. So I must be missing a firewall rule or two. Anyone know the absolute minimum firewall rules needed for ipsec and gre to ensure things work as expected?
Code Select
# This file is automatically generated. Do not edit
connections {
f4fc114c-2b90-4d48-be4a-7ffe139e61c5 {
proposals = aes256-sha256-ecp256
unique = replace
aggressive = no
version = 2
mobike = no
local_addrs = vpn.staticdnstest.net
remote_addrs = vpn.mine3.net
encap = yes
dpd_delay = 10
send_certreq = yes
send_cert = always
keyingtries = 0
local-1952c040-2c39-4763-820c-829b9a6304ed {
round = 0
auth = pubkey
certs = xxxxxxxxxxxxxx.crt
}
remote-f4f8cd49-443d-4c88-a71b-922d76de9ecf {
round = 0
auth = pubkey
certs = yyyyyyyyyyyyy.crt
}
children {
31a6653a-63c0-4c66-8b9b-5483d36d7b72 {
esp_proposals = aes256-sha256-ecp256
sha256_96 = no
start_action = none
close_action = none
dpd_action = clear
mode = tunnel
policies = yes
local_ts = 0.0.0.0/0
remote_ts = 0.0.0.0/0
rekey_time = 1800
updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 31a6653a-63c0-4c66-8b9b-5483d36d7b72
}
}
}
5af76a2v-2988-4186-9a25-fc4d1a57a173 {
proposals = aes256-sha256-ecp256
unique = replace
aggressive = no
version = 2
mobike = no
local_addrs = vpn.staticdnstest.net
remote_addrs = vpn.mine2.net
encap = yes
dpd_delay = 10
send_certreq = yes
send_cert = always
keyingtries = 0
local-2d1149ab-c11f-45d2-8d10-5d75e20222dc {
round = 0
auth = pubkey
certs = xxxxxxxxxxxxxx.crt
}
remote-51e086dc-fc53-48c9-92b2-089f0bd00e38 {
round = 0
auth = pubkey
}
children {
3c668bc7-46c2-443a-8980-e48c215d465e {
esp_proposals = aes256-sha256-ecp256
sha256_96 = no
start_action = none
close_action = none
dpd_action = clear
mode = tunnel
policies = yes
local_ts = 0.0.0.0/0
remote_ts = 0.0.0.0/0
rekey_time = 1800
updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 3c668bc7-46c2-443a-8980-e48c215d465e
}
}
}
}
pools {
ipsec-test-pool {
addrs = ::0/0
dns = 10.10.35.1
}
}
# Include config snippets
include conf.d/*.conf
Also, I am setting the MTU in opsense to the MTU value reported by the gre tunnel in the peer device so they match. Also I add the MSS value as the same as MTU value (the help text says opnsense will do the subtraction automatically so you repeat the MTU value in the MSS field for auto clamping).
EDIT:
If I disable opnsense firewall, the gre tunnels come up. So I must be missing a firewall rule or two. Anyone know the absolute minimum firewall rules needed for ipsec and gre to ensure things work as expected?
#3
26.1, 26,4 Series / Re: Help With DHCP, IPv6 and D...
Last post by WiteWulf - Today at 04:35:37 PMRFC 2132 states that:
So yeah, it's down to the client whether or not it respects the preference/order.
I believe macOS, Windows and Linux all respect the order given by the DHCP server, trying them in order, not parallel. I don't know about others, like iOS and Android. My PiHole is an adblocker, for convenience, not for filtering/blocking/censoring any other content, so I'm happy with this.
QuoteServers SHOULD be listed in order of preference
So yeah, it's down to the client whether or not it respects the preference/order.
I believe macOS, Windows and Linux all respect the order given by the DHCP server, trying them in order, not parallel. I don't know about others, like iOS and Android. My PiHole is an adblocker, for convenience, not for filtering/blocking/censoring any other content, so I'm happy with this.
#4
General Discussion / Re: When is inbound traffic, i...
Last post by tbk49 - Today at 04:34:09 PMQuote from: Seimus on July 02, 2026, 07:07:24 PMShow your rules.
Good?
#5
High availability / HA Cluster with a /30 CIDR for...
Last post by NEOSA - Today at 03:59:47 PMHi all,
Is it possible to set up an OPNSense environment as a high-availability HA Cluster with the following constraints:
- Having private-addressed public interfaces, whilst the public IP address is in a /30 CIDR block?
Example: 1.2.3.4/30 as the public IP address - ISP GAteawy = 1.2.3.5/20 - As it is therefore not possible to have a public IP address per interface in the HA Cluster group on WAN-type interfaces.
Here is the planned setup below, would like opinions if it is a valid setup : thanks in advance for feedback ;-)
To set up High Availability (HA) on OPNsense (via CARP), the official documentation typically states that you need 3 IP addresses in the same subnet: one for the Master, one for the Backup, and one shared Virtual IP (VIP). With a /30 subnet (which only provides 2 usable IP addresses), this standard method is mathematically impossible.
Fortunately, there is an excellent workaround: using the "IP Alias" mode combined with private addressing on the physical WAN interfaces.
Here is how to structure this configuration.
1. The Logical Architecture (The Concept)
The trick is to configure the physical WAN interfaces of your two OPNsense nodes with private IP addresses (for example, in a dedicated /24 or /29 subnet for the interconnection with your public router/gateway), and to set up a private CARP between them.
Then, you assign your single available public IP as an IP Alias attached to this private CARP VIP.
Addressing Schema
Imagine your provider's router (Gateway) has the public IP 1.2.3.5/30 and provides you with the IP 1.2.3.6/30. For the local interconnection, we will use the private network 192.168.100.0/29.
ISP Router / Gateway: 1.2.3.5/30 (Routes traffic to your block)
WAN Interconnection Network: 192.168.100.0/29
OPNsense Master (Physical WAN): 192.168.100.1
OPNsense Backup (Physical WAN): 192.168.100.2
CARP VIP (Virtual): 192.168.100.3
Virtual Public IP (IP Alias): 1.2.3.6 (carried by the CARP VIP 192.168.100.3)
2. Configuration Steps in OPNsense
Step 1: Configure Physical IPs and Private CARP
On the Master, assign the address 192.168.100.1/29 to the WAN interface.
On the Backup, assign the address 192.168.100.2/29 to the WAN interface.
Go to Interfaces -> Virtual IPs -> Settings.
Create a new Virtual IP of type CARP:
Interface: WAN
Address: 192.168.100.3 / 29
Virtual IP Password: [Your password]
VHID: [A unique identifier, e.g., 1]
Step 2: Add the Public IP as an IP Alias
This is where the magic happens to bypass the /30 limitation.
Still in Interfaces -> Virtual IPs -> Settings, create a new Virtual IP.
Choose the IP Alias type.
Interface: WAN
Address: 1.2.3.6 / 30 (Your single public IP)
Virtual IP Association: Select the CARP VIP you just created (192.168.100.3).
💡 Why does this work? The public IP Alias will "graft" itself onto the private CARP IP. When the Master is active, it takes ownership of both the private CARP IP and the associated public IP. If the Master goes down, the Backup instantly recovers the CARP VIP and the public IP Alias.
Step 3: Configure the Gateway and NAT
In System -> Gateways -> Single, ensure that your WAN's default gateway correctly points to your ISP router's IP (1.2.3.5).
In Firewall -> NAT -> Outbound, switch the mode to Hybrid or Manual.
Modify your outbound NAT rules (or create one) so that Internet-bound traffic does not use the physical interface IP (192.168.100.x), but rather the public IP Alias (1.2.3.6).
3. Important Points of Vigilance
The Upstream Router (ISP / Switch): The router providing your /30 subnet must be capable of routing traffic destined for 1.2.3.6 toward the CARP VIP 192.168.100.3. If it is a simple Layer 2 switch or bridge, ensure that the ARP protocol resolves correctly.
Synchronization (pfsync): Do not forget to configure a dedicated interface (often called DMZ or SYNC) for state table synchronization (pfsync) and configuration synchronization (XMLRPC) between your two nodes.
"Promiscuous" Mode: If your OPNsense instances are virtual machines (VMware ESXi, Proxmox, Hyper-V), you must enable Promiscuous Mode / MAC Address Spoofing on the vSwitches of both the WAN and LAN interfaces. Otherwise, the CARP protocol will be blocked."
Is it possible to set up an OPNSense environment as a high-availability HA Cluster with the following constraints:
- Having private-addressed public interfaces, whilst the public IP address is in a /30 CIDR block?
Example: 1.2.3.4/30 as the public IP address - ISP GAteawy = 1.2.3.5/20 - As it is therefore not possible to have a public IP address per interface in the HA Cluster group on WAN-type interfaces.
Here is the planned setup below, would like opinions if it is a valid setup : thanks in advance for feedback ;-)
To set up High Availability (HA) on OPNsense (via CARP), the official documentation typically states that you need 3 IP addresses in the same subnet: one for the Master, one for the Backup, and one shared Virtual IP (VIP). With a /30 subnet (which only provides 2 usable IP addresses), this standard method is mathematically impossible.
Fortunately, there is an excellent workaround: using the "IP Alias" mode combined with private addressing on the physical WAN interfaces.
Here is how to structure this configuration.
1. The Logical Architecture (The Concept)
The trick is to configure the physical WAN interfaces of your two OPNsense nodes with private IP addresses (for example, in a dedicated /24 or /29 subnet for the interconnection with your public router/gateway), and to set up a private CARP between them.
Then, you assign your single available public IP as an IP Alias attached to this private CARP VIP.
Addressing Schema
Imagine your provider's router (Gateway) has the public IP 1.2.3.5/30 and provides you with the IP 1.2.3.6/30. For the local interconnection, we will use the private network 192.168.100.0/29.
ISP Router / Gateway: 1.2.3.5/30 (Routes traffic to your block)
WAN Interconnection Network: 192.168.100.0/29
OPNsense Master (Physical WAN): 192.168.100.1
OPNsense Backup (Physical WAN): 192.168.100.2
CARP VIP (Virtual): 192.168.100.3
Virtual Public IP (IP Alias): 1.2.3.6 (carried by the CARP VIP 192.168.100.3)
2. Configuration Steps in OPNsense
Step 1: Configure Physical IPs and Private CARP
On the Master, assign the address 192.168.100.1/29 to the WAN interface.
On the Backup, assign the address 192.168.100.2/29 to the WAN interface.
Go to Interfaces -> Virtual IPs -> Settings.
Create a new Virtual IP of type CARP:
Interface: WAN
Address: 192.168.100.3 / 29
Virtual IP Password: [Your password]
VHID: [A unique identifier, e.g., 1]
Step 2: Add the Public IP as an IP Alias
This is where the magic happens to bypass the /30 limitation.
Still in Interfaces -> Virtual IPs -> Settings, create a new Virtual IP.
Choose the IP Alias type.
Interface: WAN
Address: 1.2.3.6 / 30 (Your single public IP)
Virtual IP Association: Select the CARP VIP you just created (192.168.100.3).
💡 Why does this work? The public IP Alias will "graft" itself onto the private CARP IP. When the Master is active, it takes ownership of both the private CARP IP and the associated public IP. If the Master goes down, the Backup instantly recovers the CARP VIP and the public IP Alias.
Step 3: Configure the Gateway and NAT
In System -> Gateways -> Single, ensure that your WAN's default gateway correctly points to your ISP router's IP (1.2.3.5).
In Firewall -> NAT -> Outbound, switch the mode to Hybrid or Manual.
Modify your outbound NAT rules (or create one) so that Internet-bound traffic does not use the physical interface IP (192.168.100.x), but rather the public IP Alias (1.2.3.6).
3. Important Points of Vigilance
The Upstream Router (ISP / Switch): The router providing your /30 subnet must be capable of routing traffic destined for 1.2.3.6 toward the CARP VIP 192.168.100.3. If it is a simple Layer 2 switch or bridge, ensure that the ARP protocol resolves correctly.
Synchronization (pfsync): Do not forget to configure a dedicated interface (often called DMZ or SYNC) for state table synchronization (pfsync) and configuration synchronization (XMLRPC) between your two nodes.
"Promiscuous" Mode: If your OPNsense instances are virtual machines (VMware ESXi, Proxmox, Hyper-V), you must enable Promiscuous Mode / MAC Address Spoofing on the vSwitches of both the WAN and LAN interfaces. Otherwise, the CARP protocol will be blocked."
#6
Tutorials and FAQs / [HOWTO] NordVPN Wireguard setu...
Last post by meyergru - Today at 03:41:17 PMThere are lots of (mostly incomplete) instructions on how to setup NordVPN on OpnSense scattered all over the forum. Also, there are instructions from NordVPN themselves, but they do not focus on Wireguard.
Also, I found that my setup failed a few days ago, because NordVPN obviously cancelled one of their rented servers (de1019.nordvpn.com) which happened to be the one I used until then.
Therefore, I took the effort to create a setup with a failover for a fixed set of clients. This setup also will behave as a "kill switch", i.e. that no client targeted by it can bypass the NordVPN setup and expose itself accidentally.
1. You have to create not one, but two so-called "Access Token" in the NordVPN customer dashboard by clicking on NordVPN on the left. Then, the link to enter the access token menu will be at the bottom of the page. Create to different tokens and be sure to note them, because they will not be accessible later on.
2. Once you have those tokens, you will need to create a private key for both of them. This can be done via 'curl -s -u token:<YOUR_TOKEN_HERE> https://api.nordvpn.com/v1/users/services/credentials | jq -r .nordlynx_private_key'.
3. For entry into WG instances, you will also need the corresponding public keys, which you can get via 'echo <YOUR_PRIVATE_KEY_HERE> | wg pubkey'.
4. If you followed along, you should now be in posession of two private/public key pairs pertaining to your NordVPN account. These are neccessary to discriminate between the two connections, you cannot do this using only one key pair.
5. Using these informations, you can now add two Wireguard instances under VPN:Wireguard->Instances. Add these as "NORDVPN_INSTANCE1" and "NORDVPN_INSTANCE2", use different, free "Listen Ports" (these can be arbitrary, but must not be used anywhere else) and 10.5.0.2/16 as "Tunnel address" (yes, both are the same!).
6. Obtain two NordVPN server names from their API via 'curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=2" | jq -r ".[]|.hostname"'. This will give you two names like "xx999.nordvpn.com".
7. Next, create two Wireguard peers under VPN:Wireguard->Peers. Name them NORDVPN_PEER1 and NORDVPN_PEER2, and choose different NordVPN server names obtained in the previous step for bot peers (e.g. 'deXXX.nordvpn.com'). Use "public key" = "m0tej5P6pYfBivkJc8yRV4KqQXmM81AChLlzlsOSjSs=", "Allowed IPs" = "0.0.0.0/0", "Endpoint port" = 51820, "Keepalive Interval" = 30. Choose NORDVPN_INSTANCE1 as Wireguard instance for NORDVPN_PEER1 and NORDVPN_INSTANCE2 for NORDVPN_PEER2 - use only one per each peer!
8. Next, you can check VPN:WireGuard:Status. You should see both the peer and the instance come up as green for both instance/peer pairs if Wireguard is enabled.
9. Now, assign those two Wireguard interfaces names via Interfaces:Assignments. Name them NORDVPN1 and NORDVPN2. Select each of them under Interfaces and check the "Enable Interface" and "Prevent Interface Removal" boxes.
10. Create an alias with the definition of all clients, that should go through NordVPN only. Name that NORDVPN_CLIENTS. I prefer to use a network group alias that includes MAC aliases for individual machines, see also the hint about IPv6 at the end of this article.
11. Create two SNAT rules for each of the two NordVPN interfaces under Firewall:NAT:Source NAT with:
12. Create two Gateways under System:Gateways:Configuration with
(Note: The "IP address" of 103.86.99.100 in this second entry is not an error, but a trick to make this work!)
Leave everything else on default.
13. Create a gateway group under System:Gateways:Group named NORDVPN_FAILOVER with "Trigger Level" = "Member Down", having NORDVPN_GW1 as Tier 1 and NordVPN_GW2 as Tier 2, with anything else as tier "Never". After having them created, both gateways should be listed as active (green) here.
14. Finally, create a firewall rule under Firewall:Rules[new] (it should preceede most other rules):
This assumes that you have an RFC1918 alias. You could also use an inverted firewall group containing all of your local networks. What this is supposed to mean is "internet traffic", with the exception of "local traffic", should you want to access your NORDVPN_CLIENTS from any of your local networks.
If you want to try the failover, disable the first Wireguard peer. You will see the gateway failing and after a few seconds, the client traffic will go over the second connection. Re-enable the peer and soon afterwards, the traffic will be routed over the first connection again.
You can verify this when you check the change of your visible external IP with e.g. https://www.whatismyip.com/ from one of your NordVPN clients.
Note: This setup only handles IPv4! Currently, NordVPN does not support IPv6 anyways. If you want to make sure that your NordVPN clients will not expose themselves via IPv6, disable it completely on those clients or block IPv6 completely via a firewall rule for NORDVPN_CLIENTS (hint: you can use the MAC adresses instead of IPs to define the alias!).
P.S.: By default, OPNsense can take up to 60 seconds to detect a gateway failure and switch over. To make the failover happen faster, apply this adjustment:
Go to System:Gateways:Configuration, edit both gateways (`NORDVPN_GW1` and `NORDVPN_GW2`), scroll down, click "Advanced" under *Weight / Intervals* and change the values for both gateways to:
- "Ping Interval" = 1 (pings every second)
- "Time Period" = 3 (calculates average over 3 seconds)
- "Down Interval" = 3 (marks the gateway as down after 3 missed pings)
Also, I found that my setup failed a few days ago, because NordVPN obviously cancelled one of their rented servers (de1019.nordvpn.com) which happened to be the one I used until then.
Therefore, I took the effort to create a setup with a failover for a fixed set of clients. This setup also will behave as a "kill switch", i.e. that no client targeted by it can bypass the NordVPN setup and expose itself accidentally.
1. You have to create not one, but two so-called "Access Token" in the NordVPN customer dashboard by clicking on NordVPN on the left. Then, the link to enter the access token menu will be at the bottom of the page. Create to different tokens and be sure to note them, because they will not be accessible later on.
2. Once you have those tokens, you will need to create a private key for both of them. This can be done via 'curl -s -u token:<YOUR_TOKEN_HERE> https://api.nordvpn.com/v1/users/services/credentials | jq -r .nordlynx_private_key'.
3. For entry into WG instances, you will also need the corresponding public keys, which you can get via 'echo <YOUR_PRIVATE_KEY_HERE> | wg pubkey'.
4. If you followed along, you should now be in posession of two private/public key pairs pertaining to your NordVPN account. These are neccessary to discriminate between the two connections, you cannot do this using only one key pair.
5. Using these informations, you can now add two Wireguard instances under VPN:Wireguard->Instances. Add these as "NORDVPN_INSTANCE1" and "NORDVPN_INSTANCE2", use different, free "Listen Ports" (these can be arbitrary, but must not be used anywhere else) and 10.5.0.2/16 as "Tunnel address" (yes, both are the same!).
6. Obtain two NordVPN server names from their API via 'curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=2" | jq -r ".[]|.hostname"'. This will give you two names like "xx999.nordvpn.com".
7. Next, create two Wireguard peers under VPN:Wireguard->Peers. Name them NORDVPN_PEER1 and NORDVPN_PEER2, and choose different NordVPN server names obtained in the previous step for bot peers (e.g. 'deXXX.nordvpn.com'). Use "public key" = "m0tej5P6pYfBivkJc8yRV4KqQXmM81AChLlzlsOSjSs=", "Allowed IPs" = "0.0.0.0/0", "Endpoint port" = 51820, "Keepalive Interval" = 30. Choose NORDVPN_INSTANCE1 as Wireguard instance for NORDVPN_PEER1 and NORDVPN_INSTANCE2 for NORDVPN_PEER2 - use only one per each peer!
8. Next, you can check VPN:WireGuard:Status. You should see both the peer and the instance come up as green for both instance/peer pairs if Wireguard is enabled.
9. Now, assign those two Wireguard interfaces names via Interfaces:Assignments. Name them NORDVPN1 and NORDVPN2. Select each of them under Interfaces and check the "Enable Interface" and "Prevent Interface Removal" boxes.
10. Create an alias with the definition of all clients, that should go through NordVPN only. Name that NORDVPN_CLIENTS. I prefer to use a network group alias that includes MAC aliases for individual machines, see also the hint about IPv6 at the end of this article.
11. Create two SNAT rules for each of the two NordVPN interfaces under Firewall:NAT:Source NAT with:
Code Select
Description = "NAT for NordVPN"
Interface = NORDVPN1 / NORDVPN2
Version = IPv4
Protocol = any
Source Address = NORDVPN_CLIENTS
Translate Source IP = leave empty12. Create two Gateways under System:Gateways:Configuration with
Code Select
Name = NORDVPN_GW1
Interface = NORDVPN1
Address Family = IPv4
IP Address = 10.5.0.1
Far Gateway = checked
Failover States = checked
Disable Gateway Monitoring = unchecked
Monitor IP = 103.86.96.100
Description = IPv4 Gateway for NordVPN
Code Select
Name = NORDVPN_GW2
Interface = NORDVPN2
Address Family = IPv4
IP Address = 103.86.99.100
Far Gateway = checked
Disable Gateway Monitoring = unchecked
Monitor IP = 103.86.99.100
Description = IPv4 Gateway for NordVPN
(Note: The "IP address" of 103.86.99.100 in this second entry is not an error, but a trick to make this work!)
Leave everything else on default.
13. Create a gateway group under System:Gateways:Group named NORDVPN_FAILOVER with "Trigger Level" = "Member Down", having NORDVPN_GW1 as Tier 1 and NordVPN_GW2 as Tier 2, with anything else as tier "Never". After having them created, both gateways should be listed as active (green) here.
14. Finally, create a firewall rule under Firewall:Rules[new] (it should preceede most other rules):
Code Select
Description = Force gateway for NordVPN clients
Interface = any
Quick = checked
Action = Pass
Direction = In
Version = IPv4
Protocol = any
Invert Source = unchecked
Source = NORDVPN_CLIENTS
Source Port = any
Invert Destination = checked
Destination = RFC1918
Destination Port = any
Gateway = NORDVPN_FAILOVER
This assumes that you have an RFC1918 alias. You could also use an inverted firewall group containing all of your local networks. What this is supposed to mean is "internet traffic", with the exception of "local traffic", should you want to access your NORDVPN_CLIENTS from any of your local networks.
If you want to try the failover, disable the first Wireguard peer. You will see the gateway failing and after a few seconds, the client traffic will go over the second connection. Re-enable the peer and soon afterwards, the traffic will be routed over the first connection again.
You can verify this when you check the change of your visible external IP with e.g. https://www.whatismyip.com/ from one of your NordVPN clients.
Note: This setup only handles IPv4! Currently, NordVPN does not support IPv6 anyways. If you want to make sure that your NordVPN clients will not expose themselves via IPv6, disable it completely on those clients or block IPv6 completely via a firewall rule for NORDVPN_CLIENTS (hint: you can use the MAC adresses instead of IPs to define the alias!).
P.S.: By default, OPNsense can take up to 60 seconds to detect a gateway failure and switch over. To make the failover happen faster, apply this adjustment:
Go to System:Gateways:Configuration, edit both gateways (`NORDVPN_GW1` and `NORDVPN_GW2`), scroll down, click "Advanced" under *Weight / Intervals* and change the values for both gateways to:
- "Ping Interval" = 1 (pings every second)
- "Time Period" = 3 (calculates average over 3 seconds)
- "Down Interval" = 3 (marks the gateway as down after 3 missed pings)
#7
26.1, 26,4 Series / Re: [SOLVED] Upgrade to 26.1.1...
Last post by demyers - Today at 03:36:57 PMI didn't have any errors, but it looked to me like the output of the fetch commands was line buffered, and therefore didn't appear until each fetch completed. I upgraded from the console menu. The web GUI was functional and I could see from the traffic graphs that a download was taking place.
Starting web GUI...done.
Fetching base-26.1.11-amd64.txz: ................................................................................. done
Fetching kernel-26.1.11-amd64.txz: ............................ done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-26.1.11-amd64.txz... done
#8
Tutorials and FAQs / NordVPN setup with failover fo...
Last post by meyergru - Today at 03:36:35 PMThere are lots of (mostly incomplete) instructions on how to setup NordVPN on OpnSense scattered all over the forum. Also, there are instructions from NordVPN themselves, but they do not focus on Wireguard.
Also, I found that my setup failed a few days ago, because NordVPN obviously cancelled one of their rented servers (de1019.nordvpn.com) which happened to be the one I used until then.
Therefore, I took the effort to create a setup with a failover for a fixed set of clients. This setup also will behave as a "kill switch", i.e. that no client targeted by it can bypass the NordVPN setup and expose itself accidentally.
1. You have to create not one, but two so-called "Access Token" in the NordVPN customer dashboard by clicking on NordVPN on the left. Then, the link to enter the access token menu will be at the bottom of the page. Create to different tokens and be sure to note them, because they will not be accessible later on.
2. Once you have those tokens, you will need to create a private key for both of them. This can be done via 'curl -s -u token:<YOUR_TOKEN_HERE> https://api.nordvpn.com/v1/users/services/credentials | jq -r .nordlynx_private_key'.
3. For entry into WG instances, you will also need the corresponding public keys, which you can get via 'echo <YOUR_PRIVATE_KEY_HERE> | wg pubkey'.
4. If you followed along, you should now be in posession of two private/public key pairs pertaining to your NordVPN account.
5. Using these informations, you can now add two Wireguard instances under VPN:Wireguard->Instances. Add these as "NORDVPN_INSTANCE1" and "NORDVPN_INSTANCE2", use different, free "Listen Ports" (these can be arbitrary, but must not be used anywhere else) and 10.5.0.2/16 as "Tunnel address" (yes, both are the same!).
6. Obtain two NordVPN server names from their API via 'curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=2" | jq -r ".[]|.hostname"'.
7. Next, create two Wireguard peers under VPN:Wireguard->Peers. Name them NORDVPN_PEER1 and NORDVPN_PEER2, and choose different NordVPN server names obtained in the previous step for bot peers (e.g. 'deXXXX.nordvpn.com'). Use "public key" = "m0tej5P6pYfBivkJc8yRV4KqQXmM81AChLlzlsOSjSs=", "Allowed IPs" = "0.0.0.0/0", "Endpoint port" = 51820, "Keepalive Interval" = 30. Choose NORDVPN_INSTANCE1 as Wireguard instance for NORDVPN_PEER1 and NORDVPN_INSTANCE2 for NORDVPN_PEER2 - use only one per each peer!
8. Next, you can check VPN:WireGuard:Status. You should see both the peer and the instance come up as green for both instance/peer pairs if Wireguard is enabled.
9. Now, assign those two Wireguard interfaces names via Interfaces:Assignments. Name them NORDVPN1 and NORDVPN1. Select each of them under Interfaces and check the "Enable Interface" and "Prevent Interface Removal" boxes.
10. Create a "Host" alias with the definition of all clients, that should go through NordVPN only. Name that NORDVPN_CLIENTS.
11. Create two SNAT rules for each of the two NordVPN interfaces under Firewall:NAT:Source NAT with:
12. Create two Gateways under System:Gateways:Configuration with
13. Create a gateway group under System:Gateways:Group named NORDVPN_FAILOVER with "Trigger Level" = "Member Down", having NORDVPN_GW1 as Tier 1 and NordVPN_GW2 as Tier 2, with anything else as tier "Never". After having them created, both gateways should be listed as active (green) here.
14. Finally, create a firewall rule under Firewall:Rules[new]:
This assumes that you have an RFC1918 alias. You could also use an inverted firewall group containing all of your local networks. What this is supposed to mean is "internet traffic", with the exception of "local traffic", should you want to access your NORDVPN_CLIENTS from any of your local networks.
If you want to try the failover, disable the first Wireguard peer. You will see the gateway failing and after a few seconds, the client traffic will go over the second connection. Re-enable the peer and soon afterwards, the traffic will be routed over the first connection again.
You can verify this when you check the change of your visible external IP with e.g. https://www.whatismyip.com/ from one of your NordVPN clients.
Note: This setup only handles IPv4! If you want to make sure that your NordVPN clients will not expose themselves via IPv6, disable it completely on those clients.
Also, I found that my setup failed a few days ago, because NordVPN obviously cancelled one of their rented servers (de1019.nordvpn.com) which happened to be the one I used until then.
Therefore, I took the effort to create a setup with a failover for a fixed set of clients. This setup also will behave as a "kill switch", i.e. that no client targeted by it can bypass the NordVPN setup and expose itself accidentally.
1. You have to create not one, but two so-called "Access Token" in the NordVPN customer dashboard by clicking on NordVPN on the left. Then, the link to enter the access token menu will be at the bottom of the page. Create to different tokens and be sure to note them, because they will not be accessible later on.
2. Once you have those tokens, you will need to create a private key for both of them. This can be done via 'curl -s -u token:<YOUR_TOKEN_HERE> https://api.nordvpn.com/v1/users/services/credentials | jq -r .nordlynx_private_key'.
3. For entry into WG instances, you will also need the corresponding public keys, which you can get via 'echo <YOUR_PRIVATE_KEY_HERE> | wg pubkey'.
4. If you followed along, you should now be in posession of two private/public key pairs pertaining to your NordVPN account.
5. Using these informations, you can now add two Wireguard instances under VPN:Wireguard->Instances. Add these as "NORDVPN_INSTANCE1" and "NORDVPN_INSTANCE2", use different, free "Listen Ports" (these can be arbitrary, but must not be used anywhere else) and 10.5.0.2/16 as "Tunnel address" (yes, both are the same!).
6. Obtain two NordVPN server names from their API via 'curl -s "https://api.nordvpn.com/v1/servers/recommendations?&filters\[servers_technologies\]\[identifier\]=wireguard_udp&limit=2" | jq -r ".[]|.hostname"'.
7. Next, create two Wireguard peers under VPN:Wireguard->Peers. Name them NORDVPN_PEER1 and NORDVPN_PEER2, and choose different NordVPN server names obtained in the previous step for bot peers (e.g. 'deXXXX.nordvpn.com'). Use "public key" = "m0tej5P6pYfBivkJc8yRV4KqQXmM81AChLlzlsOSjSs=", "Allowed IPs" = "0.0.0.0/0", "Endpoint port" = 51820, "Keepalive Interval" = 30. Choose NORDVPN_INSTANCE1 as Wireguard instance for NORDVPN_PEER1 and NORDVPN_INSTANCE2 for NORDVPN_PEER2 - use only one per each peer!
8. Next, you can check VPN:WireGuard:Status. You should see both the peer and the instance come up as green for both instance/peer pairs if Wireguard is enabled.
9. Now, assign those two Wireguard interfaces names via Interfaces:Assignments. Name them NORDVPN1 and NORDVPN1. Select each of them under Interfaces and check the "Enable Interface" and "Prevent Interface Removal" boxes.
10. Create a "Host" alias with the definition of all clients, that should go through NordVPN only. Name that NORDVPN_CLIENTS.
11. Create two SNAT rules for each of the two NordVPN interfaces under Firewall:NAT:Source NAT with:
Code Select
Description = "NAT for NordVPN"
Interface = NORDVPN1 / NORDVPN2
Version = IPv4
Protocol = any
Source Addres = VPN_CLIENTS
Translate Source IP = leave empty12. Create two Gateways under System:Gateways:Configuration with
Code Select
Name = NORDVPN_GW1
Interface = NORDVPN1
Address Family = IPv4
IP Address = 10.5.0.1
Far Gateway = checked
Disable Gateway Monitoring = unchecked
Monitor IP = 103.86.96.100
Description = IPv4 Gateway for NordVPN
Code Select
Name = NORDVPN_GW2
Interface = NORDVPN2
Address Family = IPv4
IP Address = 103.86.99.100 [i](Note: This is not an error, but a trick!)[/i]
Far Gateway = checked
Disable Gateway Monitoring = unchecked
Monitor IP = 103.86.99.100
Description = IPv4 Gateway for NordVPN
Leave everything else on default.13. Create a gateway group under System:Gateways:Group named NORDVPN_FAILOVER with "Trigger Level" = "Member Down", having NORDVPN_GW1 as Tier 1 and NordVPN_GW2 as Tier 2, with anything else as tier "Never". After having them created, both gateways should be listed as active (green) here.
14. Finally, create a firewall rule under Firewall:Rules[new]:
Code Select
Description = Force gateway for NordVPN clients
Interface = any
Quick = checked
Action = Pass
Direction = In
Version = IPv4
Protocol = any
Invert Source = unchecked
Source = NORDVPN_CLIENTS
Source Port = any
Invert Destination = checked
Destination = RFC1918
Destination Port = any
Gateway = NORDVPN_FAILOVER
This assumes that you have an RFC1918 alias. You could also use an inverted firewall group containing all of your local networks. What this is supposed to mean is "internet traffic", with the exception of "local traffic", should you want to access your NORDVPN_CLIENTS from any of your local networks.
If you want to try the failover, disable the first Wireguard peer. You will see the gateway failing and after a few seconds, the client traffic will go over the second connection. Re-enable the peer and soon afterwards, the traffic will be routed over the first connection again.
You can verify this when you check the change of your visible external IP with e.g. https://www.whatismyip.com/ from one of your NordVPN clients.
Note: This setup only handles IPv4! If you want to make sure that your NordVPN clients will not expose themselves via IPv6, disable it completely on those clients.
#9
26.1, 26,4 Series / Re: PPPoE Connection Issue
Last post by Liran - Today at 03:25:09 PMQuote from: chemlud on Today at 03:22:27 PMHave you tried spoofing the Cisco WAN MAC to your sense WAN?
Yes.
I also tried to disconnect the GPON for a couple of hours to male sure the Cisco session is not active anymore and then connecting the OPNsense box.
#10
26.1, 26,4 Series / Re: PPPoE Connection Issue
Last post by chemlud - Today at 03:22:27 PMHave you tried spoofing the Cisco WAN MAC to your sense WAN?
