pfSense » pfSense Plus

tested on

23.09-DEVELOPMENT (amd64)
built on Fri Sep 29 21:07:00 CST 2023
FreeBSD 14.0-CURRENT

Can't reproduce it, tunnel on IPv6 only interface starts immediately after a reboot.
tested on

23.09-DEVELOPMENT (amd64)
built on Sat Sep 30 2:50:00 MSK 2023
FreeBSD 14.0-CURRENT

my WAN is pppoe.

I just updated to this version and this problem did not occur. I will continue to observe and report in the future.
23.09-DEVELOPMENT (amd64)
built on Sat Sep 30 7:50:00 CST 2023
FreeBSD 14.0-CURRENT

This problem occurs again

This sounds like an issue with ordering and PPPoE. Likely the PPPoE connection isn't started prior to the OpenVPN Client trying to start.

As a temporary workaround, you can setup Service Watchdog to monitor the OpenVPN client. This will allow it to be restarted and reconnect after PPPoE is established.

Probably the same problem that I extinguished (from version 23.05.1)

https://redmine.pfsense.org/issues/14811#change-69877

OpenVPN TAP does not start on the client (only after rebooting the device works) - DHCP configuration via Bridge /24

Sep 26 08:35:01 openvpn 64050 FreeBSD ifconfig failed: external program exited with error status: 1
Sep 26 08:35:01 openvpn 64050 /sbin/ifconfig ovpnc1 10.100.200.20/24 mtu 1500 up

log after rebooting the device (everything ok):

Oct 2 16:52:53 openvpn 39792 Initialization Sequence Completed
Oct 2 16:52:53 openvpn 39792 /usr/local/sbin/ovpn-linkup ovpnc1 1500 0 192.168.21.10 255.255.255.0 init
Oct 2 16:52:53 openvpn 39792 /sbin/ifconfig ovpnc1 192.168.21.10/24 mtu 1500 up
Oct 2 16:52:53 openvpn 39792 TUN/TAP device /dev/tap1 opened
Oct 2 16:52:53 openvpn 39792 TUN/TAP device ovpnc1 exists previously, keep at program end

Tested on:

23.01-RELEASE (amd64)
built on Fri Feb 10 20:06:33 UTC 2023
FreeBSD 14.0-CURRENT

(all official patches added)

works without problem, only downgrade or waiting for a patch ?

Still happens with one of the two VPNs

23.09-DEVELOPMENT (amd64)
built on Tue Oct 3 14:00:00 CST 2023

is there any progress yet or will it never work properly ???

Dec 18 10:19:00 openvpn 15608 Exiting due to fatal error
Dec 18 10:19:00 openvpn 15608 FreeBSD ifconfig failed: external program exited with error status: 1
Dec 18 10:19:00 openvpn 15608 /sbin/ifconfig ovpns3 10.0.8.1/30 mtu 1500 up

Dec 18 10:10:00 openvpn 80880 Exiting due to fatal error
Dec 18 10:10:00 openvpn 80880 FreeBSD ifconfig failed: external program exited with error status: 1
Dec 18 10:10:00 openvpn 80880 /sbin/ifconfig ovpns3 172.20.2.1/24 mtu 1500 up

Version 23.09.1-RELEASE (amd64)
built on Sat Dec 9 18:57:00 CET 2023
FreeBSD 14.0-CURRENT

Łukasz Rojczyk wrote in #note-12:

is there any progress yet or will it never work properly ???

Dec 18 10:19:00 openvpn 15608 Exiting due to fatal error
Dec 18 10:19:00 openvpn 15608 FreeBSD ifconfig failed: external program exited with error status: 1
Dec 18 10:19:00 openvpn 15608 /sbin/ifconfig ovpns3 10.0.8.1/30 mtu 1500 up

Dec 18 10:10:00 openvpn 80880 Exiting due to fatal error
Dec 18 10:10:00 openvpn 80880 FreeBSD ifconfig failed: external program exited with error status: 1
Dec 18 10:10:00 openvpn 80880 /sbin/ifconfig ovpns3 172.20.2.1/24 mtu 1500 up

Version 23.09.1-RELEASE (amd64)
built on Sat Dec 9 18:57:00 CET 2023
FreeBSD 14.0-CURRENT

Hello,

Are you able to crank up the verbosity of your OpenVPN client's logging and see if there is any additional details on the failure?

Jan 4 13:00:00 openvpn 21642 Exiting due to fatal error
Jan 4 13:00:00 openvpn 21642 FreeBSD ifconfig failed: external program exited with error status: 1
Jan 4 13:00:00 openvpn 21642 /sbin/ifconfig ovpns3 172.20.2.1/24 mtu 1500 up
Jan 4 13:00:00 openvpn 21642 do_ifconfig, ipv4=1, ipv6=0
Jan 4 13:00:00 openvpn 21642 TUN/TAP device /dev/tap3 opened
Jan 4 13:00:00 openvpn 21642 TUN/TAP device ovpns3 exists previously, keep at program end
Jan 4 13:00:00 openvpn 21642 TLS-Auth MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Jan 4 13:00:00 openvpn 21642 MTU: adding 432 buffer tailroom for compression for 1800 bytes of payload
Jan 4 13:00:00 openvpn 21642 PID packet_id_init seq_backtrack=64 time_backtrack=15
Jan 4 13:00:00 openvpn 21642 Incoming Control Channel Encryption: HMAC size=32 block_size=32

nothing smarter, level 11

I have diagnosed something, so far I know that removing the TAP bridge from the LAN solves the problem above.

Is there anyone here from pfSense who writes code and can tell what has been changed that now the bridge cannot be done ?

I haven't yet checked that just adding in iptables rules allows MACs through without manually adding a bridge ....