Initial observations

[cbb09]

Hello,

I like the changes to 16.7 very much, specifically FreeBSD 10.3. Now I can use my modified coretemp.ko (modified to reduce reported temp by 30C as my proc has a different junction temp).

Unfortunately, the update broke UPnP. Plex and other services that use NAT-PMP or UPnP cannot register their ports anymore. I've restarted the firewall and the various clients, but it doesn't work. OPNsense doesn't register any open ports under "Status" either.

Then, under "Service Status" on the Dashboard, there's suddenly an entry for the dhcpd6 service (not started) although I utilize no IPv6 services. It wasn't there in 16.1 and use the same conf.

The Traffic Graphs show IPsec (which I don't use), but no OpenVPN.

Finally, after reboot, I have to restart the OpenVPN client for it to work. This was an issue in 16.1, but I thought that there was a fix for that.

Thank you! And good work!

[franco]

Hi there,

Thanks for testing!

Unfortunately, the update broke UPnP. Plex and other services that use NAT-PMP or UPnP cannot register their ports anymore.

Didn't hear of this before, I'll take a look.

Then, under "Service Status" on the Dashboard, there's suddenly an entry for the dhcpd6 service (not started) although I utilize no IPv6 services. It wasn't there in 16.1 and use the same conf.

This will be fixed in RC2.

The Traffic Graphs show IPsec (which I don't use), but no OpenVPN.

Did they do that before? We'll have to reiterate in this area, but it's likely not in the first 16.7, but somewhat after.

Finally, after reboot, I have to restart the OpenVPN client for it to work. This was an issue in 16.1, but I thought that there was a fix for that.

There was a fix, but for specific bridged setups. It's hard to tell why this won't work in your case now. Care to share details?


Cheers,
Franco

[cbb09]

Hi there,

Thanks for testing!

Unfortunately, the update broke UPnP. Plex and other services that use NAT-PMP or UPnP cannot register their ports anymore.

Didn't hear of this before, I'll take a look.

Somehow this fixed itself... Probably user error in my side rather than something wrong with 16.7. Sorry about that.

Then, under "Service Status" on the Dashboard, there's suddenly an entry for the dhcpd6 service (not started) although I utilize no IPv6 services. It wasn't there in 16.1 and use the same conf.

This will be fixed in RC2.

The Traffic Graphs show IPsec (which I don't use), but no OpenVPN.

Did they do that before? We'll have to reiterate in this area, but it's likely not in the first 16.7, but somewhat after.

I am not sure, it just noticed it.

Finally, after reboot, I have to restart the OpenVPN client for it to work. This was an issue in 16.1, but I thought that there was a fix for that.

There was a fix, but for specific bridged setups. It's hard to tell why this won't work in your case now. Care to share details?

I set-up the OpenVPN client to connect with an external VPN provider. That interface is then connected to a VLAN. It all works fine, but after reboot the VLAN clients can't connect to the tunnel. In the dashboard, everything seems ok. After manually reconnecting the VPN client, it works fine. I think it has to do with the startup order of how interfaces are enumerated, maybe?

[franco]

Thanks for the OpenVPN/VLAN hint, I may know where to look now.


Cheers,
Franco

[franco]

Other than a small problem with the OpenVPN status page, it looks fine. Let me know if this is still happening on RC2 and provide the OpenVPN log and after reboot see whether "pgrep openvpn" yields a PID.


Cheers,
Franco

[cbb09]

Will do!

[cbb09]

Other than a small problem with the OpenVPN status page, it looks fine. Let me know if this is still happening on RC2 and provide the OpenVPN log and after reboot see whether "pgrep openvpn" yields a PID.


Cheers,
Franco

Forgot to mention: the trunk to my switch is a LAGG interface and my VPN VLAN uses that as a the host interface. Maybe the "initialization" sequence of LAGG and OpenVPN client is the issue?

[franco]

Yes, it sounds like it. Adding LAGG to the equation makes it even more complicated.

Did RC2 help in any way or do we need to keep digging?


Cheers,
Franco

[franco]

I couldn't reproduce this locally. Client comes up ok on reboot. Unless you meant it's up but can't connect.


Cheers,
Franco

[cbb09]

It's actually working since 16.7 RC2! I just noticed that after a short power outage yesterday. After the firewall was back up I checked and could ping external IPs via the OpenVPN client without restarting the service.

[cbb09]

Damn! I just noticed that I had lagg turned off yesterday when I restarted the firewall and the OpenVPN client worked. Today, I turned lagg back on and now the issue is back:

After a reboot, the OpenVPN client gets its IP from my VPN service provider and it all looks fine, but devices on the VLAN that's connected to that interface can't reach WAN addresses. Inter VLAN etc works fine. As soon as I restart the OpenVPN client, it works immediately. All VLANs use the lagg lan interface as their host.

So, the issue is still there, but it seems only when on lagg

[franco]

We could fix this with a small startup script in the meantime if you like as I see that we won't be able to fix that in time for 16.7 anymore.

The initialisation order is correct in the code: lagg, vlan, openvpn so I think it could be a timing issue.


Cheers,
Franco

[cbb09]

We could fix this with a small startup script in the meantime if you like as I see that we won't be able to fix that in time for 16.7 anymore.

The initialisation order is correct in the code: lagg, vlan, openvpn so I think it could be a timing issue.


Cheers,
Franco

Hmm, I think you might be right. lagg might need a moment to connect (dynamic LACP). That could explain why there isn't an issue without lagg. Let's try the startup script.

Many thanks!

[franco]

Ok the general idea is that one can add scripts in /usr/local/etc/rc.syshook.d to either "start", "stop", or "early" (after opnsense is up, before opnsense goes down, or before opnsense configures the network respectively).

# touch /usr/local/etc/rc.syshook.d/openvpn_lagg_fix.start
# chmod 700 /usr/local/etc/rc.syshook.d/openvpn_lagg_fix.start

The contents should be something like:

#!/bin/sh
sleep 5
pkill -HUP openvpn

Not entirely sure this works as is, might need some tweaking. Though if this works we have our problem narrowed down a little. It might be that lagg does not propagate its new state to the vlan device so it doesn't receive a devd event preventing openvpn from reloading or that openvpn itself is not probed during said event.


Cheers,
Franco