Cant ping one device unless on same subnet…
-
Btw, I have excatly your setup : all my company stuff on LAN, and a guest Wifi on OPT1 : 192.168.2.0/24
I'm very able to PING any of my 4 AP's (on OPT1: 192.168.2.2 192.168.2.3 192.168.2.4 etc) from a device (PC) on LAN (example : a PC 192.168.1.3).Just one question : you didn't hooked up your AP using its "WAN" port, did you ?
NOPE
-
An AP wouldn't have a "wan" port - because a AP doesn't route.. So there would not be any distinction between a wan and a lan..
The AP In question
https://www.netgear.com/business/products/wireless/business-wireless/wndap360.aspx#tab-techspecsOnly has 1 network interface - while it does have a rj45 console port.. It wouldn't work at all for clients if his network was plugged into this port.
From a quick look at the manual - I don't see any sort of security were you could enable/block remote access from different network. The symptoms point to the gateway of the AP being wrong.. Or maybe some possible vlan misconfig is this 192.168.2 network a vlan or is just a normal untagged network?
What are your rules on your 192.168.1.0/24 interface in pfsense? Can you please post them up (screenshot is best)
**No VLAN is in use.
AP gateway is 192.168.2.1 (as it should be - as is the gatewway for all other .2 devices that are pingable)**
-
Look.
You can blame pfSense and disregard our advice all day long but it is not going to solve your problem.
Like I said, pcap it and post that here.
If pfSense is sending ICMP to 192.168.2.2 on the correct MAC address and receiving nothing in reply, there is nothing more for it to do and no setting there will fix that.
And you should seriously consider upgrading to something current.
-
Yes I would agree with Derelict here do a simple capture on pfsense to see if the pings are being sent to your AP and the correct mac of the AP. As he says if your not getting a reply that would have nothing to do with pfsense.
From looking at the manual of the AP, it seems it can do packet captures as well - if so you can validate that it seeing the ping or not..
Your first 2 lan rules the 192.168.1 interface seem pointless. How would the 192.168.2 network ever be a source into the lan interface? And what exactly is the 2nd rule suppose to do since it an allow and then right under that you have a allow any any rule. So that would be of no use - unless you wanted to log this traffic which you don't seem to have marked on the rule.
Also yeah what version of pfsense are you running - that gui for sure is not current version.
-
Also yeah what version of pfsense are you running - that gui for sure is not current version.
Agreed we have fallen back to the previous version in our lab to test this as we cannot keep poking at production.
I assure you the behavior and configuration is identical though.
-
Also, don't overlook that one point I made earlier about the diagnostic ping…
Quote from: Derelict on Today at 01:31:12 am
Can you ping 192.168.2.2 from pfSense (Diagnostics > Ping)
Yes.
...When pinging from the .2 interface.
HOWEVER...
When pinging from the .1 interface - NO
In fact, pinging anything in 192.168.2.2 from the .1 interface ALSO does not work -
Please stop abbreviating. Use full IP addresses and netmasks.
So, pcap for ICMP to 192.168.2.2 on the 192.168.2.0/24 interface while pinging from 192.168.1.1.
Post that.
This is dead-simple stuff. It all works.
Do you have a gateway set on the pfSense interface for 192.168.2.0/24? If you do, remove it.
-
"Do you have a gateway set on the pfSense interface for 192.168.2.0/24? If you do, remove it."
You should not have gateways set on any lan interface 192.168.1 or 192.168.2
And I agree also please you full addresses, or atleast the last two octets.. When you say .2 what do you mean the IP address of the AP or the IP of pfsense 192.168.2 interface which is what 192.168.2.1?
-
"Do you have a gateway set on the pfSense interface for 192.168.2.0/24? If you do, remove it."
You should not have gateways set on any lan interface 192.168.1 or 192.168.2
And I agree also please you full addresses, or atleast the last two octets.. When you say .2 what do you mean the IP address of the AP or the IP of pfsense 192.168.2 interface which is what 192.168.2.1?
There are no default gateways specified on any of the LAN interfaces.
(We build these units for clients and have used them for years.)Also, the addresses for all of these devices are clearly outlined earlier in this thread in fact, I have provided a Visio diagram that fully documents it.
So, when I refer to .1 and .2 networks I am referring to the networks we established earlier in this thread.
-
Yet you still provide no information.
I think I'm done here.
-
Yet you still provide no information.
I think I'm done here.
I have provided EXCELLENT information in the FIRST POST, and subsequently every time have been asked.
It's OBVIOUS from your request that you haven't read this thread.
There is nothing I haven't provided.
However, you are quite rude, and I agree…. it's best you that you go. -
Yes I would agree with Derelict here do a simple capture on pfsense to see if the pings are being sent to your AP and the correct mac of the AP. As he says if your not getting a reply that would have nothing to do with pfsense.
From looking at the manual of the AP, it seems it can do packet captures as well - if so you can validate that it seeing the ping or not..
I'm working on getting the packet captures.
Your first 2 lan rules the 192.168.1 interface seem pointless. How would the 192.168.2 network ever be a source into the lan interface?
**We have those two rules to allow iPads to watch training videos from a video server.
The second is for IP cameras on the .2 interface that that to reach a surveillance server on the .1 network.
The last rule is the default LAN allow rule that allows access from .1 to any of the other networks on the box including the Internet**
And what exactly is the 2nd rule suppose to do since it an allow and then right under that you have a allow any any rule. So that would be of no use - unless you wanted to log this traffic which you don't seem to have marked on the rule.
Okay, with regard to the order of the allow any rule, I would assume that the rules are ordered that was because the rule logic goes "top down", yes?
-
You do know that you can take them right from pfSense in Diagnostics > Packet Capture right?
Rules apply to traffic ENTERING an interface. John's point is that it is not possible for traffic to ENTER LAN1 with a LAN2 source address so the rule is nonsense and will never match. If you were running a current version you would have counters that would show you that the rule is never matched and has no effect.
It proves you have a fundamental misunderstanding of how pfSense works in general. Get over yourself and realize that the problem you are having has zero to do with pfSense and you'll be taking the first step toward finding the actual issue in your network/design.
-
You do know that you can take them right from pfSense in Diagnostics > Packet Capture right?
Yes.
Rules apply to traffic ENTERING an interface. John's point is that it is not possible for traffic to ENTER LAN1 with a LAN2 source address so the rule is nonsense and will never match. If you were running a current version you would have counters that would show you that the rule is never matched and has no effect.
**Yes, I can see that, and had these rules had anything to do with the device at 192.168.2.2, I would have focused on them.
However, this issue centered around the AP being the ONLY device on the entire network that is un-pingable.When I have time to diagnose this further, I will capture and examine in more detail.**
"It proves you have a fundamental misunderstanding of how pfSense works in general.
**…aaaaaaaand here we go.
You just can't help yourself can you?
You just HAVE have to mock people, don't you?
Does this make you feel better?So, you condescend and belittled me 3 times in this thread before you just tipped my scale.
In doing this, you squarely call into question how you got the role of "Global Moderator".
You are not "moderate" in any sense of the word when it comes to being a member of the management of this community.**
Get over yourself and realize that the problem you are having has zero to do with pfSense and you'll be taking the first step toward finding the actual issue in your network/design.
Amazing irony here.
I have never ONCE behaved in a way that was self-important, whereas you have several times in this thread.
You sir are the ONLY one that needs to "get over themselves."
For the curious folk out there that wonder how seriously hot-headed this guy is, you would need to see what I received in my inbox. just before this last reply above…
It seems that Derelict got so frustrated with my previous reply that he simply "LOCKED" this topic.
(ever heard a kid "rage quit" on XBOX Live? - I'm sure it was kinda like that.)Only 2 minutes later to "UNLOCK" the topic and spend nearly 10 minutes constructing the reply you see above.
You sir are a condescending, hot-head and frankly have no business interacting with customers/users at the level of authority you currently hold on this forum.
Don't take my word for it, lets look at your "Karma" record.
Karma is a feature that shows the popularity of members.
This allows members to "applaud" or "smite" a member to raise or lower that member's karma.This is likely a huge reason that almost a FULL 1/3rd of your posts are marked as "negative" on this forums' Karma scale.
(Based on your 5.5 posts-per-day rate, that's about 2 times a DAY that you rub someone the wrong way)You seriously should think about that next time you decide to post a reply to loyal users of this product, much less before you tell them to "get over themselves".
.
-
So, again, here you are not wanting help with your problem.
-
Are we going to see this packet capture or not?? I mean really it takes 2 seconds to do?? Your spending more time quoting and then bold your response then it would take to do a packet capture..
The thing about the rules - when a user posts rules that are pointless, and show a lack of understanding of how pfsense works, and also running old version… It doesn't scream this guy knows what he is doing ;)
And then asked repeatedly for something that would take 2 seconds to produce - but just continues to point the issue to pfsense without some simple proof.. Show your packet capture on pfsense lan, and then on your other with the ping not going out... Then this would point to pfsense not forwarding on the ping for some reason.
Lets just say it gets frustrating.. As to smites.. I have quite a lot as well... You want to know where 90% if not more come from? Some idiot that gets heated over asking for information... And then goes off like you just did saying the person trying to help you is being condescending and rude.. etc.. etc.. And then will go and smite them for hours/days upon days every hour on the hour, etc.. Pretty sure 250 some of those from Derelict came from the same dipshit...
I currently have some asshat smiting me every time they log in, etc.. So what you should be looking at more is the +karma, the -karma are crazy skewed by little kids that think its funny or something.. And get all pissy faced when someone calls them on something stupid they are doing. Or finally gets fed up and states that if you don't post the info we need to help you then no point in continuing..
How long did it take you to figure out 5.5 posts a day for Derelict.. Could of posted like 20 packet captures in that time from the sending box, pfsense both interfaces, its wan showing the ping not going out that way and the dest box, etc.. Just saying.. Can you please post the packet capture - so we can put this to bed!
-
So you state your AP is pointing to pfsense as its gateway. Did you verify its mask? The simple thing that would cause your exact problem is if you have the mask wrong.. Anything larger than /22 would put your 192.168.2 and 192.168.1 on the same network. So the AP seeing a ping request from 192.168.1.x would think hey thats my network and just answer it vs sending to its gateway. It would not be able to arp for it.. So if your sniff shows you send it ping from pfsense, and all you see back is arps this would scream the mask is wrong on the AP.
This would explain why you can ping other stuff on the 192.168.2 network but anything from 192.168.1 can not talk to the AP.
