OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: meepmeep on March 29, 2023, 03:12:29 pm
-
Hi
I just upgrade to OPNsense 23.1.5 on my 2 sites (home and remote). And since the reboot of both server, I have no traffic on the wireguard interface.
- No traffic from any client to the main (remote) server
- No traffic between the 2 site (wireguard site-to-site)
Changelog of this version show no impact on wireguard.
The configuration has not changed since few months, and previous upgrade went smoothly, pointing to an upgrade error on 23.1.5 ?
(plugins os-wireguard is installed but os-wireguard-go is not)
interface: wg0
public key: 5awzdJKxxxxxxxxx
private key: (hidden)
listening port: 994
peer: O5Wxxxxxxxx
allowed ips: 10.7.0.225/32
transfer: 0 B received, 32.23 KiB sent
persistent keepalive: every 20 seconds
peer: L/W9xxxxx
allowed ips: 10.7.0.210/32
peer: jbx
allowed ips: 10.7.0.200/32
transfer: 0 B received, 31.94 KiB sent
persistent keepalive: every 20 seconds
peer: EjjDFxxxxxxx
allowed ips: 10.7.0.130/32
transfer: 0 B received, 32.38 KiB sent
persistent keepalive: every 20 seconds
peer: n8gxxxx
allowed ips: 10.7.0.132/32
transfer: 0 B received, 31.94 KiB sent
persistent keepalive: every 20 seconds
peer: B2Cxxxxx
allowed ips: 10.7.0.134/32
transfer: 0 B received, 32.38 KiB sent
persistent keepalive: every 20 seconds
peer: QTxxxx
allowed ips: 10.7.0.133/32
transfer: 0 B received, 32.23 KiB sent
persistent keepalive: every 20 seconds
peer: Saxxxxxx
allowed ips: 192.168.1.0/24, 10.7.0.254/32
transfer: 0 B received, 31.22 KiB sent
persistent keepalive: every 25 seconds
peer: 2Dxxxxxx
allowed ips: 10.7.0.221/32
transfer: 0 B received, 32.23 KiB sent
persistent keepalive: every 20 seconds
-
Are you using network-Aliases in the corresponding Firewall-Rule?
For me 23.1.5 seems to have issues with network-aliases again.
When i look at Firewall -> Diagnostics -> Aliases some of me network-aliases are empty. (maybe something like this issue? https://github.com/opnsense/core/issues/5788)
-
Yes, a lot (as a destination WAN ip for wireguard rule for example)
-
and if you look at Firewall -> Diagnostics -> Aliases... are your aliases empty as well?
-
yes, "WAN1" is empty.
I changed the rule to use an IP instead of the alias .. and it's working.
-
Screenshots would help communicating this clearly. Applying aliases doesn't change it?
Cheers,
Franco
-
Hi franco,
Applying aliases doesn't fix the issue.
i did run "/usr/local/opnsense/scripts/filter/update_tables.py" which returned {"status": "ok"} - but alias is still empty
here are some screenshots:
Alias defined as:
(https://i.imgur.com/dhD0SSc.png)
not showing up under Firewall -> Diagnostics -> Aliases:
(https://i.imgur.com/qEF1wMx.png)
Thanks,
BR
Edit: Strange thing is that other aliases with networks working well, also wenn i create a Internal_LAN2 with the same Subnet it is working perfectly...
-
I have multiple WAN ip on my server.
WAN1 and WAN2 are alias to thoses ip :
(https://ordu.re/u/xACi7/xaLoFAvU07.png/raw)
WAN1 alias is empty in diag:
(https://ordu.re/u/xACi7/hoZeSAqU56.png/raw)
So rules with this alias are not working :
(https://ordu.re/u/xACi7/RopixatO94.png/raw)
Is a replace WAN1 by the ip address directly, it works.
-
And what happens on:
# configctl template reload OPNsense/Filter
Cheers,
Franco
-
root@MGMT-FW02:~ # configctl template reload OPNsense/Filter
OK
... but alias still empty
-
I have also issues regarding aliases / NAT. While IPv6 network aliases work I also have mixed network allies which includes IPv6 and IPv4 networks. After the upgrade to 23.1.5 only IPv6 works, all IPv4 inbound NAT rule which are filled with alias does not work. They are all populated correctly under Aliases. Even when I hoover over them in UI they are listed there. I reverted back to 23.1.4_1 using opnsense-revert -r 23.1.4_1 opnsense and NAT / port forwarding does work instantly without a reboot. I compared the /tmp/rules.debug file with the /tmp/rules.debug.old where the latter was the version from 23.1.5 and the first from 23.1.4_1 and indeed all RDR and NAT which are using aliases where missing from the 23.1.5 file.
-
I don't use any Aliases in the NAT section with IPs but do with ports. It seems this is working as expected after upgrading.
I do use IPs in aliases on rules and those are fine for me.
Just different points of data.
-
I use aliases, but I'm not seeing this issue in 23.1.5.
-
Ok, so far nothing...how about the content of this file?
# cat /usr/local/etc/filter_tables.conf
Thanks,
Franco
-
# cat /usr/local/etc/filter_tables.conf
the files looks the same between versions. I re-applied the 23.1.5 update, rebooted and the issue was still present. I looked at the commits in Github and found Firewall/Aliases - refactor alias update script. I just did a rm -f /var/db/aliastables/* && /usr/local/opnsense/scripts/filter/update_tables.py and everything was working again.
-
Odd. It might be related to https://forum.opnsense.org/index.php?topic=33297.0 and wrong time in the system.
# opnsense-patch 4ac3e1d57368
# killall ntpd
# pluginctl -s ntpd start
# /usr/local/opnsense/scripts/filter/update_tables.py
(this is only a theory but can't hurt)
Cheers,
Franco
-
Thanks rsk this saved my ass.
If I went to Firewall -> Aliases -> Search for alias things looked fine
When I went to Firewall -> Diagnostics -> Aliases and selected the alias, it was empty.
I took your advice and did rm -f /var/db/aliastables/* && /usr/local/opnsense/scripts/filter/update_tables.py and now everything works again. Firewall -> Diagnostics -> Aliases -> selected alias now shows what should be in the alias, which fwiw is an ipv6 /32 network alias.
-
for me it is not related to ntpd.
it is the same behaivor again as descripted here:
https://github.com/opnsense/core/issues/5788
- Create an alias with only one network in it
- reboot
- pfctl -t $ALIAS_NAME -T show - returns nothing
-
for me it is not related to ntpd.
it is the same behaivor again as descripted here:
https://github.com/opnsense/core/issues/5788
me too. ntpd / system time was fine. I also think that there is a regression regarding alias #5788
-
23.1.5_2 fixed it.