Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - anomaly0617

Pages: [1] 2 3

Virtual private networks / Re: IPsec migrating to Connections [new] for Draytek 286x routers

« on: August 29, 2023, 06:00:53 pm »

This doesn't answer your question specifically, but just my two cents on it.... In IPSec for a Phase 1 tunnel, at the very top, there's a field that defines whether either side can attempt to establish the tunnel, or if one side does it immediately, on traffic, or just listens for a connection. I've used this in the past to dictate when tunnels are established.

As far as the "Connections (new)" section is concerned, I'm an old crusty OPNsense user, having switched over around 2016. I'm still confused what this "Connections (new)" section is for. I know what I'd like it to be for - multiple IP addresses for the same location, like for where we have redundant internet connections and if one goes down or is unavailable, it "fails over" to the next one in the list - but I've not found the documentation stating officially what its purpose is.

Virtual private networks / Re: OpenVPN Site to Site breaks in v23.x

« on: August 29, 2023, 05:52:01 pm »

I've applied these patches to a few firewalls, but looking at them, they seem to only affect the UI, not the underlying code that may create or destroy routes when they are initiated or dropped. Am I being dense, or is this the case?

The issue I'm seeing is that nothing seems to be consistently destroying/deleting the routes when a tunnel drops, and then because there's already "a route" when the tunnel re-establishes, the route command can't do it's job. But the old routes are also stale/dead and don't work.

Virtual private networks / OpenVPN Site to Site breaks in v23.x

« on: August 27, 2023, 06:58:09 pm »

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!

Virtual private networks / IPSec and Multi-IP Redundancy

« on: July 19, 2023, 09:41:45 pm »

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!

General Discussion / Re: Upgrading from the stone age to current?

« on: November 13, 2022, 06:59:38 pm »

Quote from: yourfriendarmando on November 13, 2022, 02:16:58 am

The quick easy to find out is try it.

The upgrade functions could offer the next necessary intermediate version. If not, it could be dangerous.

In either case, take a dd capture if the disk, or keep an older iso and backup config handy.

I'm not certain how to try it out. When you run option 12 from the UI in the console or SSH, it will offer you the next major version (if you're on 19.1, it will likely offer you 19.7 - but not 22.7 or 22.10). So if it's possible, I'm not sure how to kick start it into the latest major version. the dd backup is a good plan, though, regardless. I tend to rely on the XML backup config files more though.

General Discussion / Upgrading from the stone age to current?

« on: November 12, 2022, 11:17:24 pm »

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?

Virtual private networks / IPSec VPN + SIP Phones Advice

« on: November 07, 2022, 06:14:35 pm »

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!

Virtual private networks / Phase 1 Key Lifetime setting for mobile connections

« on: March 04, 2022, 03:20:05 am »

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!

21.1 Legacy Series / OpenVPN No Client Export Option - The Solution You're Probably Looking For...

« on: June 29, 2021, 09:52:30 pm »

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!

General Discussion / GEOM Mirror Widget?

« on: May 20, 2021, 06:03:23 pm »

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

General Discussion / 1:1 NAT Forwarding/Masquerading

« on: May 18, 2021, 04:37:51 pm »

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