New cameras from Netgear-Arlo
-
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
-
@Dashrender said in New cameras from Netgear-Arlo:
A client behind a NAT firewall sends out some traffic to the NAT, it then assigned a port to that traffic and send it to the web server, the webserver gets the traffic along with the port it needs to respond on, and then responds on that port?
The firewall sees the incoming traffic on that port, from the IP it sent traffic out on, on behalf of our client PC, so it knows that it's valid incoming traffic and sends it inside the network to the client.
is this correct?
That's correct but missing some of the detection and security pieces. But lacking those pieces, the parts that are there appear to be correct.
-
So from your description of how NAT works, can you now see why your proxy idea would not work?
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
-
@Dashrender said in New cameras from Netgear-Arlo:
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
No, that would require it to breach the security of the firewall. The communications between the two firewalls is invisible to either end point. A proxy in the middle could see that info, and even pass that info as data to the applications. But I'm unclear of how either application could usefully use that information.
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
how does web surfing work through a NAT firewall?
The connect is initiated from the inside of the network, the NAT firewall recognizes the pattern and listens for a response packet to the one that was sent out. It starts from the inside and has to come back as a response to the one that was sent. Port to respond to is determined by the NAT firewall.
ug... yeah OK fine, I'm starting to crack and think I had a missunderstanding.. I know the NAT firewall has to assign the port for the outgoing traffic.... what I don't know is if there is any way for the internal client to find out what port was used by the NAT firewall when sending that packet out.
No, that would require it to breach the security of the firewall. The communications between the two firewalls is invisible to either end point. A proxy in the middle could see that info, and even pass that info as data to the applications. But I'm unclear of how either application could usefully use that information.
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
-
@Dashrender said in New cameras from Netgear-Arlo:
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
Not sure what you mean. Nothing on the inside network would create any predictable port on the outside. Otherwise two Skype clients on the inside would conflict with each other trying to use the same port on the outside. The open port on the outside is a random number from a pool of unused ports. It's random, ephemeral and requires a response (when using a stateful firewall) that matches an ongoing conversation that is already in progress.
-
@scottalanmiller said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
Well, assuming that the each client behind the NAT used the same port regardless of what IP they went to externally, you could do what I described earlier.
But if the port changes for each connection, then yeah, that wouldn't work.
Not sure what you mean. Nothing on the inside network would create any predictable port on the outside. Otherwise two Skype clients on the inside would conflict with each other trying to use the same port on the outside. The open port on the outside is a random number from a pool of unused ports. It's random, ephemeral and requires a response (when using a stateful firewall) that matches an ongoing conversation that is already in progress.
So now I'm asking for educational purposes.
client pc A makes a connection to www.microsoft.com, then makes a connection to www.google.com and then one to www.scotthatesme.com.
Question, does the NAT firewall assign a different randomly picked port to each connection? or is it the same port since it's the same client behind the firewall?
-
@Dashrender said in New cameras from Netgear-Arlo:
Question, does the NAT firewall assign a different randomly picked port to each connection? or is it the same port since it's the same client behind the firewall?
The question isn't quite right. It makes many, many connections to each one because HTTP is stateless. Each connection gets its own port, randomly assigned on the outside. So it's even less predictable than you were imagining possible.
-
So I was reading JB's link UDP hole punching.
UDP hole punching is a method for establishing bidirectional UDP connections between Internet hosts in private networks using network address translators. The technique is not applicable in all scenarios or with all types of NATs, as NAT operating characteristics are not standardized.
Hosts with network connectivity inside a private network connected via a NAT to the Internet typically use the Session Traversal Utilities for NAT (STUN) method or Interactive Connectivity Establishment (ICE) to determine the public address of the NAT that its communications peers require. In this process another host on the public network is used to establish port mapping and other UDP port state that is assumed to be valid for direct communication between the application hosts. Since UDP state usually expires after short periods of time in the range of tens of seconds to a few minutes,[2] and the UDP port is closed in the process, UDP hole punching employs the transmission of periodic keep-alive packets, each renewing the life-time counters in the UDP state machine of the NAT.
UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the well known STUN server is restricted to receiving data from the well-known server, and therefore the NAT mapping the well-known server sees is not useful information to the endpoint.
In a somewhat more elaborate approach both hosts will start sending to each other, using multiple attempts. On a Restricted Cone NAT, the first packet from the other host will be blocked. After that the NAT device has a record of having sent a packet to the other machine, and will let any packets coming from this IP address and port number through. This technique is widely used in peer-to-peer software and Voice over Internet Protocol telephony. It can also be used to assist the establishment of virtual private networks operating over UDP. The same technique is sometimes extended to Transmission Control Protocol (TCP) connections, with less success due to the fact that TCP connection streams are controlled by the host OS, not the application, and sequence numbers are selected randomly; thus any NAT device that performs sequence number checking will not consider the packets to be associated with an existing connection and drop them
Please explain the difference between my above explanation and this. Where am I missing the boat?
-
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@JaredBusch said in New cameras from Netgear-Arlo:
The next IoT device to add to the botnet
Yup. Get a DVR and use a VPN or SSL not something that uses their online service...
I don't have a problem with using someone's online service as long as my device doesn't need to be published through my own router. Sure if the vendor gets hacked, the hackers could use that connection to try to get back into my network, but I'm a soft target compared to the vendor's network.
Not really.. Not when there's millions of those devices to uses in a DDoS. You all become part of the plan.
I get what you're saying, but normals want remote access their DVRs and setting up access through a cloud provider that then has a secure connection to the DVR is way better than normals trying to setup and maintain VPNs, etc.
Or people could be content to miss whatever it is.
I'm sure people will live and civilisation continue if DVR's and other toys aren't accessible outside home LANs 
-
@nadnerB said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@Dashrender said in New cameras from Netgear-Arlo:
@Jason said in New cameras from Netgear-Arlo:
@JaredBusch said in New cameras from Netgear-Arlo:
The next IoT device to add to the botnet
Yup. Get a DVR and use a VPN or SSL not something that uses their online service...
I don't have a problem with using someone's online service as long as my device doesn't need to be published through my own router. Sure if the vendor gets hacked, the hackers could use that connection to try to get back into my network, but I'm a soft target compared to the vendor's network.
Not really.. Not when there's millions of those devices to uses in a DDoS. You all become part of the plan.
I get what you're saying, but normals want remote access their DVRs and setting up access through a cloud provider that then has a secure connection to the DVR is way better than normals trying to setup and maintain VPNs, etc.
Or people could be content to miss whatever it is.
I'm sure people will live and civilisation continue if DVR's and other toys aren't accessible outside home LANs While it's true that people would learn to cope, but the cat's already out of the bag. Unless ISPs start blocking outbound traffic, you can't stop someone from doing this. Plus there are already probably millions of those things out there, it's not like people are just going to give them up tomorrow if they saw the news and realized they were partly to blame for these types of problems.
I do wish that ISPs were the tiniest bit more altruistic and would take a list from the forensic analysis of large attacks like this and at minimum send emails to their customers who's IP was on the list of those participating in the attacks.
AND while it's much less effective now considering the number of IoT devices available to attack with real IPs, I wish ISPs would drop outgoing packets that have forged return addresses.
