@viragomann

Thank you so much, i didn't understand that i needed a IP "reservation" in the tunnel, so i can create a new rule allowing access to the MGMT network.

now everything is fine.
🙏

@ermilan2309
If you need and don't want to throw the hardware in the trash (the manufacturer forgot to update their product, for example Yealink).
Use Custom options on server:
tls-cert-profile insecure

@fholzer I have re-generated all certificates to 2.7.0 version.there are still fixes https://github.com/pfsense/pfsense/commit/48cf54f850c5bf4fe26a8e33deb449807e71c204.patch [PATCH] OpenVPN Enforce key usage option fix. Issue #13056 , Fix OpenVPN forming invalid route statements for empty local networks (After applying, edit/save affected entries or reboot, Redmine #14919). Use IP/system_patches.php

@bp81 @Gertjan ,

This was client to site tunnel.
Eventually there was no true problem, my way of testing with single tcp stream of iperf3 was bad idea.

OpenVPN single stream can be awfully slow, max those 40mbps. If there is single packet lost, tcp windows goes back to lowers value.
If I do iperf3 with parallel connections then I come to point that my download/upload are more or less the same.

Cant explain why iperf3 upload test with single stream gets max, while download gets ~40-50mbps

Nevertheless, my conclusion is that OpenVPN is particularly bad for those older protocols which use single tcp stream (ssh,scp, ftp, rdp etc)
While those that use multiple streams, such as web browsing will get maximum speed.
If I do test on speedtest.net i get almost maximum.

This is without any special tweaks, AES-NI turned on, AES-GCM with ECDH without dco and any special mtu/mss buffer changes.

Thank you for you willingness to help guys.

@fholzer
The OpenVPN IF is wide open; allows from any to any, any protocol.

there was a lack of client override settings
now all is working fine

@dust1
Check this https://forum.netgate.com/post/675979

@bolvar maybe your old client - which is common added the search suffix.

You should be able to push the search suffix or domain in the options for that client on the server.

You mean 2.6.13? That is the current openvpn client.

I think right around 2.6.something is when they changed to dco interface - that might have something to do with the search suffix of the domain you hand out?

But a NS should really never answer a non fqdn qeuery.. If you don't want to use the fqdn then you client should auto add search suffixes to the query.

@crazily9892 said in OpenVPN Layer 2 with VLANs - How to Set Up?:

My pfSense lets me put a VLAN tag on my L2 VPN

Thank you.

I tried to set the VLANs on the OpenVPN tap interface:

Screenshot 2025-03-05 at 09.59.44.png

And then I added a bridge from the newly created VLAN to the existing interface which is tagged on the switch:

Screenshot 2025-03-05 at 09.59.48.png

Screenshot 2025-03-05 at 10.00.33.png

The CLOUD_LAN interface has a CARP Virtual IP Address:

Screenshot 2025-03-05 at 10.05.14.png

On the other end, I have a vmbr interface:

24: tap0.150@tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr150 state UP group default qlen 1000 link/ether e6:43:98:64:45:36 brd ff:ff:ff:ff:ff:ff 25: vmbr150: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:43:98:64:45:36 brd ff:ff:ff:ff:ff:ff inet 192.168.150.1/24 scope global vmbr150 valid_lft forever preferred_lft forever inet6 fe80::e443:98ff:fe64:4536/64 scope link valid_lft forever preferred_lft forever

Which is bridged to the tap0 OpenVPN interface:

root@node1:~# brctl show bridge name bridge id STP enabled interfaces vmbr0 8000.107c614c4e64 no enp5s0 vmbr150 8000.e64398644536 no tap0.150

Anyway, if I try to ping the pfSense CLOUD_LAN IP address from the OpenVPN client, it does not work:

root@node1:~# ping 192.168.150.254 PING 192.168.150.254 (192.168.150.254) 56(84) bytes of data. From 192.168.150.1 icmp_seq=1 Destination Host Unreachable From 192.168.150.1 icmp_seq=2 Destination Host Unreachable From 192.168.150.1 icmp_seq=3 Destination Host Unreachable

And tcpdump only see the ARP request:

root@node1:~# tcpdump -i tap0.150 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on tap0.150, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:03:23.636095 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:24.659991 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:25.683845 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28 10:03:26.708073 ARP, Request who-has 192.168.150.254 tell 192.168.150.1, length 28

This let me think that the problem is on the client, because packages are not exiting from it.

Do you have any idea?
Thank you!

@JonathanLee Not only smb needs to be accessed, but also a proxmox server, for example

@nattygreg Thanks I have attempted many trail and error tests, another one that gave me speed boosts was changing these settings.

Screenshot 2025-03-03 at 21.50.05.png

@Gertjan does SafeXcel accelerate any of these ?

@justanotherpfsenseadm
If the interface is configured as a DHCP client it possibly gets a gateway from the DHCP, or you've stated the gateway by yourself in the interface settings.
In theses cases pfsense automatically adds an outbound NAT rule.

You can verify automatically generated rules at the bottom of the outbound NAT page.

@Gertjan said in Any recent changes? Getting hard reset.:

Your "/sbin/ifconfig ovpns1 172.16.255.1/24 mtu 1500 up" seems to fail.

can't tell you why .....
No issues with my :

I couldn't seen any reason either, so I rebooted pfSense and that seemed to clear it.

Sooo I did some extensive testing on my home box...

Renew CA - use same key and same serial Renew server cert - use same key and NOT use same serial

In this scenario all existing certs are valid and can connect without an issue. If I renew client cert it also connects without an issue.

What is more interesting is this:

Old CA was valid to today for example When I generated client cert with that CA it was valid for 10 years and NOT until today like my old CA So this probably mean that this cert, generated with old CA and valid for 10 years will also be valid with NEW CA and NEW server cert in place :)

So if you have like 400 clients like I do it is IMHO OK if CA is valid for 10 years, then just renew CA and server cert approx. 2 years before expiration and take care of certs that are expiring and that's it :)

And then, repeat after 8 years...

Thoughts or criticism?
Can it really be this simple and straightforward or am I missing something?