05-16-2018 09:37 AM
I have spent the last few days struggling with a couple of issues, the first one is detailed
below hopefully I have plenty of info here to facilitate your help already.
As seen in the below layout my parents have a partial Unifi network (I am slowly replacing items) Internally (LAN) I can connect to the camera at the end of this example using its internal address 192.168.1.103:1004 on port 1004
I have port forwarding configured to these cameras as shown below
And this has in turn created firewall exceptions as shown here
When I look at the external address given to the USG on WAN 1 I can see the external address but when I try to connect (on another device tethered to my mobile the traffic doesn't appear to be getting through the USG (I tried a tcp dump via ssh)
I dont know what else to try. Am I missing something really stupid here?
Thanks in anticipation for your help.
05-16-2018 09:54 AM
Just to add in case it makes a difference the controller is on my network and I have the devices connected to there (without any other issues) and I have the Inform and STUN ports forwarded on my network so the device traffic can reach the controller.
05-16-2018 10:05 AM
Run the following command on the USG:
sudo tcpdump -npi eth0 port 1004
And then test connecting to the camera from the client tethered to your phone's LTE connection again. Make sure you're connecting to the public address 92.26.x.x there, and pointing to port 1004.
If you don't see the traffic coming in on that tcpdump, then it's not *arriving* at the USG.
If you do see the traffic coming in, then run the following: (assuming 192.168.1.103 is on eth1, not a vlan)
sudo tcpdump -npi eth1 port 1004
If you see the traffic being sent out there destined to the camera, the port forward is working.
If you don't see traffic here, it's either missing a rule or a route. The route and rule are most likely there based off of all the info you provided, so this scenario is highly unlikely to happen.
05-16-2018 12:22 PM
Thanks, @UBNT-jaffe this is similar to what I tested the other day, however, I didn't get any traffic.
I tested as per your suggestion again just now and it appears that it is not "arriving" at the USG,
I contacted Draytek when I got similar results the other day and they advised
"The Vigor 120 is a bridge- it does not intercept any traffic so it
doesn't need a DMZ. Please contact UK support (link below) and they
can try to diagnose."
I will contact Draytek again but if you have any advice I would gladly accept that too :-)
05-16-2018 12:58 PM
I agree with them, what they mean by DMZ is a 1:1 NAT, that isn't needed since the public IP lives straight on your USG's WAN interface. The Draytek should pass everything through as a bridge (won't filter anything).
But if it doesn't arrive at the USG, then it's unlikely the USG is the culprit. Try opening up ICMP on WAN_LOCAL on the UniFi controller firewall rules and see if you can ping that external address from the outside.
05-16-2018 01:02 PM - edited 05-16-2018 01:11 PM
What is ICMP on WAN_Local? I'm not familiar with that terminology. Nevermind I found this :-)
05-17-2018 02:32 AM
I have had a response to my question about what is blocking traffic through the Vigor 120, and Drayteks response is
The 120 is basic modem there is not anything you can alter on the modem for this configuration. It is a plug and play device."
Is there something more I need to do on the USG to get the traffic to pass through?
05-18-2018 11:43 AM
Run the tcpdumps again I mentioned earlier in the thread. First, ping your WAN IP and instead of "port 1004", put "icmp" there and see if the traffic arrives. If it does, then put "port 1004" there again and see if it comes in, it it doesn't, something could be wrong with your testing method. How are you testing anyways?
05-18-2018 11:45 AM
Thanks for getting back to me @UBNT-jaffe
The other day I tested from my home using team viewer to my dads PC and running ssh there.
I'll try again now
05-18-2018 01:01 PM
Performed the tests again but still nothing
Check the ip on the controller
And double checked via google
Its going to be one of those crazy stupid things but I cant see what I'm missing
Any insight? and thanks again for helping
05-23-2018 01:12 PM
If you're not seeing the requests come in on eth0 (WAN) when you ping it, then something else is answering for it... either that or you're sourcing your ping from "inside" your LAN (most likely what's happening). If you're sourcing that ping from inside your LAN, you won't see it ingress or egress eth0, it will only ingress/egress the eth1, nothing physically has to enter or leave eth0.
If that's the case, try it again when sourcing the ping externally, you can even use a ping-checker website to do it.
Once we have those results, we'll move further into diagnosing the port testing.
05-23-2018 01:42 PM
I’ll try an external website, however when I was last testing I was at my house (5 miles away from the USG I was ssh’d into) you can see on the tracert screen shot
does this not show the traffic coming in from an external source?
05-23-2018 02:59 PM
@herishi forget the tracert, just use icmp ping... sometimes tracert's use UDP instead of ICMP, so unless we have that information, we're gambling on the ICMP filter for the tcpdump.