Ring and Eufy client behind pfSense
-
This is a failed ring attempt from an android client (not sure how different it is between that and Apple).
I'm going to go through the pfBlockerNG alerts to see if there's anything blocked there at this time, then I need to capture if on the android client when it works.
-
@brtech
Here's the working one from Android. -
@johnpoz Looks like we never get a good STUN response on the failing ones.
-
@johnpoz Ok, when I capture the WAN I can see the bind success messages, so something on my rules is dropping these, is there any quick way of finding out what rule this is?
-
@brtech and what are these rules? Do you have floating rules? Out of the box this works - so what rules have you put in place?
Are you doing vpn? Can you send me the sniff? The conversations list isn't a lot of help.
-
@johnpoz I'll email you the traces.
Problem is I've lots of rules for various things, pfBlockerNG, rules to allow traffic to and from internal systems, vendor access, so unraveling it is a bit of a mare!
My home firewall has the option to provide an ip, interface and port and it displays what will happen tot he packet, that's something that I think is missing from pfSense, as editing every drop rule and turning on logging is a bit of a pain, but if that's what I need to do I'll do it.
-
@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.
