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 - keeka

#1
General Discussion / Visibility of aliases
Today at 11:07:59 AM
I think it would streamline configuration for the user if aliases were expanded and exposed in more sections of the OPNsense web interface.
Host interface aliases, for example, would make make it possible to configure DHCP and VPN without hardcoding a firewall IP address. Maybe I am overlooking something, but I have found myself looking for interface aliases and either not finding them in the dropdown or no aliases are offered/supported.
#2
Push appropriate DNS servers to the ovpn client. At the bottom of the server instance config page.
You may also need to you push the necessary routes to reach that dns server (under 'Local network' on the same page).
#3
Quote from: talowicz on September 14, 2025, 09:36:39 AMExactly what I needed! Thanks a bunch :)

Glad to hear. IIRC you can add -s0 switch to tcpdump to ensure full packet payload capture.
You may also want to check -U switch too (man tcpdump on remote host OS).
#4
If you're using wireshark on a linux desktop (not sure about the windows version) you can use the 'ssh remote capture' option to bring it straight in to wireshark near realtime.

Just to add, best way I find to configure the capture in wireshark:
Server: appropriate opnsense interface address.
authentication: username and private key.
capture: select 'other' and put a full tcpdump command. e.g. tcpdump -i pppoe0 -w - 'udp port 53 or tcp port 80'
(Use actual device interface names rather than aliases lan, wan etc.)
check 'save parameters on capture start'.
HTH
#5
Virtual private networks / ovpn_status.py 100% cpu
August 29, 2025, 02:09:48 PM
I am attempting an API script that changes an openvpn client's remote IP and restarts the instance.
This always produces the intended result but on occasion leaves behind an ovpn_status.py process that is consuming 100% cpu, which I then have to kill.
The script retrieves the instance, updates the remote endpoint, restarts the instance, checks the status.
What might I be doing wrong here to cause the runaway process and how better to handle it?
I'm guessing it is related to potential repeated calls to /api/openvpn/service/search_sessions below.

client_name = sys.argv[1]
remote_ip = sys.argv[2]

r = requests.get(
    "{}/api/openvpn/instances/search".format(remote_uri),
    auth=(api_key, api_secret),
    verify=False
)
if r.status_code != 200:
    print("error : %s" % r.text)
    sys.exit(1)

instances = json.loads(r.text)

for row in instances['rows']:
    if row['description'] == client_name and row['role'] == 'client':
        uuid = row['uuid']

        instance = {
            "instance": {
                "remote": remote_ip,
            }
        }

        print("Changing remote from {} to {}".format(row['remote'], remote_ip))

        r = requests.post(
            "{}/api/openvpn/instances/set/{}".format(remote_uri, uuid),
            auth=(api_key, api_secret),
            verify=False,
            json=instance
        )
        if r.status_code != 200:
            print("error setting new remote: %s" % r.text)
            sys.exit(1)

        if row['enabled'] == '0':
            print("instance {} disabled. Skipping restart".format(client_name))
            sys.exit(0)

        print("restarting {}...".format(client_name))
        r = requests.post(
            "{}/api/openvpn/service/restart_service/{}".format(remote_uri, uuid),
            auth=(api_key, api_secret),
            verify=False
        )
        if r.status_code != 200:
            print("error restarting: %s" % r.text)
            sys.exit(1)

        sleep_time = 5
        num_checks = 3
        while num_checks > 0:
            time.sleep(sleep_time)
            num_checks -= 1
            r = requests.post(
                "{}/api/openvpn/service/search_sessions".format(remote_uri),
                auth=(api_key, api_secret),
                verify=False
            )
            if r.status_code != 200:
                print("error checking status after restart: %s" % r.text)
                sys.exit(1)
            statuses = json.loads(r.text)
            for s in statuses['rows']:
                if s['id'] == uuid and s['status'] == 'connected':
                    client_status_str = "{} {} {} {} {} {}".format(
                        s['description'],
                        s['status'],
                        s['real_address'],
                        s['virtual_address'],
                        s['bytes_sent'],
                        s['bytes_received']
                    )
                    print("Success {}".format(client_status_str))
                    sys.exit(0)
        print("{} failed to (re)start".format(client_name))
        sys.exit(1)

print("No matching vpn client instance found")
sys.exit(1)

#6
I think a unified syslog would be a good idea if you plan on expanding your network and starting out with a homelab.
Even taking opnsense in isolation, a unified log makes it easier to poke around.
I like Graylog. Running it in a proxmox lxc with 4GB RAM, it copes perfectly well with my small network. Very helpful in tracking down problems. I am not sure how useful it is in analysing netflow data for example. But for regular syslog it is flexible, has the tools to extract/enrich logs, and handle unusual log formats you're likely to encounter from time to time.
#7
Quote from: viragomann on August 08, 2025, 05:48:55 PMVPN: OpenVPN: Instances > "Static Keys" Tab

Thanks! I was fixated on it appearing in the LHS menu.
#8
If I remember right these were configurable in the openvpn section of the web UI. Whilst I can select existing ones for each client/server instance, I cannot configure the keys themselves in 25.7.
#9
When I select one or more states and hit the delete selected states button (bottom right), I receive the 'endpoint not found' warning.
According to firefox console, the post request is to /api/diagnostics/firewall/del_state/undefined and the json parameter is empty.
I am using OPNsense 25.7.1_1.
#10
25.1, 25.4 Series / Re: Recent VOIP disconnections
August 02, 2025, 12:18:37 PM
Changing firewall optimization from conservative to normal seems to have cured this. Now, with udp.multiple of 60s rather than 900s, I have managed calls over 1 hour and no interruptions. It seems counter intuitive and runs counter to advice re VOIP and NAT. I have since found this post, describing the same issue with the same resolution.
#11
Quote from: VTOLfreak on July 17, 2025, 02:58:45 PMI didn't add any plugins to my installation that didn't come from the opnsense repository if that is what you mean. (see screenshot)
If this is running on a qemu guest, you don't need cpu microcode packages. Though I don't think it does any harm, it's one less package in the mix.
#12
Some time after upgrading to 25.1.9, I seem to be seeing VOIP disconnections when call duration exceeds approx 900 seconds.
Prior to this all calls, including some lasting over an hour, were uninterrupted.
I cannot accurately correlate the problem with the upgrade as there were no calls of sufficient duration for 2 weeks.

Were there any changes in 25.1.9 that might be related?
#13
25.1, 25.4 Series / Re: [acme] Custom deploy hooks?
July 03, 2025, 05:22:24 PM
There is the option in the dropdown to run a remote command via SSH.
You should therefore be able to use that option to run a local command via SSH on localhost. However I'm not sure how you discover the current cert/key/ca paths, should you need it in your script.
#14
I don't think there is a concept of static dhcp with openvpn tunnel network. To assign a consistent IP to each client, you can create client specific overrides for a given username.
EDIT or are you saying you cannot get more than 1 client connected simultaneously because it refuses to hand out addresses other then .2?
#15
Quote from: senseOPN on June 22, 2025, 05:16:54 PMWhatever, regular default-deny /state-violation packages should be logged for this rule and not with some other, user-added rule!
That should be clear.
No, that's not how it works. If some rule you define has already matched a packet and acted upon it, that packet will not reach the default block, whether logging is enabled or not. I vaguely recall there being match type rules which allowed you to act on a packet but it still traverse the rest of the interface rules. But don't see that in current opnsense.