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

#1
I just did, and it worked!!

I created a client specific override and placed the foreign network (In my case 192.168.1.0/24) in "Remote Network" field. 

I did not realize the difference between the OpenVPN server "Remote networks" and the "Remote networks" for the Client Specific Overrides. In the overrides the "remote networks"  are configured via iroute clauses in OpenVPN and inform the server to send these networks to this specific client.

Thank you!
#2
I have a OpenVPN client that acts as gateways. I currently access a remote network behind the remote OpenVPN client. This works fine under the Legacy OpenVPN configuration. However, I have tried (and failed) to migrate this configuration to the new OpenVPN "instances". I can get the tunnel to form, and I can see traffic leaving in the logs and in a tcpdump, but the routed traffic (i.e. 192.168.1.0/24) never makes it to the remote end. If I put the client back on the legacy server config, it just works.

Example:

[LAN Client 10.7.7.16] <-> [OpnSense] (NAT all traffic to OpenVPN server side IP) <-> (ovpns1 -Server Side:10.7.7.201 - Client Side:10.7.7.202) - [Debian Real Client IP 192.168.1.164] - (Client Network 192.168.1.0/24)

Here is a tcpdump from my OpnSense Openvpn Server:

During the capture I pinged 192.168.1.1 (remote network) and 10.7.7.202 (OpenVPN TUN client IP). You can see the remote client side IP respond, but the packet to 192.168.1.1 never makes it to the remote side.

# tcpdump -nn -i ovpns1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpns1, link-type NULL (BSD loopback), snapshot length 262144 bytes
09:05:20.480107 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3316, length 40
09:05:25.473947 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3317, length 40
09:05:26.540133 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3318, length 40
09:05:26.581940 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3318, length 40
09:05:27.549951 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3319, length 40
09:05:27.601653 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3319, length 40
09:05:30.464978 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3320, length 40
09:05:35.461030 IP 10.7.7.201 > 192.168.1.1: ICMP echo request, id 1, seq 3321, length 40
^C
8 packets captured
29 packets received by filter
0 packets dropped by kernel

$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:05:26.558456 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3318, length 40
09:05:26.558500 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3318, length 40
09:05:27.573679 IP 10.7.7.201 > 10.7.7.202: ICMP echo request, id 1, seq 3319, length 40
09:05:27.573721 IP 10.7.7.202 > 10.7.7.201: ICMP echo reply, id 1, seq 3319, length 40
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

On the firewall I see the packets being accepted on the internal interface vtnet0_vlan5, natted, and being sent out the ovpns1 interface

Relevant logs:

2025-05-21T09:04:56-04:00    Informational    filterlog    321,,,53e5b031704847c121cc75f16415bc29,ovpns1,match,pass,out,4,0x0,,127,6267,0,none,1,icmp,60,10.7.7.201,192.168.1.1,datalength=40   
2025-05-21T09:04:56-04:00    Informational    filterlog    5,,,0,ovpns1,match,nat,out,4,0x0,,127,6267,0,none,1,icmp,60,10.7.7.16,192.168.1.1,datalength=40   
2025-05-21T09:04:56-04:00    Informational    filterlog    225,,,48fd8e8cb60ac9658d99782f3473edbc,vtnet0_vlan5,match,pass,in,4,0x0,,128,6267,0,none,1,icmp,60


Can anyone point me in the right direction on how to make this work?

Thanks again!
Chris
#3
I run OPNsense as a Proxmox VM, virtio trunk interface, queues=6 (matching the number of cores). I have  Intrusion Detection configured to use Promiscuous mode on the trunk interface, using hyperscan as the pattern matcher. Everything seems to work well, but I am seeing output errors on interfaces only when I enable IPS Mode for Intrusion Detection. Is there anything I can tweak to mitigate this?

Thanks again! 
#4
On every reboot I get this system status error:

[20-Feb-2025 11:33:41 America/New_York] PHP Fatal error:  Uncaught Error: Call to a member function add() on null in /usr/local/opnsense/mvc/app/models/OPNsense/Unbound/Migrations/M1_0_1.php:96
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(790): OPNsense\Unbound\Migrations\M1_0_1->run(Object(OPNsense\Unbound\Unbound))
#1 /usr/local/opnsense/mvc/script/run_migrations.php(54): OPNsense\Base\BaseModel->runMigrations()
#2 {main}
  thrown in /usr/local/opnsense/mvc/app/models/OPNsense/Unbound/Migrations/M1_0_1.php on line 96

Unbound loads correctly, if I reload/stop/start unbound the error does not come back.

I looked at M1_0_1.php...

94         if (!empty($config->unbound->domainoverrides)) {                       
 95             foreach ($config->unbound->domainoverrides as $old_domain) {       
 96                 $new_domain = $model->domains->domain->add();                   
 97                 $domain_data = [                                               
 98                     'enabled' => 1,                                             
 99                     'domain' => $old_domain->domain,                           
100                     'server' => $old_domain->ip,                               
101                     'description' => !empty($old_domain->descr) ? substr($old_domain->descr, 0, 255) : null
102                 ];                                                             
103                 $new_domain->setNodes($domain_data);   
     

Could this be coming form a bad entry in my Unbound DNS Overrides?

I would appreciate if anyone could point me in the right direction on diagnosing this.

Thank you!
#5
I believe I found a fix for you. In HAProxy, do you have a single frontend servicing multiple backends? If so, move your Home Assistant frontend configuration to the top of the list. This seems to work for me.
#6
Just found your post, I have the exact same issue on Pfsense w/HAproxy! I don't have a solution but the issue is the same for me.

1. Only in a new browser session (not a tab).
2. I access the main HASS page via haproxy.
3. I can log in or not, but after about 10-12 seconds I get a page reload. This reload comes from a client "get" request to /auth/authorize, and a redirect to https://<mydomain.com>/?auth_callback=1

I cant figure out why the client does this when connected to HASS via HAproxy vs directly to the server.