2.1.5 to 2.2.4 can't ping from LAN interface

[yaboc]

so i've upgraded from 2.1.5 to 2.2.4 remotely.
the WAN works, i can ping from it however if i try to ping from LAN interface i receive 100 packet loss
in the log i see LAN interface as 192.168.100.1 which is different from my LAN interface before upgrade 10.xx.xx.xx. when i check interfaces everything shows as my old interface config but in the log i see 192.  any ideas whhat could be wrong ? Thanks

[cmb]

Do you have multiple IPs on the LAN? Where it's a bridge, the order may be such that the alias shows rather than the primary interface IP, though that would have been the same in 2.1.5 and earlier, and is only cosmetic. Nothing in the upgrade changes interface config or IPs. Which log are you referring to?

[yaboc]

im looking at the firewall log

LAN   Icon Easy Rule: Add to Block List 192.168.100.1
Cannot resolve Icon Reverse Resolve with DNS  Icon Easy Rule: Pass this traffic 224.0.0.1 IGMP

mutiple public ips? nope it's just one LAN interface and one WAN interface.
i tried to backup interfaces / reapply and reboot but still no go.

WAN still works as it connects through IPSEC to another site.

it seems that only the sites with siproxd package installed are giving me problems. the package was removed prior to the upgrade thou.

[cmb]

That's just IGMP log spam, coming from something on your LAN with IP 192.168.100.1. That's from a different system on the network and has no relation to any problem, unless maybe it's a router that's handing out DHCP to your LAN on its network.

What can't you ping?

The WAN and LAN are working if your VPN's working.

[yaboc]

from 'non working' system

PING 8.8.8.8 (8.8.8.8) from xx.xx.xx.xx WAN: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=8.964 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=11.039 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=9.890 ms

–- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.964/9.964/11.039/0.849 ms

PING 8.8.8.8 (8.8.8.8) from 10.xx.xx.xx LAN: 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

from working system i can ping 8.8.8.8 from both LAN/WAN

and yes I can ping my the other side of IPsec from the LAN that can't ping 8.8.8.8
i have no system's with 192.XX.XX.XX

[yaboc]

tried to roll back to 2.1.5 without the config and the behavior followed

[cmb]

Probably missing outbound NAT where you can't ping sourced from the LAN IP. If it's set to automatic outbound NAT, that's probably because either you have a gateway set under Interfaces>LAN (which is wrong, remove it), or if your WAN is a static IP, you don't have a gateway selected under Interfaces>WAN.

You most definitely have something on 192.168.100.1 on the LAN of the system where you got that firewall log. If you put a static 192.168.100.x IP on that LAN, and try to reach HTTP and HTTPS on 192.168.100.1, you'll probably see what it is. That's unrelated to pinging from the LAN IP though, that's likely a NAT issue.

[yaboc]

Int > LAN has no gateway set
Int > WAN is static IP and has gateway set

under NAT > Outbound i checked automatic outbound NAT but no rules are generated.

can ping 8.8.8.8 from WAN but not LAN. Also now pFsense can't check for update

still trying to fix it remotely but if no luck i'll factory reset and restore from backup.

to recap

still this only happens after i removed siproxd and upgraded to 2.2.4. downgraded back to 2.1.5 and the issue persists.

on another system with 2.1.5 and no packaged installed/removed upgrade to 2.2.4 was successful.

[cmb]

Maybe the filter isn't loading for some reason. What do you get if you try to run 'pfctl -f /tmp/rules.debug' from a command prompt?

[yaboc]

thanks cmb. since this is was a production system i just went ahead and restored back to 2.1.5 (did't have 2.2.4 install on USB drive) and restored the config. i'll check your suggestion when i'm going to be upgrading a couple systems (locally) soon. thanks for your help it was very helpful and yes I did have 192. dumb switch on the network (another thing I'm trying to slowly eliminate).