Ring and Eufy client behind pfSense
-
@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
-
@brtech said in Ring and Eufy client behind pfSense:
obviously a critical piece of info but didn't seem relevant at the time!
Yeah - that is always the issue, critical piece of the puzzle missing to complete the puzzle.
edit: note to self when asking for info, ask if captive portal is in use.. not just what packages like ips or pfblocker, etc. etc. .
-
Nice, the patch corrected it?
-
@stephenw10 Yes, all working perfectly now.