Menu

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.

Show posts Menu

Messages - muchacha_grande

#1
Hi, in other thread someone had this problem and found a workaround using a newly created pre-shared key.
#2
Ok, now I understand. I only use client export page and put these commands in the custom config.
May be if you ask thin at github the developers can consider your case and add it.
#3
Hi,

I'm using those two parameters in my config.

They are visible near the end of the page when you click advanced view on the OpenVPN instance configuration.
#4
Well, thank you. It helped me.
I created a new preauth key and expired the previous one.
Now, for some reason, it works with the new key.
#5
Hi, I found the same thing on a test OPNSense.
I recently updated the test box and observed the same issue.
I didn't give it much attention until now that you mentioned it here.
I'm using a non reusable preauth key and the status says "Backend: NeedsLogin, Tailscale IPs: null"
It was working during the beta tests phase on January, with this same key.
I'm using Headscale as the coordination server.
#6
Hi shadowlaw, could you open an issue on github to report it?

https://github.com/opnsense/core/issues
#7
Hi djpuzia, here it is my TAP config.
Note that the TLS static key has to be configured beforehand in Static Keys tab and then use it here as the Certificate in the System>Trust>Certificates and the Certificate Revocation List in System>Trust>Revocation.
Two more steps are required:
Bridge the LAN and TAP interfaces creating a bridge type interface in Interfaces>Devices>Bridge
Create the necessary pass rules on the TAP and OpenVPN interfaces at Firewall>Rules>TAP and Firewall>Rules>OpenVPN.
#8
Hi mattlf, I don't have a public IP range to test this but I think, from older posts I read, that you have to declare the additional public IPs of your range as VIPs (virtual IPs).
#9
Quote from: patient0 on February 23, 2025, 08:44:45 AMBtw: can anyone confirm that when setting the ICMP ID to 8 it does work, or is it only me?

patient0, I can confirm that using ID 8 works, as you stated.

One can suspect that the problem may be related to the use of the wrong variable being that the ICMP type of the ping is also 8.
#10
Here is another possible fixed bug that may be related to this problem https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701
#11
Quote from: muchacha_grande on February 22, 2025, 04:37:43 PMI think that this is only a matter of some configuration change between 24.7 and 25.1, but I didn't investigate it yet.

Well, it may not be a configuration problem at all.
#12
Hi patient0, the ID is not the same as the type. This is an echo request packet:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type (8)   |   Code (0)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Checksum (16 bits)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Identifier (ID) (16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sequence Number (16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Data (variable)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As it happens with TCP/UDP with the port number (session number) the ID plays that roll on ICMP echo requests.

The fact that the ID is not changed within pf means that there can only exists one ICMP echo request with each ID when it leaves the router through WAN because there can be only one state with the public source IP and a certain ID.

The first process that makes the ping with that ID will be the one that could get the way out. The subsequent ones wont get their way because they can't be routed if there is already an existing state with the same ID.

I think that this is only a matter of some configuration change between 24.7 and 25.1, but I didn't investigate it yet.
#13
Hi d00b2020, I made some tests and could see the described behavior.
#14
Thank you Patrick. I have it already on a 32 GB thick provisioned vmdk.

Cheers
#15
First of all, thanks to all the OPNSense Team.

This time I had to reinstall to move to ZFS, so I exported the configuration with RRD data included and made a full install on a ZFS pool.
The config import was done during installation with the configuration importer from a USB drive.
After the first boot, I reinstalled the plugins and then everything worked fine.
All of this was done on a a VMWare ESXi virtual machine. Now I'm able to use ZFS snapshots instead of ESXi ones.

A really really great work of OPNSense developers.
Thank you and cheers...