OPT1 needs LAN DNS access
-
@lewis said in OPT1 needs LAN DNS access:
So, why aren't clients able to access the garage device since there is a rule that should allow them to?
I don't see that rule even evaluated, see the states 0/0.. You sure its 80, and not https (443) etc. or some other port, rtsp uses 554 for example.
Also Cam device, you sure that device has a gateway setup up pointing to pfsense.. if not then you wouldn't be able to access it from another network without doing source natting.
-
I assume the second DNS is never hit since the first is always up, hence, 0/0.
The cam server is an openwrt device running mjpeg-streamer on port 80. It does have a gateway.
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 br-wan 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-wan 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br-wan 192.168.1.1 0.0.0.0 255.255.255.255 UH 0 0 0 br-wan -
@lewis I wasn't talking about the 2nd dns, I was talking about your cam rule on port 80, there are zero hits to that rule.
Why not just make that rule any any to that .241 address - can you ping it? At least until you have validated its working, then you can get more restrictive on the rules.
-
@johnpoz said in OPT1 needs LAN DNS access:
@lewis I wasn't talking about the 2nd dns, I was talking about your cam rule on port 80, there are zero hits to that rule.
Why not just make that rule any any to that .241 address - can you ping it? At least until you have validated its working, then you can get more restrictive on the rules.
Ah ok, probably because nothing is able to connect to the cam.
Yes, I also tried making it 'any'. I can't ping it from an OPT2 client but maybe that's because I don't have a rule allowing pings.
-
@lewis said in OPT1 needs LAN DNS access:
Ah ok, probably because nothing is able to connect to the cam.
Nope not how it works, if pfsense saw traffic that said hey I want to go .241 on port 80 tcp/udp that rule would trigger.. Be it the cam answered or not.. 0/0 says that pfsense never saw any traffic on opt2 that matched that rule.
Or you had a floating rule maybe that triggered before that rule.
maybe that's because I don't have a rule allowing pings.
If your cam is .241 address, make the rule any any to that IP.. Nope a tcp/udp only rule on port 80 is not going to allow for pinging.
example: I don't have a 192.168.42 network, and I block outbound access out my wan to anything rfc1918.. But I created a rule that would match, and then tried to ping that address. You can see that the rule triggered.
-
Ok, so as long as traffic gets to the rule, it will show states, no matter if it was allowed or not.
I changed the rule and made it quite open but still cannot get to the camera or ping the device at that IP. I do see something hitting it however.
-
@lewis so that is good.. You see the syn sent, but then you got no response.
So you either have nothing actually listening on that port.. 8080, not the 80 you were saying it
listens on.Or that cam is not sending the traffic back to pfsense, or it has some firewall blocking the traffic from your other network.
Looks like you can not even talk to it from your lan..
I would do a source nat.. So the interface that cam sits on.. Do a outbound nat on that interface for anything going to that .241 address and pick the interface address.
Something like this pretending my cam was on my test network.
So now if talking to your cam from opt2 it would look like the traffic is coming from your cam network interface on pfsense. Your cam needs no gateway for that to work, and firewall if running would most likely allow the traffic because to the cam its from its own network.
-
@johnpoz You're right, it's port 8080, not 80. But even with any allowed, it's not responding from OPT2. I can reach the camera just fine from anyone on the LAN.
Before I go that route, I want to be careful I don't end up breaking everything else I've got going on :). If I change this mode, it means I'll have to create rules for outgoing traffic as well as incoming?
I don't understand why any any is not working.
-
It looks like either the camera itself is refusing connections from outside it's subnet (a rule on the camera) or it has no route back to the subnet so cannot respond.
Either way get onto the camera and check it.
Steve
-
@stephenw10 said in OPT1 needs LAN DNS access:
It looks like either the camera itself is refusing connections from outside it's subnet (a rule on the camera) or it has no route back to the subnet so cannot respond.
Either way get onto the camera and check it.
Steve
The first thing I did was to check if there was a firewall on the camera that I forgot and there isn't.
-
@lewis said in 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..
Where is the camera lan, opt1, vlan2? What is the ip range?
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 - it has zero to do for anything else going out the internet or other places.. see how I created the rule with /32 - this is only the camera IP..
-
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!
