local LAN traffic blocked
-
Entirely possible I have fat-fingered something :) but I've attempted to double-check everything. I will be more than happy if it is that simple. Checking.
-
See my edit, say a /27 or /28 etc.. on the .103 or .104 boxes would put .73 outside their networks. So traffic would be sent to its gateway.. (pfsense)
-
Just checked one - can only intermittently reach over network to the web UI. Manually plugged into the eth port (as opposed to wifi) to connect and take a look. Mask was correct - /24, but I had also changed each camera to point to a non-existent GW setting so that video stream could not route outside. Changed that (GW) back and it connected immediately. Should not have made a difference as cameras and DVR_PC are on same subnet. Will check the rest to confirm but assume that is it as I'd changed GW on all.
-
Can you not just leave the gateway blank? If gateway was wrong, how would it ever have sent data to pfsense at all?
Clearly missing piece of the puzzle..
-
I agree 100%. Have never seen this type of behavior. Blank is what I normally do but these cameras seem to validate the entries for each octet to be between 1-254, and for the entire ip to match subnet, so I couldn't make them blank. I'll create a fw rule instead.
-
That was it. Still doesn't make sense to me but I changed the GW back to the valid GW for each camera and they started communicating correctly again. Sorry for the confusing post but I was stumped. Couldn't understand (and still don't) why a block was showing in the pfSense fw logs for traffic that shoudl never pass through the fw. It is working now. Thanks for having me take another look.
-
I expect that gateway was elsewhere, along with misconfigured address, etc. caused packets to try to leave the network.
-
Makes no sense at all.. There would be no way the device would of sent traffic to pfsense at all, if its wasn't the gateway..
And if the devices on the same network per their masks, there would be no reason to send traffic to the gateway, no matter what it was, etc.
Clearly some piece of the puzzle is missing.
Only thing that would make sense is the devices for whatever reason thought that pfsense IP was the .73 box.. Can you look in their arp table?
-
@johnpoz said in local LAN traffic blocked:
Can you not just leave the gateway blank?
I have seen some gear that will not let you save the settings, without a gateway address.
-
I guess no one believes the masks were correct :) but I can confirm the mask was correct on each - not even a single fat-finger. These cameras have been running for over a year and the subnet they sit on hasn't changed at all. The only changes I made were to the gateway settings hoping to add another layer of difficulty to exporting camera data out of the subnet. Didn't even change the wifi settings, just migrated the SSID/encryption/etc to the new AP. The only thing I changed to restore functionality was the gateway from a non-existent .12 to the correct host.
After having to manually attach to and change each, I will be creating DHCP reservations so I never have to do that again in the future :)
These are pretty good but relatively basic cameras (Amcrest) and I don't see any CLI access in the webUI to check arp tables. Don't see any ssh settings either and could't reach with ssh/putty.
-
I believe you - but this is why some info is missing that would explain what you were seeing.
If two devices on the same network, they would never send any traffic to the gateway. Pfsense was blocking out of state traffic SA. So for whatever reason these devices on .103 and .104 were sending their syn,ack to pfsense.
So either the device thought that .73 was not on its network, and would need to send to its gateway, but you stated that pfsense was not even the gateway, it was some other IP..
The only thing that really makes any sense was that these devices thought that the .73 they were sending their SA too was pfsense mac address. The question is how or why?
-
Again, I agree with what you're saying :) pfSense is the valid gateway, but they were not pointing to it. These cameras have always pointed to .73. All of the involved devices have always lived on the 192.168.111.x/24 network. The pfSense ip has always been the gw for that subnet although pfSense just moved there - pfSense was originally the gw on an outer subnet. Before and after the cutover, the cameras and the DVR_PC could continue to ping each other by IP, so they had each other's MAC resolved and the path to each was known - no hops in between. I had even reset the switch these connect to earlier today because I thought something may have been wrong/bad/corrupted in it's MAC tables. There was never a point where the devices failed to ping each other.
I did change the .73 host from a static IP of .73 to a DHCP reservation for it's MAC so that pfSense now hands it .73 but that shouldn't have affected anything either.
Changing from a wrong gw on the cameras to the correct one is the only change I made to resolve what I was seeing. I'm sure there is a piece that I don't see that would give us, as Paul Harvey used to say, the rest of the story. I will be making other changes to this network and it is driving me nuts not seeing the missing link so I can say I know what was happening.
Thanks for all of the responses. Keeps me on my toes.