Ring and Eufy client behind pfSense
-
@brtech you mean like a test of the rules?
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
If something is not allowed, then it would be logged by the default deny. if your putting in specific block rules, then no by default they wouldn't be logged unless you log that rule.
You shouldn't have any "return" rules - state allows return traffic. Could you send me picture of your rules.. Are you using pfblocker rules to allow it to auto block stuff?
Out of the box any any is default, so pfsense shouldn't be blocking your access to anything on the internet. If I could see your rules - maybe something obvious would jump out at me - are you policy routing traffic out a vpn? etc. Are you blocking large geopip ranges, or IPs in a list from pfblocker?
-
@johnpoz I've sent the rules, no policy routing, we are using pfblockerNG but I've just checked the alias lists on the WAN for 52.210 and nothing there as far as I can see.
-
@brtech first thing that jumps out at me is why are you block bogon on an internal interface?
That sort of rule should really never be on an internal interface.
Why are you natting internal traffic? You have rules that say nat to prod, etc.
Can you send your outbound nat rules and port forwards?
-
@johnpoz Just turned off the bogon on the WLAN, no idea why that was on!
-
@brtech so sniff you sent me has a 10.215 address - but in your outbound nat your not natting this address range.. How is to talk to public IPs?
You have your outbound nat in manual mode - and blocking bunch of stuff from natting..
-
@johnpoz The comments on the WLAN rules are wrong, it's just a pass rule, not a NAT, it's just to allow access to certain internal services for WLAN users,
-
@brtech Where is this 10.215.173.1 that is in the sniff with all the stun? That isn't going to be able to talk to the internet through pfsense - because pfsense has no outbound nat rule for this 10 network..
-
@johnpoz That's the packet capture software on android, it uses an internal vpn to collect the traffic, it just looks odd (the android device isn't routed so that's the way to achieve packet capture)
-
@brtech why are you sniffing on the device? Sniff on pfsense..
We are interested in packets that go through pfsense, there is no reason to sniff on the device.
the android device isn't routed so that's the way to achieve packet capture
How would it talk to the internet??? To stream ring video?
-
@johnpoz It's a man in the middle capture, just so we could see the traffic, if you hold on I'll get the same from pfSense, but it'll show the same thing, the STUN packets leave the WLAN but the responses are never seen there.
-
@johnpoz for "routed" I actually meant "rooted"(!) - sorry!
-
@brtech said in Ring and Eufy client behind pfSense:
leave the WLAN but the responses are never seen there.
You mean it leaves the WAN? Your saying they are seen on the internal interface - but never go out the pfsense wan interface?
-
@johnpoz No, the STUN requests are seen on the internal WLAN and the WAN, the STUN response is seen on the WAN but never makes it to the WLAN so it's being dropped by a rule somewhere.
E.g. on the WAN capture packets 1496 is the request and packet 1503 is the successful binding response.
-
It should be passed by the existing state on WLAN. The fact it isn't implies something else is happening. Like maybe a state conflict.
-
@stephenw10 said in Ring and Eufy client behind pfSense:
It should be passed by the existing state on WLAN
Exactly - what rules on your wan mean nothing once there is a state.. The state would allow the return traffic..
-
@johnpoz Ok, extremely strange, I can see in the state table that the udp for the stun session is there, but it's definitely not appearing in an unfiltered trace of the WLAN interface on pfSense?
-
@brtech where is the state on the wan, where that was natted, you should also see that.. do all interfaces and filter on the clients IP.
example
edit: where is sniff on wan showing the response from the stun sent.. Many they are not being responded too?
-
@brtech So I got your email - what specific patch did you apply, and did you have captive portal enabled?
-
@johnpoz #12834 was the patch, yes captive portal was enabled for the guest WLAN, obviously a critical piece of info but didn't seem relevant at the time!
-
@brtech Ok its seems captive portal was enabled on this interface..
Seems this patch was applied and now working
