OPT1 needs LAN DNS access

lewis

To be safe, here they are. DNS servers are on the LAN, hence the rules.

lewis

I think all I really need to do now is to add a rule on each network to not allow clients to access the gateway/firewall right?

johnpoz

@lewis said in OPT1 needs LAN DNS access:

each network to not allow clients to access the gateway/firewall right?

Your rfc1918 rule would do that, other than the wan IP which I would assume is public. This is good use of the "this firewall" alias. Which would include any IPs on the firewall, even if they change.

lewis

Correct, none of the clients on each network can see the pfsense firewall.
Or I should say, using nmap from a client, I can see the gateway of the network which is the pfsense device but no ports show up which is good.

However, I have a bit of a different situation on another network. I set up OPT2 recently for my new AP and the wireless clients can see ports 22, 53, 80 and 443 on the AP.

It's not yet clear to me if I should block that from the AP (running openwrt now) or using pfsense.
What is interesting to me is like our DHCP talk, it would be nice to have just one place (pfsense) to monitor/maintain all access rules.

I will have to block access to clients using the AP rules but am curious to know if there might be a way to do it from pfsense instead. Meaning, some rules on pfsense that would block other clients on the same network from being able to see those ports while also allowing the LAN to have access to the AP.

johnpoz

@lewis said in OPT1 needs LAN DNS access:

I set up OPT2 recently for my new AP and the wireless clients can see ports 22, 53, 80 and 443 on the AP.

Pfsense has no control over devices talking to other devices on the same network.. If you fire up some device, even an AP on a network and it has services listening on ports pfsense would have no way to stop a client on the same network from seeing those. That would have to be done on the device.

With something like an AP, the management IP should be on a network that is not available to wireless clients for example..

lewis

@johnpoz

Got it. I thought there might be a way to block clients on the network itself.
I'll block access on the AP then and allow the single LAN IP that should have access.

johnpoz

@lewis said in OPT1 needs LAN DNS access:

I thought there might be a way to block clients on the network itself.

Nope - not how it works.. When a device want to talk to an IP that is on the same network as its IP via its mask, it just arps and then sends the traffic directly to that mac.

Traffic is only ever sent to the router (pfsense) when the IP the client wants to talk to is not on the clients own network. When a devices want to talk to say IP 1.2.3.4, which is not part of its local network. It will arp for the gateway mac if not already in its cache. And then send the traffic to the mac of the gateway with the destination IP of 1.2.3.4, pfsense will see this traffic and based on its routing send the traffic on either out another interface that is attached to the network that IP is on, or to its default gateway. That is if the firewall rules allow the traffic.

edit: The only possible way pfsense could be involved in traffic on the same network talking to each other is there was a bridge setup in pfsense, then pfsense could filter traffic between devices on opposite sides of the bridge. But if devices were all on the same side of the bridge then pfsense would not see the traffic to be able to filter.

jsmiddleton4

Very informative thread.....

lewis

Figured I should add to this rather than start a new thread but happy to start a new one if needed.

The last thing we did was to fix the OPT2 gateway so I could reach the AP from the LAN. All good since then.

However, something weird happened today and I realized something is still not right.

I am trying to reach a LAN IP from the OPT2 network so I created a rules that should allow this. But it didn't work. OPT2 devices cannot reach the IP on the LAN.

While testing this, I noticed that none of the clients on the AP could even nmap the DNS port for the DNS servers they are allowed to use.

If I disable the DNS rules, clients definitely lose DNS services as expected. If I re-enable the rules, clients get DNS again.

So, why aren't clients able to access the garage device since there is a rule that should allow them to?

johnpoz

@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.

lewis

@johnpoz

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

johnpoz

@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.

lewis

@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.

johnpoz

@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.

lewis

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.

johnpoz

@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.

lewis

@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.

stephenw10

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

lewis

@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.

johnpoz

@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..