OPT1 needs LAN DNS access
-
I can reach the camera just fine from anyone on the LAN.
That is not what your state table shows..That state is showing 192.168.254.10 (on OPT2) trying to reach the camera on 192.168.1.241 (on LAN).
I can reach it from anything on the LAN side.
Where is the camera lan, opt1, vlan2? What is the ip range?
The LAN is 192.168.1.1/24
Changing to hybrid and creating a specific outbound rule for the >interface your camera is on - doesn't do anything other than just that >traffic
I've seen posts mentioning using this method before. I tried to avoid it because I wanted to keep things as simple as possible. Guess I have to look into that next then.
-
@lewis said in OPT1 needs LAN DNS access:
That state is showing 192.168.254.10 (on OPT2) trying to reach the camera on 192.168.1.241 (on LAN).
Well how and the hell is coming into your lan interface???
edit: DOH! DUH!! that is the 2 states the inbound to opt2 and then outbound on lan - doh!! ;)
The only reason you would have to do such a outbound nat, is if what your talking to doesn't point to pfsense as its gateway.. OR it has some firewall that doesn't allow things on other networks to talk to it.
I have seen many a cam not have ability to have things talk to it from other networks. But seems like your doing something odd with some openwrt device?
If you can not even ping it.. Points to the thing not having a gateway if you ask me.. How exactly do you have this thing configured.. That route info you shows br-wan as the interface? But the .241 is its lan IP? Is the thing doing nat?
-
There it is :).
I logged into a Linux system on the same network and I can ping it from there.
The second system is the camera itself. I logged into it and checked the gateway. It definitely has a gateway.
-
And again what is this br-wan.. lets see the ifconfig from this .241 box..
Why is this linux box your on have a mask of /16, but this other .241 box has a mask of /16 and 24??
If its mask is /16 and your on 192.168.x to it your on the same network, and would never send any answer back to pfsense..
Its config is messed up.. It should not have a /16
No wonder you can not talk to anything on that network from your 192.168.254 network.. Because to them 192.168.anything is local to them and would never send anything back to pfsense.
-
Yup, fix that subnet mask. Looks like the same issue you had initially at the client side, I'd guess for the same reason.
With either the camera server or the client thinking it's in the same subnet it will not route traffic via it's gateway and hence will be unable to connect.
Steve
-
Why is this linux box your on have a mask of /16, but this other .241 >box has a mask of /16 and 24??
Just me needing to reach something on another subnet the other day. but the point is that all devices on the LAN can reach the camera device.
Its config is messed up.. It should not have a /16
I'll change it back when I'm done. I had to ssh into a device that was out of the /24 range.
No wonder you can not talk to anything on that network from your >192.168.254 network.. Because to them 192.168.anything is local to >them and would never send anything back to pfsense.
I think we're getting out of sync here. The 192.168.1.1 is a /24. The 192.168.254.1 is also a /24. I only have that Linux box on /16 for testing. The windows machine I've been using is on /24 as are all of the devices on the 192.168.254.x.
-
Right but the camera server also thinks it's in 192.168.0.0/16.
That means that when you try to connect to it from the OPT2 subnet the server tries to respond directly, it just ARPs for your client. Obviously your client does not respond because it isn't actually in the same subnet so the server cannot reply.
It needs to be in a /24 so that it sees the OPT2 subnet as outside it;s own and replies via it's gateway.
Steve
-
@lewis said in OPT1 needs LAN DNS access:
The 192.168.1.1 is a /24
Not on the device your trying to talk to - it clearly shows a /16 as a route..
-
Wow, this was left over from when the network was a /16.
I didn't notice that when I shared the screen.
When you pointed it out, I was like 'but I'm not seeing that' until your last comments.Multiple times this has come back to bite me now. Thanks so much for sticking to this considering how tiny the issue was. Sure enough, changing the mask gets it working.
Grrr against me for missing that again!
-
@lewis said in OPT1 needs LAN DNS access:
this was left over from when the network was a /16.
Which should of never ever been a thing in the first place ;)
A /16 has no place on an interface anywhere.. It is good for a summary route, its good for a firewall rule, etc. But on an interface - no not really.. In what possible network would you ever possible have 65k devices on the same network ;)
If your putting a /8 or a /16 on some interface - your doing it wrong ;) I could see a /22 or even maybe a /21 maybe.. But /16.. no that is just insane.. Even if your like who cares if its too big, it will bite you later when you want to use some other 192.168 network.. Why would anyone use up all of that rfc1918 space on one network?
Drives me nuts when I see such masks on users setup, or even worse the /8, just like really?? WTF!!! ;)
-
Drives me nuts when I see such masks on users setup, or
even worse the /8, just like really?? WTF!!! ;)Yes, those are very good points.
The reason I have 16's here and there is because I have to bring back to life a lot of used hardware. Quite often, I have no way to know what IP the device is using so I set the network to /16 and scan until I find something.
Problem is that some of these things get left behind as I get busy moving on to the next problems going down non stop rabbit holes.
-
@lewis you understand you could do a arpscan without having actually set the /16 on your device ;)
-
@johnpoz No, I didn't know that an arp scan could do the entire /16 range if the machine it's running on is on a /24. Is that what you're saying? I'll have to look up some info.
-
@lewis yes arpscan can arp for any IPs regardless of what IP or mask is actually set on the interface..
-
@johnpoz Thanks very much. I'll try that right now.
Ack!
arp-scan 192.168.0.0/16
It's very fast but it fails for some reason. I'll look into it.
ERROR: failed to send packet: Resource temporarily unavailable
-
@lewis you more than likely have to be root ;) or suid the command.
Here fun stuff you can do with it, here just scanned the 10.0.0/24 space, but some device might not answer that because see how it shows 192.168.2.12 as the IP asking.
Well you can set the source IP to be the same as the IP you asking for, this can get stuff to answer that will only answer if the source IP is on their network, or you can set it to what you want, etc..
-
Very cool, thanks for sharing. I'll definitely start using this.
Guess I should try to find more time to play with Kali too as it's got all kinds of such things :). -
@lewis so no more setting /16 on interfaces ;)
-
@johnpoz LOl, correct :).
Thanks very much for all of your input. Even if I am not able to commit it all to memory, I have these threads to come back to when I'm stuck.
