Unable to Ping Gateway From inside its own VLAN.
-
Hi All,
I'll get right to the point and I'll admit if it's my own fault, but I cannot see why this VLAN 60 (192.168.60.x /24) cannot ping its own gateway (Eg 192.168.60.2 (Linux VM Host) -> 192.168.60.1 (Pfsense Vlan Interface))
I already have 3-4 other vlans that have different ID and ip ranges and all work fine. Some are for physical devices, some are VMS. In this case, I am pinging or attempting to hit pfSense from a VM. All physical interfaces are trunked and allow for the respective VLAN ID just like the others do now and work fine, but for some reason I cannot get 192.168.60.2 to ping 192.168.60.1.
I will post my rules below and changes I have made. "WireGuard" is the name of the interface for VLAN 60.
When I did a packet capture on pfsense this is what came up:
just showing this20:12:48.763214 IP 192.168.60.2 > 192.168.60.1: ICMP echo request, id 506, seq 33, length 64
20:12:49.786946 IP 192.168.60.2 > 192.168.60.1: ICMP echo request, id 506, seq 34, length 64
20:12:50.811005 IP 192.168.60.2 > 192.168.60.1: ICMP echo request, id 506, seq 35, length 64
20:12:51.834949 IP 192.168.60.2 > 192.168.60.1: ICMP echo request, id 506, seq 36, length 64
20:12:52.858794 IP 192.168.60.2 > 192.168.60.1: ICMP echo request, id 506, seq 37, length 64And couldn't get any feedback back. I have rebooted pfSense, and it did ping during initial startup, but then I assume the firewall and rules took over and it stopped.
Unsure if it helps, but I'm using kea DHCP, although this is all with static IPS and I have changed the firewall state policy to "floating states"
Any questions, please let me know. I could add heaps more but I'm trying to simplify the issue without too much noise. Thanks in advance to any help.
-
@Nath2125 WireGuard as a name is really bad because there is a built-in "interface-group" with that name. Also you should check the red bell with the 57 messages and clear and resolve the issues first before doing anything else.
-
@Bob-Dig the alerts I ignore as they're for ssl certificate expiry I am not needing at this stage. I wasn't aware of any interface name conflictions I will change that now. Would that cause possible issues like this?
-
@Nath2125 said in Unable to Ping Gateway From inside its own VLAN.:
Would that cause possible issues like this?
I am not a developer but maybe you tell them here if this solved your problem.
-
@Bob-Dig It seems it didn't, but appreciate your help regardless.
-
@Nath2125 said in Unable to Ping Gateway From inside its own VLAN.:
it didn't
Your rule looks ok so it might be a problem outside of pfSense.
-
@Bob-Dig Yea, I thought so, but I set everything up the same way as the others vlans that work fine, and I can ping 8.8.8.8 out from the host and also get to my pihole (DNS port) on another vlan just fine. All of which are done via rules I've had added from the get go, but when I add the ICMP one to the ping its own gateway interface just doesn't seem to like it or something else is conflicting.
I did some quick chatgpt and checked "states" as well but no entries for any states on that interface either.
-
Not sure if this helps and came from chat, but ran this in the pfsense shell and my icmp rule if im not mistaken should be labeled here but its not.
-
I have a feeling my issue is for some reason after submission via the webgui its not actually applying it on the backend.
-
Going to mention here as I cant seem to edit the OP. I am on the latest version: 2.8.0-RELEASE
-
It appears after more digging I found my fix. Sort of my fault In a way. I noticed in the command above that my rules that were being applied from the webgui were not showing on the backend rules. After scratching my a head a while, I looked at pfblockerng and noticed it was creating a lot of table IP entries and erroring due to limit. I did enable Geo and IP blocking which would created massive lists and due to this getting stuck it wouldn't write my firewall changes down. So I have adjusted the list limit and audited the IP lists I have enabled, and my rules are now showing.