Topics

Hi folks,

Hopefully a straightforward question here....

I have a location where there are dual WAN connections, one Fiber (WAN_FIBER), and one Coaxial (WAN_COAX).

The location has a few site-to-site Wireguard tunnels to other locations.

I want to:

• Route the Wireguard traffic primarily over the Fiber line
• Route everything else (internet for users, for instance) over the Coaxial line

I can do the second one primarily with Gateway Groups I have established. But the first one... I haven't found a way to bind Wireguard to a specific network interface like I could with OpenVPN and IPSec.

Am I missing something obvious?

Oh, just to cover the base... I have a firewall rule in the WAN_FIBER interface for incoming Wireguard traffic. The problem is the outgoing traffic. I'm trying to figure out how to define the interface the Wireguard traffic leaves out of, should this location be the initiating peer.

Thanks, in advance!

[Building A]

Hi all,

In the past if I wanted to connect two buildings that had the overlapping internal subnet(s), I could use a 1:1 NAT mapping to deal with this problem. For instance:

Problem Scenario:

	Building A	Building B
Local Network	| 192.168.1.0/24	| 192.168.1.0/24 (Uh oh!)
Remote Network	| 1.2.3.4/30	| 4.3.2.1/30

In order to make this VPN tunnel work, I need to do something like this:

	Building A	Building A (Masq.)	Building B (Masq.)	Building B
Local Network	| 192.168.1.0/24	| 172.16.1.0/24	| 172.16.2.0/24	| 192.168.1.0/24
Remote Network	| 1.2.3.4/30			| 4.3.2.1/30

And now from Building A, if I ping 172.16.2.1, I get responses from the Building B firewall.

And from Building B, if I ping 172.16.1.1, I get responses from the Building A firewall.

The magic here was in the Phase 2 VPN tunnel, there was an "Manual SPD entries" field that let me specify the masquerade network. And then under Firewall >> NAT >> One-to-One, I'd create a custom mapping that converted, say, 172.16.2.26 into 192.168.1.26 in Building B, or 172.16.1.52 to 192.168.1.52 in Building A.

With me so far?

I'm migrating all of my VPN tunnels over to the new IPSec VPN Connections mechanism. And I've got 100+ new successful tunnels under my belt, so I'm fairly confident at this point that I'm doing it correctly. But this is the first time I've run into a conflict of networks.

So my question is, how do I achieve this under the new Connections mechanism of IPSec?

Is it under VPN >> IPSec >> Virtual Tunnel Interfaces, or
Is it under VPN >> IPSec >> Security Policy Database >> Manual >> Add Manual SPD?

Are there examples somewhere to reference?

Thanks, in advance!

Has anyone mentioned that the ACME client does not stay synchronized together with HA?

I see where some settings come over, but specifically certificates are not being copied, so if one server has the certificates and the other doesn't, when they flip-flop, suddenly a bunch of sites come up with non-existant/expired certificates. This is happening using the HAProxy Reverse Proxy solution. HAProxy is sync'ing up, but ACME-Client isn't.

Edit: It occurred to us that we neglected to mention the version of OPNsense we're working with here. Every device is running at least OPNsense 24.1.2 or newer. /edit

Hi all,

Well, we thought we had this problem resolved (see my previous post if you're confused) but it turns out, maybe not.

We're testing the new Strongswan IPSec Connections before we roll them out to all of our partners.

We have a handful of test sites that are single ISP, single OPNsense firewall locations. The IPSec VPN tunnels between these sites seem to work beautifully. Generally no issues.

We colocate in a datacenter site that has multiple ISPs. They are backed by 60+ carriers, and they use some form of OSPF/BGP/RIP advertisements to switch us all dynamically across routes as necessary. There are some large Fortune 500 companies in the same datacenter. They do not go down. Ever. OK, maybe ALMOST never. But it hasn't happened in 4+ years of having servers there. And we've never experienced any issues with IPSec or OpenVPN tunnels thus far. So I doubt their routes have anything to do with this problem.

At this datacenter site, we have two OPNsense firewalls running on identical Dell PowerEdge R240 servers. They are in a high availability (HA) cluster.

We're having challenges with the satellite locations' IPSec VPN tunnels staying alive to the datacenter site with the High Availability Cluster. Every 4 hours the Phase 1 seems to rekey/renegotiate successfully, but the Phase 2 often seems "broken." Like, it appears that there is a Phase 2 connection being made, but the traffic is only one way. No "bytes in" at the High Availability location. The satellite location records "bytes out", but we don't see them reflected at the datacenter site.

So far, we've tried a bunch of the suggestions we've seen, such as:
On the Phase 1 side:

• We've disabled MOBIKE in the Phase 1 for all sites that connect to this HA cluster
• We've "dumbed it down" so that the only IP listed for each tunnel at that site on the local side is the primary CARP Virtual IP, let's call it ".146".
• We've "dumbed down" the satellite sites so that the only IP they connect to is ".146"
• We've switched to all IP addresses for local and remote IPs, so no name resolution is required.
• We've played around with the DPD value on the tunnels going to that site. In general the DPD is set to 1, but Franco and I had a discussed ages ago about DPD and its negative effects on Voice over IP traffic, so we've generally been wary of DPD since then. I tried setting it to 0, and we've tried it set to 86400 (a day). It does not seem to make a difference.
• We set a continuous ping on each firewall, pinging the other one to see if it would keep the tunnel alive. It didn't.
• We made sure under Firewall -> Rules -> WAN we have three rules: one for ESP, one for ISAKMP, and one for NAT-T. Originally we had them limited by source and destination, but the most recent configuration has them set to Any/Any for the Source/Destination set. This is what got tunnels up last time (more on that in a minute). We'd like to lock this down. Just having it this way makes us twitchy.
• We're using EC521 certificate keypairs, not pre-shared keys

On the Phase 2 side:

• We've tried it with and without Policies checked. Thing is, we were never able to get a tunnel online with Policies unchecked, so we've been leaving it checked.
• Start action is Trap + Start
• Close action is Start
• DPD action is Start
• We've vacillated between ESP Proposals. Ideally we want to use AES256-SHA512-ECP521, but we've had to switch to AES256-SHA512-MODP2048 on multiple occasions. The Phase 1 is consistently AES256-SHA512-ECP521
• Local Subnets only include /24 subnets that are at the datacenter location. No exceptions.
• Remote Subnets only include /24 subnets that are at the given satellite location. No exceptions.

But then:

We dug into the logs. Remember how everything should be coming in and going out from ".146"? What we noticed was that traffic exiting the firewall is going out with it's Non-CARP (Real WAN) IP address, ".158" in this case.

11[NET] <4496d3d2-82a6-4b82-bf9c-3d0b78a3096a|375> sending packet: from xxx.xxx.xxx.158[4500] to xxx.xxx.xxx.92[4500] (96 bytes)

And it would appear that the satellite firewalls are responding to that traffic in kind, because we have log traffic that looks like this:

12[NET] <4496d3d2-82a6-4b82-bf9c-3d0b78a3096a|375> received packet: from xxx.xxx.xxx.92[4500] to xxx.xxx.xxx.158[4500] (96 bytes)

So, this is just NAT, right? We should be able to redirect that NAT traffic using an outbound NAT rule, I would assume. Just like we tell the firewall to send traffic from a server inside the datacenter out using a different IP, say, ".152", we should be able to tell the firewall to take any traffic from strongswan and route it out the door using ".146".

But is the source IP on that the LAN IP address, or the WAN IP address? I could make arguments for it being both.

We thought we'd try it just by specifying IPSec as the interface, but that did not work.

And, that might be a red herring. We may be barking up the wrong tree on the fact that it's entering/exiting from the real interface instead of appearing to enter/exit from the Virtual IP/CARP interface.

Any advice on HA IPSec configurations would be welcome. We've got a lot of HA setups across the world, and more are coming as we go multi-ISP and multi-firewall for sites.

We're happy to send screen captures to someone privately, but I don't want to post them publicly. There are so many things we'd have to redact that I suspect it would be redundant to do so.

Thanks, in advance!

[CARP Interface IP]

Are you having a problem getting an IPSec (the new >23.1 style) to connect to a High Availability environment?

I've been hammering away at this for the last hour or so, and this is what solved it for me. It's this little section in the tutorial I totally skipped over because "of course that's still there" from when I ran IPSec tunnels under the old style IPSec before.

Firewall Rules Site A & Site B (part 1)
To allow IPsec Tunnel Connections, the following should be allowed on WAN for on sites (under Firewall ‣ Rules ‣ WAN):

• Protocol ESP
• UDP Traffic on Port 500 (ISAKMP)
• UDP Traffic on Port 4500 (NAT-T)

In my case, ever since going to High Availability, I've had to explicitly specify what CARP Interface IP or an Alias containing the CARP Interface IPs (for each one of my ISPs) my rules applied to.

This got me thinking "I'm only accepting IPSec VPN traffic on one IP of each block of IPs from the ISPs. I'll bet I have to put some custom rules in place to accept this."

So I created some new rules based on the above that look like this (this is the first one. You can clone it and modify for the other two):

Firewall - Rules - WAN:

• Action: Pass
• Disabled: No
• Quick: Yes
• Interface: WAN
• Direction: In
• TCP/IP Version: IPv4 *Your preference, but I don't use IPv6
• Protocol: ESP
• Source/Invert: No
• Source: acl_remote_sites *An alias that includes my remote sites' IP addresses.
• Destination/Invert: No
• Destination: acl_wan_1st_ips *An alias that includes ISP1's 1st IP, ISP2's 1st IP, etc.
• Destination Port Range: Greyed Out, but on others you'll put in ISAKMP or NAT-T
• Log: No
• Category: [blank]
• Description: IPSec ESP
• No XMLRPC Sync: No
• Schedule: None
• Gateway: GWG_Pri_ISP1_Sec_ISP2_Tert_ISP3 *A Gateway Group I created to decide the order for failover

Save, Rinse, Lather, Repeat for the other two rules. Put them at the top of your WAN rule stack under your block rules and maybe your Allow CARP Traffic rule. This way the rule is processed quickly.

In my case, within 5 minutes of applying these rules, my remote firewalls were connecting to my High Availability cluster. It did take about 5 minutes though.

YMMV, but leave a "thumbs up" or something if this helped you. :-)

Hey folks!

I'm not sure if we call this a bug or ... what.

Here's what I've discovered, and reproducing it seems easy enough.

On a given firewall for a multi-site (10+ sites) organization, I previously used IPSec for the site-to-site connections.

IPSec tunnels work, but they do not allow for multi-WAN failover. For instance, we've recently moved from using "Dedicated" circuits (Costly, slow) to using multiple carriers with "Best Effort" circuits (Inexpensive, and generally fast). So we have two ISPs coming into each building. If the primary connection fails, the secondary connection seamlessly takes over by utilizing Gateway Groups.

However, IPSec tunnels tend to rely heavily on IP addresses for connections and identifiers. There are no options for "Try this connection as your primary, then this one as your fallback, and then on the other end, try this connection as your primary, and this other connection as your fallback."

This is where OpenVPN shines. Admittedly you have to define one site as a "parent/server" site and the other as a "child/client" site, but the multiple connection points thing is much easier to do, because in the client portion of OpenVPN, I can say "connect here on this port first, and then here on this port second."

However--

The desire by management for RoadWarrior VPN connections such that "once you connect to one site, you are connected to all sites" has become a problem. In my OpenVPN RoadWarrior configuration, I can define "Remote Networks" and include all the subnets of all the other sites. Works like a charm, until it creates a massive problem.

We noticed this when one internet connection was behaving flaky, and we were failing over to the other internet connection. We would (seemingly randomly) have trouble with sites connecting to other sites. And after about 6 months of frustration, I think I've finally found what's happening.

I started putting the Client or Server interface in the name of the OpenVPN profile. So for instance, parent/servers were ovpns{1,2,3,4,5,...} and child/clients were ovpnc{1,2,3,4,5}. This corresponds to the netif field in System >> Routes >> Status.

Lets assume that the RoadWarrior VPN connection, which was created when I first commissioned the site, is "ovpns1". And then after that, depending on the site, we added "ovpns{2,3,4...}" or "ovpnc{1,2,3...}".

When a site would stop routing to another site, I'd have to go in, disable the OpenVPN on both sides, go to the routes table, clear any leftover routes to the destination network(s) on each side out, and then restart the server, then restart the client. And this is where it gets interesting...

For many sites, I migrated them back to IPSec for stability reasons, and if the internet connection is being flaky, I'm just deactivating one IPSec tunnel and activating the second one. Which I can do automatically using Monit. But today I went to a site where I still had the OpenVPN Server/Client setup for the site-to-site, and I noticed when I went into the routes table that the "RoadWarrior" OpenVPN Server (ovpns1) had routes to all the other networks still there, even though no one was connected to the RoadWarrior VPN. So I cleared out all the ovpns1 routes to other sites and restarted the OpenVPN tunnel. It's back alive again.

Here's my theory:
All is well until someone connects to the RoadWarrior VPN connection, at which point the routes for the RoadWarrior VPN are created and it disrupts the Site-to-Site routes. Then that person disconnects and the routes do not delete. Which would explain the unpredictability of when this happens.

Here's my proposed fix/solution:

• Routes need "weights" or "costs" assigned to them. The RoadWarrior routes need a "higher cost" or "lower weight" than the Site to Site VPN tunnel routes. And there needs to be a way to script out clearing routes, because I have not found that command in BSD yet.
• There needs to be a cleaner way to delete routes via scripts. I've figured out ways to start and stop OpenVPN and IPSec tunnels using Monit. It would be nice if there was a way to write a global script that clears routes after I stop a tunnel and before I start it back up again.

[On the 10.0.0.0/24 network side (server side):]

Hi all,

It's possible this is covered somewhere and I missed it in my searches. If so, point me in the right direction and thanks in advance!

Under IPSec, there's a setting called Dead Peer Detection that would send an R_U_THERE packet every X seconds and if it didn't get a response, declare the tunnel dead and you could do resulting actions (Clear, Restart, Trap, etc.). It was far from perfect and there were good reasons not to use it in specific scenarios, but it existed as an option and could be helpful.

Under OpenVPN, there doesn't seem to be the same thing. Here's what I'm running into:

• The tunnel drops because one side or another has an internet issue. While I could go down the rabbit hole of why the ISP sucks, it happens and it's a fact of life.
• The issue is, when this happens, the firewall on the remote side (and sometimes the local side too) seem to retain routes to that network over the OpenVPN number. You can see this in System > Routes > Status and search on the ovpns# or ovpnc#, depending on which side of the tunnel you're looking at in that moment.
• With these stale routes in place, even if the tunnel re-establishes, the routes don't seem to work.
• The only solution that I've found that consistently works is to disable the tunnel on both sides, go and clear the routes out of the table above, then re-enable the server, and then re-enable the client.

Ideally I'd like to automate this process. Here's what I'm thinking, and if someone has a more elegant solution, I'm all ears:

I'm thinking all this could be done with Monit.
Set up a check in Monit for every minute, pinging a remote host. I'd suggest a remote host that isn't the remote firewall, because that way you ensure that the route is working all the way through to the end destination and not just to the remote firewall. So in my case, I use the NVRs at the remote site.

Assumptions:

• Monit is running on each firewall of the tunnel
• Each running once a minute
• Each sync'ed with time using NTP

On the 10.0.0.0/24 network side (server side):
ping -4 -c 4 -S [LAN_Address] [Remote_NVR_IP]
(I've also seen in the forums where people do this with tcpdump. I'm not particular. I just need something that can be interpreted as a success/failure)
if [failure]

• disable the tunnel (what command? **See below) I was thinking psgrep server[##] but it seems psgrep isn't an option in OPNSense, and ps -ax | grep server[##] returns both the real process ID and the grep command process ID)
  Discovered that 'pkill -f server[##]' returns the process id, which can be killed off, but that doesn't disable the tunnel. It just kills the current one.
  
• delete all the routes for that tunnel from the routes table (what command?)
• enable the tunnel (what command?)

On the 192.168.72.0/24 network side (client side):
ping -4 -c 4 -S [LAN_Address] [Remote_NVR_IP]
if [failure]

• disable the tunnel (what command?
• delete all the routes for that tunnel from the routes table (what command?)
• wait 15 seconds (sleep 15) - this gives the server side time to "reset"
• enable the tunnel (what command?)

Can the above actions be scripted? If so, does someone have a template for this already in Monit?

(Edits for clarification)

[OPNSense 23.7.9-amd64]

This is running OPNSense 23.7.9-amd64, new build.

The hardware I have:

• ProtectLI FW2B-0 (CPU: Celeron J3060, Mem: 8GB, SSD: 250 GB)
• PCI-E SIM Card Adapter (Installed in the WiFi/LTE slot)
• Novatel LTE modem (Installed on the PCI-E SIM card adapter)
• External Antennae for LTE

The Novatel card shows up on the system as ue0, and I can assign it as the WAN interface.

What I cannot do is define an APN for the SIM card, get information from the SIM card, or connect to the modem at all using cu -l as noted in OPNsense documentation. So the interface is there, but showing as down. I have DHCP and DHCP6 selected for the IP address assignments.

I found this HOWTO and attempted to follow it. But I do not have a /dev/cuau0 or child devices.

I do however see the device when I run the following:

Code Select Expand

root@fw-026-001:/dev # dmesg | grep Nova
ugen0.4: <Novatel Wireless, Inc. Novatel Wireless HSPA> at usbus0
cdce0: <Novatel Wireless, Inc. Novatel Wireless HSPA, class 239/2, rev 2.00/0.00, addr 3> on usbus0


And running usbconfig, I see the following:

Code Select Expand

root@fw-026-001:/dev # usbconfig
ugen0.1: <Intel XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <vendor 0x1a40 USB 2.0 Hub MTT> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
ugen0.3: <Avocent Avocent AVRIQ-USB> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen0.4: <Novatel Wireless, Inc. Novatel Wireless HSPA> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)


Since there's no /dev/cuau0 or similar device, I cannot run cu -l /dev/cuau0 or see any child devices like .1 or .init or whatever.

I also tried cdce0 and ugen0.4:

Code Select Expand

root@fw-026-001:/dev # cu -l /dev/cdce0
/dev/cdce0: No such file or directory
link down


Code Select Expand

root@fw-026-001:/dev # cu -l /dev/ugen0.4
cu: unsupported speed 9600
root@fw-026-001:/dev # cu -l /dev/ugen0.4 -s 115200
cu: unsupported speed 115200

I can't create a PPP interface as defined in the HOWTO doc because when I go to that screen (/interfaces_ppps_edit.php) there's no Link Interface(s) in the dropdown, even if I unassign the NovaTel ue0 interface from the WAN assignment.

I'm likely missing something stupid due to having no experience configuring an internal, integrated cellular modem into an OPNsense box. I've done this loads of times using a JetPack or MiFi.

What am I missing?

Thanks in advance!

I've been asked by management to add a disclaimer between the OPNsense logo and the Login prompt. The disclaimer is their boilerplate "This is a government/commercial institution device, hacking is a crime and you really shouldn't be here if you aren't supposed to be here, blah blah" message that we have on all the PCs when you press Control-Alt-Delete and before the login prompt appears. This is for the HDMI/VGA console and the SSH console, not the Web UI (though they may want that too eventually).

Is there an easy way for me to add this verbiage to the login screen? In linux I think this is /etc/motd, but I'm not sure what it is on OPNsense/FreeBSD.

Thanks, in advance!

[s]

Hi there,

We're seeing a problem across all of our OpnSense v23.x installations where OpenVPN Site-to-Site tunnels are in use.

The symptom:

When one side (site) of the tunnel drops due to either an internet connection going down or a scheduled task like a weekly reboot, and the tunnel is re-established, traffic no longer routes across the tunnel.

The workaround (fix):

• Go to VPN >> OpenVPN >> Clients at the "client" site and disable the client side of the tunnel.
• Go to VPN >> OpenVPN >> Servers at the "server" site and disable the server side of the tunnel (if possible).
• At each site, go to System >> Routes >> Status and search on "ovp" in the search box. Find the destination networks, if there are any. If there are none, no worries. If there are some, then note the NetIF number (for instance, "ovpns9", or "ovpncX") and add it to your search field at the top. All the routes you see there need to be removed (Garbage can icon on the right). Remember, the tunnel is down. Those routes should not exist, but they still do. They need to not exist.
• Go to VPN >> OpenVPN >> Servers on the server side of the tunnel and edit it. Add "(ovpnsX)" to the end of the name, replacing X with the number you found earlier. This will help you in the future. Uncheck the "Disabled" box. Save.
• Go to VPN >> OpenVPN >> Clients on the client side of the tunnel and edit it. Add "(ovpncX)" to the end of the name, replacing X with the number you found earlier. This will help you in the future. Uncheck the "Disabled" box. Save.

The tunnel should now re-establish, and new routes will be created.

In the future when one of these tunnels drop, you can use the ovpn number you documented in the label of the tunnel to more quickly find and delete the routes that are stale and left over from the previous tunnel connection.

We started noticing this at multiple sites after upgrading to v23.x, but it's possible it existed before then and we didn't catch what update caused it. But it seems to be universal, affecting multiple sites that have no connection to one another.

Could someone on the Dev team look into this, if no one has already?

I'm sure someone could write some script wizardry to do this. I haven't had time to put my programming hat on and do it as of yet.

Thanks, all!

Hi there,

I'm a regular here. Been doing this awhile. But I tend to look for answers to questions before I post, and when I don't find the answers, I sometimes STILL don't post. But here's one I'm wondering about.

At our customers we've been shifting from dedicated fiber options that have an SLA with the internet service provider over to multiple "best effort" fiber and coaxial options without an SLA.

So, for instance, whereas before I had 30 x 30 Mbps dedicated fiber internet and my customer was paying nearly $700 a month for it, now we have 1 x 1 Gbps shared fiber as our primary connection and 960 Mbps x 40 Mbps shared coaxial as our backup solution. And our total bill is somewhere around $450 for both services combined. Each service has it's own block of 8 (5 usable) static IP addresses.

So, one of my larger customers has multiple locations, and they are doing this at both sites. They wanted me to set up VPN between the sites such that:

Location 1 Fiber >> Location 2 Fiber is preferred
Location 1 Fiber >> Location 2 Coax is acceptable
Location 1 Coax >> Location 2 Fiber is acceptable
Location 1 Coax >> Location 2 Coax is possible, but not preferred.

I had them on IPSec Site to Site VPN, and I discovered there was no way for me to set this up natively in OpnSense like this. In order to set it up, I had to use OpenVPN. OpenVPN allows for multiple "servers" on the client side, so this became doable as:

Location 2 Fiber >> Location 1 Fiber
Location 2 Fiber >> Location 1 Coax
Location 2 Coax >> Location 1 Fiber
Location 2 Coax >> Location 1 Coax

But, Location 1 cannot initiate the connection to Location 2. That's not the way OpenVPN was designed. Once is a "client" and one is a "server" whereas in IPSec each side is treated as an equal peer.

I'm seeing in the 23.x versions of OpnSense that there's a new "Connections" and "Pools" section in IPSec. Is IPSec getting the functionality I was hoping for above?

Thanks, in advance!

Let's say I stumble upon an OPNsense firewall that was installed in 2020, but not updated with the major versions since then.

22.10 is presently out.

Is there a way to upgrade from, say, 20.1 to 22.10 in one command at the console or SSH interface? Or do I have to do the upgrades in order until I make it to the latest version?

Hi all,

I'm looking for some advice. I've got two locations, a main location and a remote one, connected via an IPSec VPN tunnel. The remote location has about 6 SIP phone handsets, which should be communicating back to the PBX at the main location over the VPN tunnel. It also happens to be where the calls come into for customer support, so the phones NOT working is really noticeable.

Once a month on the 1st Sunday, I reboot both OPNSense firewalls, do firmware updates, etc. The following Monday (today in this case), some of the phones come up in the SIP Status interface of the phone server as being "unavailable." This appears to be due to SIP QUALIFY and SIP OPTIONS traffic not flowing between the two locations appropriately. So I've been chasing this for about 4 months now and I'm banging my head against a wall. I'm wondering if you all would look at my IPSec VPN configuration and see if you see something I'm doing incorrectly...

Phase 1

   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

Setting	Local	Remote
Phase	1	1
Disabled	Unchecked	Unchecked
Connection Method	Start Immediate	Start Immediate
Key Exchange Version	V2	V2
Internet Protocol	IPv4	IPv4
Interface	WAN	WAN
Remote gateway	(Remote Bldg IP)	(Main Bldg IP)
Dynamic Gateway	Unchecked	Unchecked
Description	Remote Bldg	Main Bldg
Phase 1 Auth Method	Mutual PSK	Mutual PSK
My identifier	My IP Address	My IP Address
Peer identifier	Peer IP Address	Peer IP Address
Pre-Shared Key	(The Key - They Match)	(The Key - They Match)
Encryption Algorithm	AES-256	AES-256
Hash Algoritm	SHA1	SHA1
DH Key Group	5 (1536 bits)	5 (1536 bits)
Lifetime	86400	86400
Install Policy	Checked	Checked
Disable Rekey	Unchecked	Unchecked
Disable Reauth	Unchecked	Unchecked
Tunnel Isolation	Unchecked	Unchecked
SHA256 96 Bit Truncation	Unchecked	Unchecked
NAT Traversal	Enable	Enable
Disable MOBIKE	Unchecked	Unchecked
Close Action	None	None
Dead Peer Detection	Unchecked	Unchecked
Inactivity Timeout	(Blank)	(Blank)
Keyingtries	(Blank)	(Blank)
Margintime	300	300
Rekeyfuzz	50	50

Phase 2

   
   
   
   
   
   
   
   
   
   
   
   
   
   

Disabled	Unchecked	Unchecked
Mode	Tunnel IPv4	Tunnel IPv4
Description	Local to Remote	Remote to Local
Local LAN Type	LAN Subnet	LAN Subnet
Local LAN Address	(Blank)	(Blank)
Remote LAN Type	Network	Network
Remote LAN Address	192.168.20.0/24	192.168.1.0/24
Protocol	ESP	ESP
Encryption Algorithm	AES256	AES256
Hash Algorithms	SHA1	SHA1
PFS key group	off	off
Lifetime	3600	3600
Automatically ping host	192.168.20.1	192.168.1.1
Manual SPD entries	(Blank)	(Blank)

Under Firewall >> Rules >> IPSec on both firewalls I have an Allow IPv4 Any-Any-Any rule with a description of "Allow IPSec Traffic."

Under Firewall >> Settings >> Advanced I have the Firewall Optimization set to Conservative

Can anyone see something I'm doing wrong here? In talking with the PBX vendor, they advised that I needed to turn off DPD on my Phase 1, which I did. This did resolve some problems, but not all of them.

Thanks in advance for any advice!

[this]

I've set up hundreds of PPTP, IPSec, L2TP, and OpenVPN connections over the years, so I wouldn't consider myself a NEWB on this topic. But this is the first time I've set one up where the internet has the potential to be this spotty.

I need a "site-to-site" connection between a stationary, physical location with fiber and (get this) a charter bus.

The charter bus has two cellular routers, one each from the leading carriers. Those come into a micro-firewall running OpnSense. And the charter bus is on the highway more often than not, so it's almost always near at least 1 or more cellular towers. But that's where the stability ends. The cellular providers both have agreed (for more money) to give us an APN that doesn't use C-NAT (Carrier-based NAT), so the IP address we see in each router is the IP address that OpnSense sees. This is a big deal because without this change, C-NAT is the default on cellular, and the cellular router has an IP address that google's "What Is My IP" does not confirm. They also firewall off the traffic to the cellular router directly, so the IP address that you see on the cellular router isn't accessible.... which means Dynamic DNS is worthless.

So, here's my question: Assuming I need bidirectional communication as much as possible, what are everyone's thoughts on setting the P1 Key Lifetime very low, like 30-600 seconds kind of low?

The present issue is that if I set that P1 key lifetime to anything normal (say, 3600-28800) and the bus goes through an area with no cellular signal, the VPN tunnel won't reconnect when it acquires cellular service again without me having to remote into both firewalls, disable the VPN tunnels on each one and Apply, then re-enable each one and Apply again. At 2 in the morning, this is really, really annoying.

Is there a precedent for this with strongswan and OpnSense?

Thanks, in advance!

See https://forum.opnsense.org/index.php?topic=13354.0. You cannot reply to archived threads, so I'm creating a new thread here.

Every once in awhile I have this problem as well, and figuring it out is a pain in the butt, because not everyone does OpenVPN the same. In our case, we use Active Directory as the back end authentication mechanism. When the "Client Export" page has no link at the bottom, you start to pull your hair out trying to figure out what you did wrong... so here's the answer...

Look at the certificate you linked to in your OpenVPN Server configuration. Grab it's name and then go to System > Trust > Certificates. Is it Self-Signed? If so, that's your issue.

Make sure you have a Certificate Authority for your firewall. Add one under Trust > Authorities > Add. It can be Self-Signed, because it's a Certificate Authority (ie: Something that can create and issue certificates).

Next, create a new Certificate under System > Trust> Certificates.
Create an Internal Certificate.
For Certificate Authority, choose the Certificate Authority you created above.
Under Type, make sure you select Server Certificate.
I usually set the Lifetime of this certificate to something like 3650 (10 Years). You likely don't want to have to reissue VPN profiles to users that often.
Fill in all the information. Under Common Name, give it something unique, like SSLVPN Certificate or something similar.
Save it, and let's go back to OpenVPN Servers.

VPN > OpenVPN > Servers
Edit Your Server.
Under the Cryptographic Settings section, look at Server Certificate and select the one you just created.
Go to the bottom and click Save.

Go to VPN > OpenVPN > Client Export. You should now have a link to select.
I'm a fan of "File Only" because it bundles everything up into one nice file for OpenVPN to import.
I also change the Hostname to a DNS resolvable name. This makes life easier when you change ISPs.

Hope this helps!

This seems funny to me, but in all the conversions I've done from that other *Sense product to OpnSense, I never noticed that there's no GEOM Mirror Widget. Here's what it used to look like:

GEOM Mirror Status Widget

How hard would it be to create one and make it an optional add-on to OpnSense? I know it's some derivative of the "gmirror status" command.

Thanks, in advance, for all you do!
Paul

[/22]

Hi all,

I've done this before, but it's been years and I'm hoping someone can just give me a quick refresher on it.

I have a vendor (gotta love vendors) who has set up an internal network around their manufacturing solution wherein they are utilizing a 192.168.0.0/22, or in more human readable terms, a network where the start address is 192.168.0.0 and the end address is 192.168.3.255.

My boss wants us to connect to this network and pull stats from the manufacturing solution. There's software to do this, and we've purchased it. But the issue is that we already have networks that are on the 192.168.1.0, 192.168.2.0, and 192.168.3.0 networks. Thus, I've set up an opnsense firewall on another VLAN'ed network, which is the 192.168.20.0 network, dedicated to the various manufacturing machines.

So, my "WAN" interface on this firewall looks like this: 192.168.20.254/24
And, my "LAN" interface on this firewall looks like this: 192.168.1.254/22

I've used nmap to scan the entire network for this manufacturing solution, and I find 27 IP addresses between 192.168.0.0 and 192.168.3.255.

What I'd like to do is set up some virtual IPs on the opnSense firewall like this:

WAN 192.168.20.230 = LAN 192.168.1.10
WAN 192.168.20.231 = LAN 192.168.1.15
...

And this way we can ping and communicate with the devices on the manufacturing network using 192.168.20.x network addresses instead of their native 192.168.[0-3].x addresses.

It seems like this was possible and relatively easy once I got the hang of it. But by "getting the hang of it" I mean I did it once about 4 years ago.

Can someone refresh my memory on how to make this work?

Thanks, in advance!
Paul

Hi all,

Am I correct in saying that NUT (Network UPS Tools) can be a client on OpnSense, but OpnSense cannot act as a NUT server/daemon for other machines to connect to?

Hypothetically, let's say we find a security vulnerability in OPNSense that we want to (privately!) bring to the attention of developers to get it resolved quickly and quietly. Who should we send this data to, and how should we send it?

Thanks!
-Anomaly0617

Hi all,

We maintain a number of multi-site locations where we've used IPSec and fully-meshed the networks (ie: every location can talk to every other location). The obvious issue with this is the upkeep. Doing the math, if I have 11 locations, that means that every firewall has 10 IPSec tunnels. (Locations * (Locations -1)). So, in the instance of 11 locations, I'm maintaining 110 individual tunnels.

And this is where cloud-meshed VPN solutions (SD-WAN) enters the show. Instead of having to maintain 110 tunnels, I could maintain 11, and the cloud-meshed VPN solution would handle the routing. Or, worst case, I can manage the routes at the centralized console. Point is, the routing becomes easier.

For some of my locations, this is a non-starter. Those locations deal with protected information and an SD-WAN solution leaves too high a possible risk for someone to silently add their own node onto the network and then have time and access to all of the information they can vacuum up without our notice. Yes, I know that these solutions often offer multi-factor authentication at the cloud level. But even multi-factor is being hacked these days.

And this brought us around to ZeroTier. One of my engineers was complaining about what a pain in the rear maintaining all the tunnels was, and how SD-WAN would be so much better a solution. So I decided to give it a try with ZeroTier.

I picked a location that is more or less a "test site" - no issues if that site gets hacked, there's nothing there for them to find. And for the other site (and eventually, sites), I picked a few of our staff's home networks that are in a similar situation - if they get hacked... well, that sucks, but they have firewalls and backups.

I followed this guide and tried to keep the configuration as simple as possible. Get it working reliably first, and then start building rules and filters as necessary. But I didn't get that far.

My experience was that after

• updating OPNsense to the latest version
• getting the zerotier plugin installed
• connecting it to my zerotier portal through VPNs >> ZeroTier and using the API I was given from the ZeroTier portal
• adding the site and approving it in the portal
• creating the network interface and assigning it the appropriate IP address from ZeroTier (note: /24, not /32!)

I would see an uptime of about 45 seconds to 2 minutes, after which my network monitoring software would go from "all green" to "all red" pinging the remote hosts.

I tried adding managed route(s) (example: network 192.168.92.0/24 routes through 10.147.17.197).
I tried rebooting firewalls.
My experience did not change.

I read through the ZeroTier manual. No luck.

I not only disabled the IPSec tunnels that were in place before, I deleted them out of a few firewalls and rebooted. No change.

So, I'm now curious if I did something very obviously wrong, or if this experience is relatable to others? I'm open to the idea of an SD-WAN solution if it's stable, but I'm not going to sacrifice stability for convenience.

Opinions/Comments welcome!