NAT is not a mechanism for securing a network.. but.. HELP!

Sorry but still tunneling is not clear to me, only proxying is clear.

With a proxy, each packet is modified to change the IP addresses and ports but uses the same protocol (e.g., TCP, UDP, etc).

With a tunnel, each packet is used as the data load to form a packet for a different protocol. A trivial (and unlikely) example would be if we have the TCP protocol but not the UDP protocol and want to be able to run programs that use UDP. We build a "tunnel", where UDP packets are actually sent using the TCP protocol.

A tunnel fakes one protocol, and instead uses a mutually exclusive alternate protocol.

To understand why that is done, perhaps understanding the layered approach to networking is required. All communications links have various layers of protocols...

You've probably heard of the "OSI Layered Model" that labels 7 layers? And you've probably seen comparisons with TCP/IP, which doesn't really have all 7 of those layers because it combines some of them? Here is a comparison chart:

OSI Model Typical Internet Implementation

Application 7 --+ | Presentation 6 |-- Application | Session 5 --+

Transport 4 ----- TCP / ICMP / RAW / UDP / OTHER

Network 3 ----- IPv4 / IPv6

Datalink 2 ----- Device Driver

Physical 1 ----- Hardware

Notice that each layer can have multiple /different/ protocols. For example we have several "Transport" layer protocols to choose from, and any given application might use TCP or ICMP or UDP or one of the other (not listed) protocols. Some applications may even allow the user to choose which protocol is used.

At each layer the connection to the next layer is to one specific protocol selected from the several that are available.

Here is a diagram of a typical example, which in this case is the connection between a web client and a web server that are on an Ethernet LAN.

Client Server Host Host

Application Protocol Web Client Web Server Applications Layer | | | TCP Protocol | TCP TCP Transport Layer | | | IPv4 Protocol | IP IP Network Layer | | | Ethernet Protocol | Ethernet Ethernet Datalink Layer Driver Driver | | | 10baseT Protocol | Ethernet Ethernet Physical Layer NIC & Cable NIC & Cable | (CAT5 cable) | +----------------------------------+

Note that each "stack" of protocols is the same on both the client and the server hosts. The dashed horizontal lines represent "virtual connections" between the layers on each host, and ideally the layers above any given dashed line do not know, or care, about what is below that line. (That ideal situation doesn't always exist though!)

Okay, so that is the way it is *supposed* to happen. Each layer should be *totally* isolated from anything more than one layer away from it. Hence an application would select TCP (as opposed to UDP or ICMP etc) and then would not know or care what the datalink layer actually was. The fact that it is Ethernet rather than Token Ring or PPP is not supposed to make any difference.

However, the fact is it *does* make a difference, and sometimes we can't control that. Lets say you have an existing implementation of protocol 'A' (in any of those layers), and purchase a program that is fine tuned to run *only* when used with protocol 'B', which is not available. That would be one instance where a "tunnel" might be used. Rather than add a /real/ protocol 'B', the program is provided with something that looks like it comes from 'B', but it actually connects to your existing 'A' protocol.

A really simple example would be if for some reason UDP was not available (perhaps a mid-link firewall does not allow UDP packets). No problem, just write a UDP to TCP tunnel for each end of the connection. The program expects UDP, so it thinks the virtual connection will look like this:

Client Server Host Host

Application Protocol Client Server Applications Layer | | | | UDP UDP Transport Layer | | | | IP IP Network Layer | | ~ ~

But since there is no usable UDP protocol available, but the TCP protocol does work, a "tunnel" is put into place, and it ends up looking like this:

Client Server Host Host

Application Protocol Client Server Applications Layer | | | UDP Virtual connect | UDP--+ +--UDP | | \\ | | \\ UDP-TCP TUNNEL UDP-TCP TUNNEL > Transport Layer | | / | TCP Virtual connect | / TCP--+ +--TCP | | | IP Virtual connect | IP IP Network Layer | | ~ ~

What the tunnel actually does is _connect_ _between_ _two_ _protocols_ _in_ _the_ _same_ _layer_, and encapsulate the data from one into appropriate data for the other. That usually means taking a packet from the first protocol and using the entire packet as the data load for a packet suitable for the second protocol.

A tunnel looks like one protocol to the layer above it, and like a different protocol to the layer below it. In the above example the Application Layer is dealing with UDP, while the Network Layer below is talking to a TCP protocol.

The example of tunneling UDP through a TCP connection is perhaps a bit far fetched, and probably is never done. But examples where a tunnel actually is used are available for each layer.

For example, if we want to encrypt all of our data, regardless of what program is used, we might replace the entire transport layer with a tunnel. Each protocol would be available, but instead of connecting directly to the Network Layer below, every packet would then be encrypted, put into a TCP packet, and sent on its way.

Another example is PPPoE, where we have an Ethernet, but want the Network Layer to deal with certain Ethernet frames as if they come from a PPP connection.

The common thing, by the way, is filtering not routing. A PIX, which is a firewall appliance without any doubt, is not routing. And any other firewall appliance does not need to route.

Yours, VB.

Hm... ;-)

For example, an IP packet is data only, as everything, a computer works with, is just data.

So, if I can send data and receive data, I can send and receive IP packages. For example, I can send IP packages with simple email.

This works, because IP packages are binary data, which can be stored in a file. And the file can be an attachement to an email, for example.

So what we need are two tunnel endpoints, two tunneling gateways. Each one must be a software program, which "listens" on a usual network interface for IP packages, stores every packet in a file, and sends this as an attachement to the other side. If it receives an email with such an attachement then reads the file, and sends such an IP packet through the usual network interface.

By this example, you have a simple tunnel for IP packets ("Internet connection") through common email.

You can tunnel everything through everything. Alexander's wwwsh for example tunnels a simple terminal protocol (remote shell) through Windows messages and HTTP.

Yours, VB.

You can use HTTP as the tunneling protocol, and if you tunnel through HTTP, then a proxy is not a drawback. But you don't need proxies to implement tunneling.

Yours, VB.

Floyd L. Davidson wrote: [tunnel explnataion]

Thanks a lot Floyd! Indeed is a very intersting subject!

Hm... then I guess I failed to explain. Perhaps you can make my job here easier, if you'd try to hack some networking code yourself.

For this, you could try Richard Stevens' "UNIX Network programming", at least volume 1. Then you'll understand what's goin' on.

Sorry. That's all I can do.

Yours, VB.

Routing does offer a small measure of protection. Better than just plugging the cable modem into the back of the PC.

I cannot see that - could you explain, please?

Yours, VB.

I've never disputed that, and encourage users to have at least a NAT Router, but I never mistake a NAT router as a firewall.

I was referring to a NAT router blocking unsolicited inbound traffic. Minimal, and not perfect. But it is better than nothing at all.

The dictionary does... ;)

The American Heritage® Dictionary of the English Language: Fourth Edition.

1. Computer Science Any of a number of security schemes that prevent unauthorized users from gaining access to a computer network or that monitor transfers of information to and from the network.

As I said, since there is no legal definition of the term firewall (as there is for, say, a hamburger in the U.S.) the word will obviously be used to refer to the process of limiting access in one way or another.

Little Cyberdrool is lurking you. That little *clown* will keep you going with his car and dry wall crap. :)

Duane :)

A NAT router does none of those things - it does not block any Dangerous traffic, does not block inappropriate traffic, it just doesn't "route" traffic inbound unless there has been a connection from the inside first. So, according to the RFC 2979 definition, a NAT router is not a firewall - that's for showing us the truth.

And if you don't believe my other post following this, then a Switch with VLAN's is also a firewall - which we all know is not true.

Ah, OK. You mean filtering.

Thanx, yours, VB.

There are standards:

A "firewall" is an agent which screens network traffic in some way, blocking traffic it believes to be inappropriate, dangerous, or both. (RFC 2979, Behavior of and Requirements for Internet Firewalls)

A NAT router with filtering capabilities is a firewall following this definition.

Yours, VB.

I beleive that this blocking inbound connections capability of the NAT router is what makes people believe that NAT is a firewall, while i would agree with you that it is not. But it somehow is providing security but only as a "side effect" of its NATing procedure not to "route" the inbound traffic as you correctly said.

But then again why would someone embed this dont route capability to NAT. Wouldnt be enough to just let NAT tranlate the source and destinatiop ip addresses as the eacronym suggests?

Why did they add into NAT this "dont route inbound traffic capability" that makes people beleive that NAT is a firewall?

People mistakenly beleive (and it shard to distingusih) that

"dont route inbound traffic" == block inbound traffic.

I think your post made this concept clearer.

Aaah, yes.... That makes veen cleared the fast that NATing isnt blocking anything but instead isnt routing.

If the data coming to the router is a response to a previosuly initiated connection from an internal host (and NAT sees that by checking with its own NAT table, i guess by looking the incoming source ip:port of the packet if it matches the previously outgoing dest ip:port of the packet that send) then translste the dest ip and redirect the packet. Thats one case of routing.

If an incoming packets comes as requesting a connection(meaning no NAT entry record) then look the port forwarding rules. if you find that we redirect such a port that the inbound packet wants then also route. Thats 2nd case of routing

And third if NO NAT Entrry Record and NO Port forwarding rule also then NAT dont know wht to do with the packet and thus it doenst route it but simply ignore it. Thats what most people including me mistakenly used to beleive thats this is blocking the inbound traffic when it just is NOT ROUTING the incoming packet. Correct?

Dynamic NAT = 1 public ip address to many internal hosts. Here we need port seperations.

I would like to ask about the source port of the originatin packet. lets say 10.0.0.1 want to communicate with soem wremote web server and we have Dynamic NAT cause we have a lot of hosts in our lan.

how does tha NAT table looks like(in my case)?

Thanks!