Messages

the IP address 10.1.21.20 is assigned to a network printer.

This printer was reachable via HTTPS Admin GUI and pingable in the past. And it answers pings to the OPNsense, when using the built in ping command from the gateway of

• 020_equipment 10.1.20.1
• 010_trusted clients 10.1.100.1
• but not from 10.1.100.68 or 10.1.101.68

and nothing changed on the printer setup. The only I changed was setting up the firewall fresh.

I checked the printers settings, it has
IP Address: 10.1.21.20
Subnet mask: 255.255.254.0
Gateway: 10.1.20.1

all given out by DHCP.

[cannot]

Hi,

I'm kind of blind, where to look for issues anymore. It is OPNsense 24.1.7_4-amd64

I have two vLANs
020_equipment 10.1.20.1/23
100_trusted_clients 10.1.100.1/23

I have two floating rules, that have these interfaces assigned, saying

• direction IN/OUT IPv4/IPv6 any to any, any protocoll
• no further rules defined anywhere else

I can ping

• 10.1.20.1 to a device 10.1.21.20
• 10.1.100.1 to a device 10.1.20.1

but I cannot ping 10.1.101.68 to 10.1.21.20, while the life view of the firewall shows green for the ICMP packages.

Run into the same issue today. Solution is easy. Select () next to enable) the the machine you want to see aliases for in the Override section, than it is showing the aliases. (My 2 cents to the issue: Bad UI design.)

https://github.com/opnsense/core/issues/5752 

Hallo,

die Schritte sind eigentlich immer:
* VLANs anlegen
* Schnittstellen (Interfaces) für das netzwerkgebundene VLAN erstellen (keine weiteren Einstellungen wie IP Adresse u.ä.)
* Schnittstelle für das WLAN erstellen und ggf. die WLAN pecifischen Einstellungen vornehmen (auch hier keine IP Adressen vergeben)
* eine Bridge erstellen und beide Interfaces (LAN+WAN) hinzufügen
* auf dem Bridge Interface dann die IP spezifischen Einstellungen vornehmen und dafür dann auch DHCP/DHCPv6 anlegen

PF Regeln werden default auf den Member Interfaces angelegt, was ich aber etwas unhandlich fand. Ich filtere ausschließlich für das Bridge Interface, also werden die PF Regeln auch nur dort angelegt. Dafür mussten dann
die unter System > Advanced  für net.link.bridge.pfil_member geändert werden.

Viele Grüße,
Kay-Uwe 

Hi,

due to the PPPoE reconnect issue, I have to restart the OPNsense (v18.7.5_1) on a daily base and I see, that OpenVPN failed to start in these procedure. This is a fresh installation. By the way, I'm able to connect to the OpenVPN Gateway, even if it shows, it's not up. So I guess these is a mismatch between GUI and real world.

These is, how it looks in bash:
root@fw:~ # ps aux | grep openvpn
root    13532   0.0  0.2 1085792   6404  -  Ss   06:38    0:00.17 /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf


Oct 24 06:38:28   openvpn[13532]: Initialization Sequence Completed
Oct 24 06:38:28   openvpn[13532]: IFCONFIG POOL: base=10.4.6.2 size=252, ipv6=0
Oct 24 06:38:28   openvpn[13532]: MULTI: multi_init called, r=256 v=256
Oct 24 06:38:28   openvpn[13532]: UDPv4 link remote: [AF_UNSPEC]
Oct 24 06:38:28   openvpn[13532]: UDPv4 link local (bound): [AF_INET]89.247.XXX.XX0:1194
Oct 24 06:38:28   openvpn[13532]: Socket Buffers: R=[42080->42080] S=[57344->57344]
Oct 24 06:38:28   openvpn[13532]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Oct 24 06:38:27   openvpn[13863]: Exiting due to fatal error
Oct 24 06:38:27   openvpn[13863]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
Oct 24 06:38:27   openvpn[13863]: TUN/TAP device ovpns1 exists previously, keep at program end
Oct 24 06:38:27   openvpn[13863]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:38:27   openvpn[13863]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:38:27   openvpn[13863]: Diffie-Hellman initialized with 4096 bit key
Oct 24 06:38:27   openvpn[13863]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 24 06:38:27   openvpn[13863]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Oct 24 06:38:27   openvpn[13863]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Oct 24 06:38:27   openvpn[13532]: /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpns1 1500 1622 10.4.6.1 255.255.255.0 init
Oct 24 06:38:27   openvpn[13532]: /sbin/route add -net 10.4.6.0 10.4.6.2 255.255.255.0
Oct 24 06:38:27   openvpn[13532]: /sbin/ifconfig ovpns1 10.4.6.1 10.4.6.2 mtu 1500 netmask 255.255.255.0 up
Oct 24 06:38:27   openvpn[13532]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Oct 24 06:38:27   openvpn[13532]: TUN/TAP device /dev/tun1 opened
Oct 24 06:38:27   openvpn[13532]: TUN/TAP device ovpns1 exists previously, keep at program end
Oct 24 06:38:27   openvpn[13532]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:38:27   openvpn[13532]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:38:27   openvpn[13532]: Diffie-Hellman initialized with 4096 bit key
Oct 24 06:38:27   openvpn[13532]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 24 06:38:27   openvpn[13532]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Oct 24 06:38:27   openvpn[13532]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Oct 24 06:38:27   openvpn[12925]: library versions: LibreSSL 2.7.4, LZO 2.10
Oct 24 06:38:27   openvpn[12925]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018
Oct 24 06:38:27   openvpn[13058]: library versions: LibreSSL 2.7.4, LZO 2.10
Oct 24 06:38:27   openvpn[13058]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018

The service button stays red and any restart try fails with these logs:

Oct 24 06:45:57   openvpn[50915]: Exiting due to fatal error
Oct 24 06:45:57   openvpn[50915]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
Oct 24 06:45:57   openvpn[50915]: TUN/TAP device ovpns1 exists previously, keep at program end
Oct 24 06:45:57   openvpn[50915]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:45:57   openvpn[50915]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Oct 24 06:45:57   openvpn[50915]: Diffie-Hellman initialized with 4096 bit key
Oct 24 06:45:57   openvpn[50915]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Oct 24 06:45:57   openvpn[50915]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Oct 24 06:45:57   openvpn[50915]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Oct 24 06:45:57   openvpn[50391]: library versions: LibreSSL 2.7.4, LZO 2.10
Oct 24 06:45:57   openvpn[50391]: OpenVPN 2.4.6 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 15 2018

I see no difference in behaviour between OpenSSL and LibreSSL installs. Only way to get a match between GUI and bash, is killing the running OpenVPN process and start by hand.

Kind regards,
kug1977

I have setup such a scenario here. The WAN address is bound to a DynDNS name and updating on any change of WAN IP. The tunnel is using the name for Phase 1 and a shared secret. But it should work with a certificate too.

Hi,

following these steps, I have now a working WAN connection, but I see in the system logs:

opnsense: /usr/local/etc/rc.filter_configure: New alert found: There were error(s) loading the rules: /tmp/rules.debug:16: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [16]: table <bogonsv6> persist file "/usr/local/etc/bogonsv6"

while the bogonsv6 table is filled and the /usr/local/etc/bogonsv6 is recreated / filled with # last updated 1522126201 (Tue Mar 27 04:50:01 2018 GMT) content.

It's a bit strange.

Kind regards,
kug1977

Hi, are you on OPNsense 18.1.5 too?

Hi,

>Do you guys have IPS enabled?
No, not enabled.

>Btw, if you disconnect the WAN network cable and reconnect after a few seconds, is the PPPoE working again?
No, it needs a restart after.

Setup is:
Deutsche Telekom VDSL 50
Draytek Vigor 130 in PPPoE path-through /bridge mode
APU1D with OPNsense 18.1.2 on eth0

Kind regards,
Kay-Uwe

Hi,

I'm on OPNsense 18.1.2 and I'm facing the same problem. Solution so far is the cron reboot every day.

Kind regards,
Kay-Uwe

Hi,

I've an APU1 board for OPNsense 18.1.1 and on port 0 works a Vigor 130 as VDSL modem. The Interface is configured as IPv4 / PPPoE and IPv6 / DHCPv6. I have enabled "Block private networks" and "Block bogon networks". Only username and password is set.

On a restart, the WAN come up and work probably. But it will not survive the daily forced separation and stay in interface overview than with status "up", but no network is working. It need a restart to work again. It stopped working after the upgrade to 17.7.11. 17.7.10 was working fine.

I can see in the logs at this time the following entries in /var/log/ppps.log. What is different between  re-negotiation and restart is the entry Feb  3 15:35:31 fw2 ppp: caught fatal signal TERM.

Any idea, why the re-negotiation is failing?

Kind regards,
Kay-Uwe

Hi,

moving back to 10.7.10 and WAN renegotiate is working again. But it stay broken on 17.7.11, 17.7.12 and 18.1. As I'm on 18.1 now, I will open a new ticket there.

Thanks,
Kay-Uwe

Hi,

which version have you installed, 17.7.12? Have seen these too. ou can try to downgrade to 17.7.10 and see, if these solves the resync.

# opnsense-revert -r 17.7.10 opnsense

Kind regards,
Kay-Uwe

Hi Franco,

you're right, I was on opnsense-devel ... switched back to opnsense and revert to 17.7.10. I will test, how it will handle the renewal today and report.

Kind regards,
Kay-Uwe

both commands are not working:
# opnsense-revert -r 17.7.10 opnsense
Package 'opnsense' is not installed

so it seems to be something is broken.