Messages

hello
with last version of OPN (24.7.5), I added in "IPsec: Security Policy Database" the manual subnet but it is not routed. Of-course the line for this subnet to nat 1-1 exists.

I tried to select Child and change also with the numeric ReqID of the Children declared to the connection but nothing.

If I add this subnet inside the 'Children' area of the connection, together with the real one used in the phase2, the traffic is routed inside and the nat 1-1 does the traslation.

Am I doing something wrong or has something else changed?

Thanks

Hello

I waited until today for the update to 24.1.9, including the hotfix (_1), and I confirm that it has rewritten my one-to-one entries by changing my 'destination' addresses.
Basically, 'Internal' and 'Destination' were bearing the same thing.

I did the update from 24.1.8

I manually edited the entries with the correct destinations.
Regards

Sorry for the question but I couldn't find anything about it.
Have any of you ever tried to use Rest API to POST an OpenVPN client overwrite configuration?

I've been trying for quite some time without success, trying both api/openvpn/client_overwrites/add and api/openvpn/client_overwrites/test and passing it a JSON like this:

Code Select Expand


{
    "common_name": "test",
    "enabled": "1",
    "description": "Test User"
}


Ther Result is always: "failed"

Regards
Stefano

good morning to all
I am running some tests to migrate my ipsec tunnels from legacy to 'Connection' and have encountered some anomalous behaviour.

The first concerns the "Disable all auto-added VPN rules" option in the "Advanced" section (ipsec area) which, if not selected, does not automatically generate the entries to the WAN firewall rules for the different ipsec protocols. If I create a Legacy ipsec session, these are created correctly.

The second problem, which I do not understand, is precisely why I keep receiving incoming calls from a remote peer if:
- there are no inbound rules on the WAN to allow this
- there is a general drop (IPv4 any) at the end of the WAN rules with logging option mode active and "first match"
- there do not appear to be any auto-generated rules, for precisely the reason given in the first point. The same goes for 'floating rules'.

Yet in the ipsec log I keep seeing:
2024-04-23T20:06:12   Informational   charon   09[NET] <172> received packet: from x.x.x.190[500] to x.x.x.148[500] (240 bytes)

could someone help me understand how this happens?

Thanks

Hello, with 23.7.3 is now OK.

Thanks a lot.

[route-gateway <gateway>]

Hello

In an OpenVPN Topology (subnet) configuration I set the Tunnel network to be a class B.

Within the CSO section I subsequently created individual directives for each common name that connects by assigning them smaller subnets and dedicated IP so as to divide the different users into groups and consequently creating special firewall rules.

Within the same CSO I set the directive "route-gateway <gateway>" in the Advanced section to assign an IP from that subnet as gateway.

Everything works correctly with OPNSense version 23.1.x but in the new version 23.7 I can't find how to speficate this directive in the CSO section.

Where can I set this route-gateway?

thanks

Hello

I applied the patch and I tested again but in the log "Notice" not appear the use of CSO:

Code Select Expand


2023-08-28T13:01:28 Notice openvpn_server2 127.0.0.1:1959 PUSH: Received control message: 'PUSH_REQUEST'
2023-08-28T13:01:28 Notice openvpn user 'XXXXXXX' authenticated using 'Local Database'
2023-08-28T13:01:27 Notice openvpn_server2 127.0.0.1:1959 PUSH: Received control message: 'PUSH_REQUEST'


Regards

yes, it connects and gets the first ip of the subnet declared at the instance server level but it does not take the settings declared in the CSO, that are, the remote subnets to which it is to connect and the expected static IP it is to get.

As mentioned in the previous post, to do the test, I configured a new openvpn instance, leaving the legacy server configuration unchanged, assigning it a different listening port but using the same configurations (except the IPv4 Subnet).

With Legacy, I see this:
user 'xxxxxxx' authenticated using 'Local Database' CSO [CN]:/var/etc/openvpn-csc/1/xxxxxxx

With Instance, this line not exists and in CSO page I selected correctly the new Instance as server.
user 'xxxxxxx' authenticated using 'Local Database'

Check the log for "client config created" under NOTICE log level.
Cheers,
Franco

There is no trace. it seems not read the line made in CSO page.

what I did not understand is whether or not the port-share command on new openvpn instances (not legacy) can, or will, be used again in the future. If yes, at this point I will wait for development to transition.

SSLH can be used in the meantime for just testing compatibility openvpn configurations between clients and legacy/new.

Sorry @franco,
how can I verify that CSOs are correctly read if I configure a new Instance using the new method?

As indicated here, https://forum.opnsense.org/index.php?topic=35447.msg172767#msg172767, I tried and it does not retrieve the CSO using the common name.

Thanks

Correct. In the previous post, I was referring to a home/test use condition.
Indeed, the port-share solution has the merits as you indicated and is more convenient in case of traceability of the connections/tunnels/users.
At the moment and pending further development, this plugin gives the possibility to test on the new instance mode if we are in the condition of having only one public IP and need to use port 443 for both, nginx/haproxy and OpenVPN.

Inviato dal mio SM-A336B utilizzando Tapatalk

Just tried it, setting up a new Instance.

through the use of os-sslh plugin I can safely make up for not being able to use port-share... in fact, it is more practical.

thanks for the suggestion.
Regards

Hello

I waited for version 23.7.2 before running the test.

I kept the legacy version of openvpn and then configured a new instance using the same certificates and settings, such as "Strict User/CN Matching" and "Username as CN" but changing the "Server (IPv4)" subnet network so that it would not overlap with the legacy.

I then cloned the previous "Common Name" line present into "Client Specific Override," associating it with the new OpenVPN instance server. Of course, I updated the "IPv4 Tunnel Network" with the correct octect.

Moving the incoming WAN NAT to the new OpenVPN instance, I noticed that it does not retrieve the overrides, let alone show any kind of error in the log. The user, with the correct "Common Name" is active in the status page.

If I move the WAN NAT back to the legacy instance, everything works and the override are working again.

Am I doing something wrong?
Thanks for the reply