Messages

Franco,

I ran the check for updates on Friday, and it gave me 21.7
I noticed the problem the next day, Saturday morning and posted right away.
I misinterpreted your reply to mean that you didn't care for 21.7.1
Now that I read you second reply and followed the links you provided, I see that it is fixed in 21.7.1
I just rechecked for updates and was provided 21.7.1 which does indeed correct the issue.

Thanks for that!

Mantis314

Franco,
I'm not a fan of some of the "Improvements" that show up after updating various products, Windows comes to mind here.
Bugs, on the other hand are just part of the process.

After all the whole reason for updates and patches is to replace documented issues with undocumented ones. :)

Mantis314

Kosta, The issue is that going in to edit one field, in my case the description, should not automatically change other unrelated fields.
When I saved my description changes, both subnets changed from /24 to /32 which broke my config.
Now that I know to watch for that it shouldn't be a problem for a while. But if I change something 6 months from now, I will likely have forgotten again.

Mantis314

I have an IPsec tunnel between two OPNsense firewalls.
I upgraded both of them today to 21.7.
If I go to VPN/IPsec/Tunnel Settings, both local and remote subnets are /24.
If I then click on the edit icon (Pencil), the next page shows both subnets as /32.
Please see attached snips.
I didn't notice this when I edited the description field and crashed my tunnel upon saving the configuration.
It was easy to fix, once I spotted the problem.
Subsequent testing shows that it does this every time, and it behaves the same way at both ends.
This looks like a bug to me.
If it's intentional, I'm not a fan.

Mantis314

By the "IPs on both ends" I assume you mean the public WAN interface IPs.
Both ends are dynamic, and I use a dynamic DNS service to maintain hostname integrity.
Both IPs are stable in that neither address has changed in months.
I in fact tested using the IPs as opposed to the hostnames, but the outcome was the same.
The history of these two sites is that both ends were protected by old Sonicwalls (NSA-240 & TZ-100).
I had an IPSEC tunnel between the Sonicwalls which was quite reliable.
It has been about 24 hours now since I established an IPSec tunnel between the two OPNsense firewalls.
So far it is stable again.
My observation of the Wireguard is that, true to it's claim, it is very easy to set up and get running.
I never ran an iPerf test to see how much faster Wireguard was, but it did have a nice "feel" to it while it was up.
The Wireguard would not recover on it's own from a restart of either firewall. I always had to disable/enable it to get it running again.
And of course the site to site tunnel refused to stay up on it's own.

Mantis314

I gave up on it.
It's just not worth all the frustration.
Tonight I built an IPSec tunnel instead.
Hoping that stays up.

Thanks for the support though, much appreciated!

Mantis314

It's 200 miles away.
But I will be there over the weekend. I might try that.

Mantis

I removed 192.168.19.0/24 from the Endpoint.
There is now only the relevant LAN subnet at each end.
I restarted the tunnel at 11:00 this morning.
When I returned home from work this afternoon at 4:00 it was down again in the same manner as before.
Going to Endpoints and clicking Apply Lights it back up again.
Are there any logs for Wireguard which might provide a clue as to what is happening?

Mantis314

These snips are of the end that drops, and were taken when the tunnel is up.
After it drops the list configuration and Handshakes go completely blank.
The local config has a field for DNS. I have tried with and without a DNS server here. I used 8.8.8.8

Mantis314

Set the Keep Alive to 5 at both ends. It ran for over an hour. I went out to the grocery store this evening and when I returned it was down again.
Logged into the remote appliance,
Verified that List Configuration was blank again.
Verified that Handshakes was blank again.
Went to Endpoints and simply clicked Apply.
Seconds later List Configuration is populated as is Handshakes.
Tunnel is back up.
It will be down again in the morning.
It has been doing this since I first set it up a few months ago.
I don't get it.

I have two sites both running Protectli appliances with OpnSense 21.1.9 installed.
I have Wireguard site to site VPN configured and working.
The VPN refuses to stay up for long though. It will only stay up for a couple of hours.
I have Keep Alive configured on both ends and set to 25.
The VPN-Wireguard-List Configuration and Handshakes tabs are blank on the remote end.
To get it working again I need to visit the Endpoints tab (on the remote firewall) and click Apply. It will come right back up and work for a couple more hours. Also at this point, the List Configuration and Handshakes tabs are populated again.
What do I need to do to keep the tunnel up?

Thanks in advance for any suggestions.

Mantis314

Bart,

Yes, that was it!
While there was no option to disable compression, I set it to "No preference".
I tested it by opening an RDP session to a PC on the other end and it worked the first time.
I will likely play with the compression now that I know it was the issue.

You saved me a lot of frustration!

Thank You,

Bill

I'm new to OpnSense.
I have OpnSense 21.1.6 on a Protectli appliance.
I have configured OpenVPN following the RoadWarrior documentation.
LAN subnet = 192.168.13.0/24
OpenVPN subnet/pool = 192.168.16.0/24
I am able to connect successfully and obtain an IP from the OpenVPN pool.
I can access the web interface for my OpnSense firewall.
If I run an Angry IP Scan of my LAN subnet, I can see all the devices on my LAN.
However, I am not able to access anything (other than my firewall) on my LAN via any service I have tried.
I have devices on 22, 80, 443, 3389 etc.
The Angry IP scan shows these ports open on the appropriate devices.
The OpnSense Firewall is 192.168.13.253 and is my default gateway for everything on the LAN.
From a PC on the LAN when I run a tracert to my laptop which is connected via OpenVPN, the trace shows OpnSense sending the traffic back to the OpenVPN client.

C:\Users\Admin>tracert 192.168.16.6

Tracing route to BW-WS1 [192.168.16.6]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.13.253
  2    51 ms    43 ms    45 ms  BW-WS1 [192.168.16.6]

Trace complete.

Here is a live log view of an attempt to access the web interface on an access point at 192.168.13.251 from a VPN client on 192.168.16.6 showing the traffic is allowed.

srcport,dstport=443src,dst=192.168.13.251

Interface      Time   Source   Destination   Proto   Label   
LAN      Jun 3 21:04:05   192.168.16.6:59481   192.168.13.251:443   tcp   let out anything from firewall host itself   
LAN      Jun 3 21:04:05   192.168.16.6:59480   192.168.13.251:443   tcp   let out anything from firewall host itself   
LAN      Jun 3 21:03:33   192.168.16.6:59459   192.168.13.251:443   tcp   let out anything from firewall host itself   
LAN      Jun 3 21:03:33   192.168.16.6:59458   192.168.13.251:443   tcp   let out anything from firewall host itself   

Why am I able to ping and scan but not do anything else?

BTW all this used to work with my old Sonicwall.
The only thing that has changed is the introduction of the OpnSense firewall.

Any thoughts on what I might be missing?

Thanks,

Bill

Install Policy was already unchecked at both ends.
As a test I checked the box and restarted the service, then unchecked it again and restarted the service.
Still no IPsec interface.
So I restarted the firewall.
Still no IPsec interface.
The tunnel is up, has been, I just can't assign any routes to it without a gateway.

Thanks,
Bill

Please excuse me if this is covered elsewhere in this forum.
I am new to OpnSense, but not new to firewalls and networking.
I am replacing a pair of old Sonicwalls with a pair of Protectli appliances loaded with the latest version of OpnSense. OPNsense 21.1.6-amd64.
I am trying to create a routed site to site IPsec VPN between my home and my cabin.
I am following the documentation and am running aground when I attempt to create the intermediate network.

(From the documentation)
***********
Gateway Site-A

Name      VPNGW      Set a name for your gateway
Interface           IPSEC1000   Choose the IPsec interface
IP Address           10.111.1.2   Set the peer IP address
Far Gateway   Checked      This has to be checked as it is a point-to-point connection
************

The problem is that IPSEC is not an option when choosing the interface.
Looking in the main menu under Interfaces, IPSEC is not present there either.

I have exactly the same issue on both ends of the tunnel.
I have searched the documentation, this forum, and elsewhere on the Internet.
I found another topic on this forum "Gateway not working anymore in routed IPsec (Azure)" which seems similar.
I was having the same issue with clean installations of 21.1.5 so I thought I would try the new 21.1.6 but the problem remained.
So far I have not found a solution.
I really don't want to plug my old Sonciwalls back in. It's also a 400 mile round trip to do so.
Any advice please?