Regression #12949
closedThe ruleset is not regenerated after assigning an interface
100%
Description
In some circumstances the ruleset is not reloaded or regenerated after re-assigning an interface.
For example after reassigning the WAN from igb0 to lagg0 in the webgui and saving that the WAN interface is correctly switched and brings up an IP as shown in ifconfig:
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: WAN options=e138bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6> ether 00:90:7f:da:44:72 inet6 fe80::290:7fff:feda:4472%lagg0 prefixlen 64 scopeid 0x11 inet 172.21.16.183 netmask 0xffffff00 broadcast 172.21.16.255 laggproto lacp lagghash l2,l3,l4 laggport: ix0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: ix1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> groups: lagg media: Ethernet autoselect status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
But the firewall is not usable because ruleset in place is still referencing igb0:
[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: cat /tmp/rules.debug set limit table-entries 400000 set optimization normal set limit states 397000 set limit src-nodes 397000 #System aliases loopback = "{ lo0 }" WAN = "{ igb0 }" LAN = "{ igb1 }"
That can also be seen in the running rulset:
[2.6.0-RELEASE][root@m470-3.stevew.lan]/root: pfctl -sr | grep igb0 scrub on igb0 inet all fragment reassemble scrub on igb0 inet6 all fragment reassemble pass in quick on igb0 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN" ridentifier 1000000561 pass out quick on igb0 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN" ridentifier 1000000562 pass in quick on igb0 inet6 proto udp from fe80::/10 port = dhcpv6-client to fe80::/10 port = dhcpv6-client keep state label "allow dhcpv6 client in WAN" ridentifier 1000000563 pass in quick on igb0 proto udp from any port = dhcpv6-server to any port = dhcpv6-client keep state label "allow dhcpv6 client in WAN" ridentifier 1000000564 pass out quick on igb0 proto udp from any port = dhcpv6-client to any port = dhcpv6-server keep state label "allow dhcpv6 client out WAN" ridentifier 1000000565 pass in quick on igb0 inet all flags S/SA keep state label "USER_RULE: Allow all ipv4+ipv6 via pfSsh.php" ridentifier 1647298900 pass in quick on igb0 inet6 all flags S/SA keep state label "USER_RULE: Allow all ipv4+ipv6 via pfSsh.php" ridentifier 1647298900 [2.6.0-RELEASE][root@m470-3.stevew.lan]/root: pfctl -sr | grep lagg0 [2.6.0-RELEASE][root@m470-3.stevew.lan]/root:
Tested using a DHCP WAN where both igb0 and lagg0 are pulling leases from the same server.
Tested in 2.6. It does not happen in 2.5.2.
Updated by Steve Wheeler over 2 years ago
Logs from a 2.5.2 VM where I reassigned WAN from em0 to vtnet0 and am able to login at the new IP imediately:
Mar 16 16:00:34 php-fpm 358 /interfaces_assign.php: Shutting down Router Advertisment daemon cleanly Mar 16 16:00:34 check_reload_status 386 rc.newwanip starting vtnet0 Mar 16 16:00:34 php-fpm 358 /interfaces_assign.php: calling interface_dhcpv6_configure. Mar 16 16:00:34 php-fpm 358 /interfaces_assign.php: Accept router advertisements on interface vtnet0 Mar 16 16:00:34 php-fpm 358 /interfaces_assign.php: Starting rtsold process Mar 16 16:00:35 php-fpm 357 /rc.newwanip: rc.newwanip: Info: starting on vtnet0. Mar 16 16:00:35 php-fpm 357 /rc.newwanip: rc.newwanip: on (IP address: 172.21.16.167) (interface: []) (real interface: vtnet0). Mar 16 16:00:35 php-fpm 357 /rc.newwanip: rc.newwanip called with empty interface. Mar 16 16:00:35 php-fpm 357 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.21.16.167 - Restarting packages. Mar 16 16:00:35 check_reload_status 386 Reloading filter Mar 16 16:00:35 check_reload_status 386 Starting packages Mar 16 16:00:36 php-fpm 358 /interfaces_assign.php: Default gateway setting Interface WAN_DHCP Gateway as default. Mar 16 16:00:36 php-fpm 358 /interfaces_assign.php: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6' Mar 16 16:00:36 check_reload_status 386 Restarting ipsec tunnels Mar 16 16:00:36 php-fpm 357 /rc.start_packages: Restarting/Starting all packages. Mar 16 16:00:40 check_reload_status 386 updating dyndns wan Mar 16 16:00:40 check_reload_status 386 Syncing firewall Mar 16 16:00:40 php-fpm 358 /interfaces_assign.php: Creating rrd update script Mar 16 16:00:40 kernel arprequest: cannot find matching address Mar 16 16:00:40 kernel arprequest: cannot find matching address Mar 16 16:00:41 kernel arprequest: cannot find matching address Mar 16 16:00:42 login 81025 login on ttyv0 as root Mar 16 16:00:43 kernel arprequest: cannot find matching address Mar 16 16:00:45 kernel arprequest: cannot find matching address Mar 16 16:00:49 rc.gateway_alarm 85955 >>> Gateway alarm: WAN_DHCP (Addr:172.21.16.1 Alarm:1 RTT:.619ms RTTsd:.121ms Loss:22%) Mar 16 16:00:49 check_reload_status 386 updating dyndns WAN_DHCP Mar 16 16:00:49 check_reload_status 386 Restarting ipsec tunnels Mar 16 16:00:49 check_reload_status 386 Restarting OpenVPN tunnels/interfaces Mar 16 16:00:49 check_reload_status 386 Reloading filter Mar 16 16:00:49 kernel arprequest: cannot find matching address Mar 16 16:00:50 php-fpm 358 /rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP' Mar 16 16:00:50 php-fpm 358 /rc.openvpn: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6' Mar 16 16:00:57 kernel arprequest: cannot find matching address Mar 16 16:00:59 php-fpm 358 /index.php: Successful login for user 'admin' from: 172.21.16.243 (Local Database) Mar 16 16:01:12 kernel arprequest: cannot find matching address Mar 16 16:01:28 kernel arprequest: cannot find matching address Mar 16 16:01:44 kernel arprequest: cannot find matching address Mar 16 16:01:59 kernel arprequest: cannot find matching address
Logs from 2.6 showing the same change (not the same VM though):
Mar 16 19:50:47 php-fpm 412 /interfaces_assign.php: Shutting down Router Advertisment daemon cleanly Mar 16 19:50:47 check_reload_status 450 Linkup starting vtnet0 Mar 16 19:50:47 kernel vtnet0: link state changed to UP Mar 16 19:50:48 check_reload_status 450 Reloading filter Mar 16 19:50:50 check_reload_status 450 rc.newwanip starting vtnet0 Mar 16 19:50:50 php-fpm 412 /interfaces_assign.php: calling interface_dhcpv6_configure. Mar 16 19:50:50 php-fpm 412 /interfaces_assign.php: Accept router advertisements on interface vtnet0 Mar 16 19:50:50 php-fpm 412 /interfaces_assign.php: Starting rtsold process Mar 16 19:50:51 php-fpm 413 /rc.newwanip: rc.newwanip: Info: starting on vtnet0. Mar 16 19:50:51 php-fpm 413 /rc.newwanip: rc.newwanip: on (IP address: 172.21.16.186) (interface: []) (real interface: vtnet0). Mar 16 19:50:51 php-fpm 413 /rc.newwanip: rc.newwanip called with empty interface. Mar 16 19:50:51 check_reload_status 450 Reloading filter Mar 16 19:50:51 php-fpm 413 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.21.16.186 - Restarting packages. Mar 16 19:50:51 check_reload_status 450 Starting packages Mar 16 19:50:52 php-fpm 412 /interfaces_assign.php: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP' Mar 16 19:50:52 php-fpm 412 /interfaces_assign.php: Default gateway setting Interface WAN_DHCP Gateway as default. Mar 16 19:50:52 php-fpm 412 /interfaces_assign.php: Gateway, none 'available' for inet6, use the first one configured. 'WAN_DHCP6' Mar 16 19:50:52 check_reload_status 450 Restarting IPsec tunnels Mar 16 19:50:52 php-fpm 413 /rc.start_packages: Restarting/Starting all packages. Mar 16 19:50:55 check_reload_status 450 updating dyndns wan Mar 16 19:50:55 php-fpm 412 /interfaces_assign.php: Configuration Change: admin@172.21.16.243 (Local Database): Interfaces assignment settings changed Mar 16 19:50:55 check_reload_status 450 Syncing firewall Mar 16 19:50:55 php-fpm 412 /interfaces_assign.php: Creating rrd update script Mar 16 19:50:55 kernel arprequest: cannot find matching address Mar 16 19:50:56 kernel arprequest: cannot find matching address Mar 16 19:50:57 kernel arprequest: cannot find matching address Mar 16 19:50:59 kernel arprequest: cannot find matching address Mar 16 19:51:01 kernel arprequest: cannot find matching address Mar 16 19:51:05 kernel arprequest: cannot find matching address Mar 16 19:51:13 kernel arprequest: cannot find matching address Mar 16 19:51:28 kernel arprequest: cannot find matching address Mar 16 19:51:44 kernel arprequest: cannot find matching address Mar 16 19:52:00 kernel arprequest: cannot find matching address Mar 16 19:52:15 kernel arprequest: cannot find matching address
Updated by Marcos M over 2 years ago
I was able to reproduce this on 2.6 with a default config.
Updated by Steve Wheeler over 2 years ago
Also seeing this in:
2.7.0-DEVELOPMENT (amd64) built on Mon Mar 14 19:29:13 UTC 2022 FreeBSD 12.3-STABLE
And:
22.05-DEVELOPMENT (amd64) built on Wed Mar 16 06:19:09 UTC 2022 FreeBSD 12.3-STABLE
Updated by Viktor Gurov over 2 years ago
- Assignee set to Viktor Gurov
Updated by Jim Pingle over 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov over 2 years ago
- Status changed from Pull Request Review to Feedback
Updated by Viktor Gurov over 2 years ago
- % Done changed from 0 to 100
Applied in changeset d1d1084eb4ebedbcc86cfe13c6d25cf9570646b0.
Updated by Steve Wheeler over 2 years ago
- Status changed from Feedback to Resolved
Confirmed this no longer happens in current 2.7 snapshots. The running ruleset is updated immediately when re-assigning the WAN.
Tested:
2.7.0-DEVELOPMENT (amd64) built on Wed Jun 01 06:12:27 UTC 2022 FreeBSD 12.3-STABLE