Nmap questions concering my router

Hello i have a Speedtouch 530 modem/router. i use WinXP(Gentoo too :-)

when i namp from console i get this:

D:\\nmap>nmap -sT -sV -O -P0 dslcustomer-225-52.vivodi.gr

PORT STATE SERVICE VERSION

21/tcp open ftp Alcatel Speedtouch aDSL router ftpd 23/tcp open telnet SpeedTouch DSL router admin interface 137/tcp closed netbios-ns 138/tcp closed netbios-dgm 139/tcp closed netbios-ssn 445/tcp closed microsoft-ds 1723/tcp open pptp? Too many fingerprints match this host to give specific OS details

Well i port scan my friend computer which he uses the same isp and same exact router i dotn see the same results:

D:\\nmap>nmap -sT -sV -O -P0 dslcustomer-222-75.vivodi.gr

(The 1659 ports scanned but not shown below are in state: filtered) PORT STATE SERVICE VERSION

137/tcp closed netbios-ns 138/tcp closed netbios-dgm 139/tcp closed netbios-ssn 445/tcp closed microsoft-ds Too many fingerprints match this host to give specific OS details

Nmap finished: 1 IP address (1 host up) scanned in 281.141 seconds

a) why to me it reports i have 21, 23 and 1723 port open? i didnt open them btw. ISP did this? Is this because my ISP wants to remote managing me? For example to upload his own firmware? Why 3 ports and whats he is doing with every 3 of them?

b) Why doesnt report the smae from my friends pc when i nmap him? Is this because iam issuing the command behind my router, but if so whats the problem with that?

c) why the netbios ports are displayed if they are closed? other ports as closed as well but nmap doesnt display them. why for netbios it does?

d) I am also running an http server Apache v2.0.55 (win32) and a smpt server and have 4899 port open but it doesnt show up why?

e) Is nmap a really good port scanner or there is soemthign better?

Thank you.

Reply to
Nik
Loading thread data ...

^^^^^^^^^^^^

Now, go read the man page again, and see what those options do.

Yes - scanning from "outside" verses scanning from "inside"

They are open on your side of the "wall" so that _you_ can manage the router.

-rw-rw-r-- 1 gferg ldp 85507 Aug 20 2001 Firewall-HOWTO

-rw-rw-r-- 1 gferg ldp 42743 Nov 24 2001 Firewall-Piercing

-rw-rw-r-- 1 gferg ldp 155096 Jan 23 2004 Security-HOWTO

-rw-rw-r-- 1 gferg ldp 278012 Jul 23 2002 Security-Quickstart-HOWTO

The last document is pointed out because of the theory presented.

Read the man page again

Did you tell nmap to scan those ports?

It's excellent once you learn how to use it. However, the man page ALONE is over 22 pages long, and it's not all of the documentation that is part of the tool. Do be careful with that tool - some ISPs feel that people who use it may be violating the Terms And Conditions or Acceptable Use Policy, and may close your account if anyone complains.

Old guy

Reply to
Moe Trin

I know what those option do but that not answer my questions

I need more info on this please

You mean on the internal interface of the router? But what i was issue tos cna was the exterior interface not the interior.

Can you tell me?

I didn see soemthing relative

No but it should by default, as it did with the other ports.

Reply to
Nicky

Can anyone answer me please?

Reply to
Nikos

Whoops!!!

On Wed, 03 Aug 2005 17:15:37 +0300, you replied to me:

-sT TCP connect() scan: This is the most basic form of TCP scan- ning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine.

Notice: "every interesting port" - not "every port"

Let me ask you about the front door of your house. From outside, can I see all of the locks and security precautions you have taken? What if I am looking from inside? The same is true of "multi-homed" computers which mean computers with more than one IP address. Your router has an address on the "street" side of your door. From there, you can see very little about the router. When you move inside (to your LAN side of the router), you can see a lot more. All computers also have a "loopback" address, which is 127.0.0.1 - and the Operating System knows that any conversation on that address/interface is "yourself" talking to "yourself". Do you trust yourself more than someone out on the street? I hope so.

Yes

But you did this from the inside. If you want to see what the outside looks like, you have to go outside, and look (scan) from there. Please remember that it is not the interface that responds - it is the computer. When you "talk" to the computer, it looks at the interface you are connecting to (in this case, inside), not the interface you are "talking" to.

[list of Linux HOWTOs]

Please read the HOWTOs, and the vast amount of documentation that comes with nmap.

-p This option specifies what ports you want to spec- ify. For example "-p 23" will only try port 23 of the target host(s). "-p 20-30,139,60000-" scans ports between 20 and 30, port 139, and all ports greater than 60000. The default is to scan all ports between 1 and 1024 as well as any ports listed in the services file which comes with nmap.

Above. There are 65536 TCP ports, and 65536 UDP ports. Scanning all of those can take a long time, and so BY DEFAULT, nmap only scans what it calls "interesting" ports. You mention you have Gentoo, so you should have 'tcpdump' available. Use nmap to scan the interface on the Gentoo system where you are running tcpdump - you'll see that only a small number of ports is scanned. Look at the last sentence I show of the -p option (just above), and then look at the nmap services file.

[compton ~]$ grep -c '/tcp' /usr/local/share/nmap/nmap-services 1153 [compton ~]$ grep -c '/udp' /usr/local/share/nmap/nmap-services 998 [compton ~]$

Please understand that a tool like nmap (or tcpdump, or even 'ping') is complicated, and you should read the instructions before assuming that you understand everything about it. With something like nmap, it also helps to experiment with it on your own systems, using other tools like tcpdump) so that you can see what is going on.

Old guy

Reply to
Moe Trin

Thanks a lot Moe for the detail explanation but what i still dont understand is this:

Please remember that it is not the interface that responds - it is the computer. When you "talk" to the computer, it looks at the interface you are connecting to (in this case, inside), not the interface you are "talking" to.

Can you calrify that a little more perhaps?

Reply to
Nicky

First - there is no intelligence in the interface. Literally, all it does is monitor the "wire" looking at the headers of the packets. If it sees a packet addressed to it (first 6 bytes of the Ethernet packet matches the MAC address of the card) or to the "media broadcast" address (FF:FF:FF:FF:FF:FF), it copies the packet into the the data bus. The interface can be put in "multicast" mode, and that will receive packets addressed to hardware address 01:00:5E:* and pass them to the data bus too. The interface can be put in "promiscuous" mode in many cases, and that simply copies all packets to the data bus. The interface also takes data from the data bus and copies this out to the "wire". The only "thinking" that the interface may do is error detection (packet length must be a integer number of bytes - minimum/maximum length, and checksum) mechanical errors (collisions and carrier failures), and the decision of when to transmit (Do I have data to send? Is anyone else "talking" on the wire right now?).

If you have a second (or third, or...) interface, all you have done is added hardware between the "wires" and the data bus in the computer. Even if your computer has multiple CPUs inside, the norm is that only one will be handling the networking tasks. This means taking that data off the data bus, and actually doing something with it. The name of this process is the "networking stack", because there are multiple processes resting on top of each other. You may be using a web browser which is the application level - the top of the stack. You may enter a URL, and press the enter key. The application hands this data down to the transport level, where it is put into a transport packet, such as TCP (or possibly UDP). The transport protocol hands the resulting packet to the network level, where it is put into (most likely) an IP packet - probably IPv4, and tries to figure out which link (the "bottom" of the stack) to send this. Which link will it use? Is the address reachable via the Ethernet (if more than one interface, which one)? Or is the packet for "me" (use the loopback). Only if the packet is going to a remote host will the packet be sent to the (appropriate) Ethernet interface. This same concept works if you are using Token Ring instead of Ethernet, or virtually all other networking mechanisms including carrier pigeons (RFC1149 updated by RFC2549).

A little point there - the computer knows all of it's own addresses. The computer next to me on this desk (there are two) has three interface cards in it. One is used for "normal" traffic, while another is on the "admin" network, and only gets secure administrative traffic. The third is on the "tape backup" network, and the traffic on that LAN is dedicated to making and restoring backups. (We do this both for security, and speed.) Let's say that 'eth0' is the main LAN, and this is 172.16.21.218 (network mask

255.255.252.0). The 'eth1' is on the admin LAN, and this is 192.0.2.14 (mask 255.255.255.0), while 'eth2' is on the backups LAN as 192.168.152.21 (mask 255.255.255.0). Don't forget the loopback, which is 127.0.0.1 with a mask of 255.0.0.0. So, what is the address of this computer? The correct answer is 172.16.21.218 and 192.0.2.14 and 192.168.152.21 and 127.0.0.1. If you send a packet to any of those addresses (except 127.0.0.1, which is special) from another host, where does the packet get "read" (meaning that the contents of the packet are actually looked at)? Well, from the first paragraph above, it CAN NOT be the interface - all it does is receive the packet and stick it onto the data bus inside the computer. Here is the packet, in the network stack, working it's way up to the application that will do something with the packet. This _could_ be a firewall that throws away, or rejects the packet - or the network stack itself if there is no application listening at the "destination" (there is no web server on this system - send a port unreachable error back to that idiot)..

Here is a little experiment you can try on your computer that has multiple interfaces. (NOTE: I'm using *nix commands because I use *nix, and don't have any windoze boxes. As microsoft copied the FreeBSD networking stack when they invented IP networking 13 years after Berkeley, the concepts are the same, although the commands may differ.) First, use the '/sbin/ifconfig -a' command, and look at the data counts on each interface (something like this);

RX packets:2066190 errors:0 dropped:0 overruns:0 frame:0 TX packets:127062 errors:0 dropped:0 overruns:0 carrier:0 collisions:2

Now, ping each of the addresses with a command like 'ping -c 2 192.168.1.3' and then quickly (if your network is busy) look at the '/sbin/ifconfig -a' data counts again. In most cases, you'll discover that the packets were sent out of the loopback interface, rather than to the Ethernet interface that you pinged. Why? Your computer knows it's own address, and knows that when it's going to talk to itself, it should use the loopback RATHER THAN CLUTTER UP THE WIRE WITH USELESS NOISE. If you want, you can go further, and actually unplug the network connection, and repeat this. The ping will still work. I have seen a situation where the Ethernet card was damaged (someone made a "minor" electrical mistake - and literally blew parts of the card to pieces). Yet the user could still ping his own system - but not the rest of the network for some reason...

Now, lets go to another computer and ping each of the IP addresses of the first computer. Without a firewall interfering, you should get identical responses from each of the IP addresses (except obviously 127.0.0.1). Why? You are pinging the "network stack" on the first computer, and an application on the computer is answering - it's not the interface that is doing so, because all the interface does is pass packets from the "wire" to the data bus.

Now, your original problem - you used nmap to test your router. You may have used the external (Internet) address of the router, but your packets reached the router on the "inside" interface. The router looked at the packet and saw that it came from the "safe" interface, and showed you one answer. If you went to your friend's house, and nmap'ed your external address, you will get a different response, because the packets reach the router from the "unsafe" interface - and that means I don't want to show you everything... click!

Much of this is a concept problem. People think that each interface, each IP address, is a completely separate computer. This is not the case. It is a different name for the same computer. All of the applications that use networking are running on the computer, not the interface.

Old guy

Reply to
Moe Trin

Thanks a lot Moe for your detailed anser bu i want still to clear some things out:

As you know i only have 1 pc with one ethernet interface directly connected to my speedtouch modem/router.

Tell me please if my following beleifs are true

my computer's ip address is now 10.0.0.1 But what does this really mean? Can computers have ip addresses? I think not. a) What i do think is that the ip address 10.0.0.1 is a number actually assigned to my ethernet interface and not the computer itself. is this correct? But as you said whatever comes to that ip address is then deliverd to the "network stack"(i dont really kno what this is) and then finally reach the desired application and port. I hope i understand it right.

But then i am still getting confused with having so many ip addreses and interfaces. Ill give an example.

Lets assume that my pc has 3 ethernet interfaces(3 ethernet cards this is) directly connected to my router, which i dont set up a NAT yet.

Now lets suppose thats someone sends data to my my routers, meaning my router is receiving an incoming http connection request from a remote host.

b) Where will the router send this request to? eth0, eth1 or eth2 and why? Does it send them to all interfaces(cards) simultaneously because he is directly connected to them? If this is the case what happens then? All the cards puts the same info on the motherboards data bus? So when my web server is receiving them it gets 3 imes the same http connection request?

c) Another question is why does the router has to have 2 interfaces and not just 1 the external that we pay for? I beleive that its the routers job to interconnect 2 networks, so when some data from my localhost wants to reach a remote host, my eth0 (10.0.0.1) should first reach the routers internal ip address(10.0.0.138) and then the router's internal will forward the data to the external one to get to the internet and finally reach the remote host. assuming that the destination ip address of the tcp packet is an ip address out of my local lan. If the router sees, by checking the packet's header, that the dest ip is a pc insdie the local lan for example 10.0.0.2 then the data packer will never reach the routers external interface but will be forwarded from the internal ip address of the router to 10.0.0.2 Did i got it right or am i mistaken?!

Sorry for my too many question but i jsut want to make sure that i have understand those concepts cause they are crucial.

Reply to
Nicky

Old guy will you be charging a consultation fee for this?

You should. ;-)

Duane :)

Reply to
Duane Arnold

In the Usenet newsgroup comp.security.firewalls, in article , Nicky wrote:

No, but it is difficult for people to separate the concept. If a computer has only one interface (rare), the discussion is not important. The problem occurs when the computer has two (or more) interfaces. The interface has the address, not the computer.

Correct. Computers have hostnames (which almost always translates to an IP address) but those with more than one interface have more than one name. Is your computer "localhost.localdomain"? Yes - that's true of all computers. This computer (compton) has a second interface on the ethernet, and to avoid confusion, that unique name is what the computer thinks of itself as others would think of it. But in it's heart, it knows it is really called 'localhost.localdomain' but only uses that name when it is talking to itself.

Your computer can have many applications - even multiple copies of the same applications running at the same time. These applications can be thought of as having a chunk of space in the computer much like a hotel room. When you want to get something from outside (the library, or the food store), you give a request to the bell-boy, or chambermaid - who takes the request to the front desk, where it gets sent by messenger to that library, or food store. The "message" might be to send this book, or that fruit to Nicky... who is in the Metropole Hotel, in room 1234. Now, the messenger that the hotel had sent has disappeared, so the library or food store hands the book or fruit to another messenger with instructions to "take this to the Metropole Hotel". When it reaches there, the staff look in the package and see that the book or fruit inside has 'room 1234' on the label), so they give it to a bell boy or chambermaid to take to room 1234 and deliver it.

OK - one hotel, but with three doors to the street, one at address 121, one at address 135, and a third at address 178. Don't forget that this is a large hotels, with 65536 guest rooms.

What address does the package have? Is it addressed to the router? But no one lives or works there. Send a message to who ever sent the package that their package could not be delivered, because the address is wrong. (ICMP Type 3, Code 3 "Port Unreachable")

Is the package addressed to the Hotel? Which street address?

Which IP address is the packet addressed to?

The router does not know that the three addresses reach the same hotel. It only knows to deliver the packet to the interface address.

No, it only goes to the interface that matches the address. The router does not know (or care) what computer is hiding behind the address.

Was the package addressed to 'Nicky" or "Nikos" or "Nickos"? They might be the same person or computer, but they are different names - only the one that matches will get the package.

To separate the traffic. Mainly for security reasons, but also because a given network segment (the wire itself) can only have so many systems connected before there are to many people talking (trying to talk) on the same telephone at the same time.

Yes

Yes, BUT the packet does not get _addressed_ to the router. The address

10.0.0.138 never appears in/on the packet, because that is not the final destination. Your computer needs to send a packet to the Dai-ichi Hotel in Tokyo. It looks at the routing table, and finds that it knows how to send packets to itself, perhaps other computers on the local LAN (and that includes the router), and another address called a 'default route'. The idea of a default route is that if you don't know where to send a packet, you hand the packet to this gateway (in this case, the router), and hope that it knows what to do with it. But this is the network stack concept - the packet is addressed to "Dai-ichi.Hotel.Tokyo" with the correct IP address and all that. But your computer knows the HARDWARE address of the router (or uses the ARP protocol to find it), and the addresses of the packet ON THE WIRE are the hardware address of the destination (the router), and the MAC address of the interface that is sending it. When this packet reaches the router, these addresses are thrown away because they are now of no further use. The router looks at the destination IP address, and discovers it is "Dai-ichi.Hotel.Tokyo". But it can't reach "Tokyo", so it looks at it's own routing table, and finds the default route is to send it to the Hellinikon airport at Athens. So it creates a new wrapper around the IP packet with a destination address of the HARDWARE address of the Hellinikon Airport, and a source address of the interface that it has that is on the same road as the airport. When the packet reaches the airport, this wrapper is thrown away, and someone there looks at the destination IP address - it's going to "Tokyo", and they put it on the plane going to (perhaps) Singapore. The people there look at the destination address, and put it on the plane to Tokyo Narita, and ...

Notice - all along this route, the IP packet was addressed to the "Dai-ichi.Hotel.Tokyo". It just got put into a basket (a packet on the wire), and carried from "here" to some intermediate stop along the way. When it got "there", the basket was thrown away, and the packet put into a new basket (on another "wire" going some where else), and carried to the next stop. At no point was your packet ever addressed to this or that airport, because that was not the final destination. The slaves who were carrying this packet - they don't care where it is going to end up, as their job is only to deliver it to the other end of the wire, or street, or plane ride.

Yes

Yes. Your router MAY ALSO look at the packet and think "Why is this idiot sending a packet from 10.0.0.1 to 10.0.0.2 and giving it to _me_ to deliver?" It knows that to talk to 10.0.0.1 or 10.0.0.2, it uses the same interface on the router, and that means that the two are on the same wire and you _should_ have sent the packet directly, rather than bothering the router. The router should send the packet to 10.0.0.2, AND MAYBE send an error message (ICMP Type 5 Code 1) back to 10.0.0.1 telling it to fix it's routing table. This type of message has been abused so much (Denial Of Service attack) that most operating systems ignore the message, but it may get into the logs, telling you that you have an error in your setup.

Right idea.

You should try to download a copy of the "Linux Network Administrator's Guide" from the Linux Documentation Project.

formatting link
The one you are looking for is the 'nag2' which is the Second Edition. There is also a "network-guide" which is the older First Edition.

Old guy

Reply to
Moe Trin

Quiet - wait till the lectures are over - then he sees the bill ;-)

Old guy

Reply to
Moe Trin

:>a) What i do think is that the ip address 10.0.0.1 is a number actually :>assigned to my ethernet interface and not the computer itself. is this :>correct?

:Correct.

Not entirely correct. See below.

:Computers have hostnames (which almost always translates to an :IP address) but those with more than one interface have more than one name.

Not entirely correct.

SunOS (in the past at least) assigns the same MAC address to all interfaces. This is acceptable in the standards because the MAC need only be unique per segment. Consequently the MAC address is a property of the -system-, and hence the IP address is a property of the -system-.

It is usually easier to think of MACs and IPs as being properties of interfaces instead of systems, but keep in mind that it is the IP stack in the system software that responds to packets, not the NIC. It starts making a difference when you get into clustering and redundancy.

Reply to
Walter Roberson

Yes, in order for the package to reach the web server application that is running on my localhost it is have to have as dest ip the routers external ip address. Otherwise it cant reach my pc and of course the package cant have as dest ip my ethernat interface 10.0.0.1 because its a private non-routable ip address.

Which one of the 3?

But the dest ip address of the ip packer is addresses to the routes external interface address. How can it possible know the ip addresses behind the router to send to the one appropriate?!?

Am i missing soemthing here?!?

Same question as above! How the sender can it possible know the ip addresses behind the router to send to the one appropriate address?!? Our routers external ip adress makes the contact so this same ip address is the dest ip when the response comes.

LAN traffic form WAN traffic i guess.

Thank very nice and detaild information but i still have a question. Why when an ip packet gets wrapped then thew sender and the recaiver are marked with hardware addresses(MACs) and not like ip addresses ast he initial package has?

but can he act otherwise? ALL lan pc are directly connected to the router and hence in order for 2 of them to communicate each other they must have a route rule that tells them that for all LAN traffic must use the router's internal ip address as gateway and then forward traffic from there?

I dont see how they can communicate otherwise each other.

And one last thing how does the routing table sepearted which traffic are LAN traffic so to use as gateway the router's internal ip and which traffic is WAN traffic so to use as gateway the router's external ip address?

And also in order for data to pass to the external ip address do they have to pass from the internal first and then forward from there?

Thanks again for your help!

Reply to
Nicky

Gloup! I hope you don't charge much :-)

Reply to
Nicky

I fail to see your connection. The multiple interfaces on a Sun box normally do have the same MAC address, but at least in SunOS 4.1.3 and

4.1.4, and Solaris 2.5.x and 2.6, there is no provision for more than one interface being attached to a specific network segment. This makes sense, because the Ethernet protocol (DIX, RFC0894 or RFC1042 or the Novell variants) was never designed for more than one interface per MAC address on a segment. You could put the same IP address on multiple segments, but only if they can never be confused, and I can't visualize a situation where such confusion would not be the case. As regards hostname - those are a human convenience, as IP works on IP Addresses, not hostnames.

And yes, I still have a handful of SparcStations and Ultras - but they are being retired slowly and replaced with x86 and ia-64 hardware usually running Linux.

Old guy

Reply to
Moe Trin

Ah, but the packet is being sent to an application running on the router, not the web server on your LAN. The fact that the application on the router is not a web server, but a "port forwarder" is not important externally. How did you configure that port forwarder (part of the firewall most likely)?

The one you set in the 'port forwarder' application. This is also known as NAT - or Network Address Translation.

And you are running an application on the router that takes packet addressed to 'Room 80 at the Metropole Hotel' (the external IP address of your router, port 80) and that application forwards the packets to some address that you designated, perhaps 10.0.0.1, and perhaps port 80. The same application may be configured to take OTHER packets - perhaps addressed to the same external IP address but port 180, and forward those to 10.0.0.2 port 80.

703560 May 23 08:22 IP-Masquerade-HOWTO 17605 Jul 21 2004 Masquerading-Simple-HOWTO

The remote person/computer has no idea that there is anything behind the router. They think that the router is actually the web server. It is the job of the router to forward the packets that are destined for the web server thought to be running on that external address to the real server located behind the router. The same application takes the "replies" from your web server, and translates (masquerades) the 'source IP address' so that it appears to the remote site as if the packets are coming from the server it thinks it is connecting to.

The facility where I work has 16 LANs with "public" addresses, and several more with "private" addresses. Thus, we separate LAN from LAN as well as LAN from WAN.

This is the network stack. (I hope you are using a fixed size font to read this.) At the application layer - lets say a web server, the packet consists of HTTP commands like 'GET {some_url}', that looks like this:

GET mumble.foo.bar/baz.html

This packet gets put into a TCP packet, with port numbers, sequence and ack numbers, flags, window size (how much data you will accept), a checksum and pointer - totalling a minimum of 20 bytes. See RFC0793. So, now we have

TCP_header GET mumble.foo.bar/baz.html

This packet gets put into an IP packet, also 20 bytes, with version, header length, TOS, packet length, identification, flags, fragmentation data, TTL, protocol number, checksum, and the source and destination IP addresses. See RFC0791. That looks like

IP_header TCP_header GET mumble.foo.bar/baz.html

Now, you want to put this on the "wire" which is an Ethernet (or other link level) protocol. Ethernet has a 14 (RFC0894) or 22 (RFC1042) byte header and a 4 byte CRC (checksum) trailer. The first 12 bytes of either header is the destination and source MAC address. So, now we have

Ethernet_header IP_header TCP_header GET mumble.foo.bar/baz.html CRC

Hmmm, didn't know if I was going to get this to fit in 80 character lines ;-)

Now, are we ready to go to Tokyo again? The _IP_ packet is almost identical at EVERY point on the trip from you to the "Dai-ichi.Hotel.Tokyo" (actually, the TTL counter in the IP header is decremented at each point, but that's being picky). The thing that changes at each step is the Ethernet (link layer) header - because that is the one that tells people to send this packet to the "next" place on the route. The TCP packet and the application packet do not change at all.

Let's look at that routing table. This is Linux, though virtually all O/S have similar commands/displays.

[compton ~]$ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 95017 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 420 lo 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 1547 eth0 [compton ~]$

Do you want to send a packet to yourself? That's the 127.0.0.0 route, using the loopback. Send a packet to the "Dai-ichi.Hotel.Tokyo" (which has an address of perhaps 210.151.247.138)? Well, that is not on 10.0.0.0/24, nor on 127.0.0.0/8 - so give the packet to 10.0.0.138, and hope it knows what to do. Wait - how do I get to 10.0.0.138? Oh, the routing table says that

10.0.0.0 through 10.0.0.255 are directly attached to eth0 (notice - no gateway is needed to reach the route). OK, now, what is the MAC address of that router?

OK, look at the routing table again - how do you get to 10.0.0.2? The answer is the first line - send it direct. How about 10.0.0.222? Same answer. The only packets you will be sending to the router are those going to an address that is not 10.0.0.0 through 10.0.0.255, or 127.0.0.0 through 127.255.255.255.

Doesn't have anything to do with the routing table. ON YOUR LAN, traffic going to your computer will have a 10.0.0.0/24 address (10.0.0.1, 10.0.0.2,

10.0.0.3, and so on). If destined for the "Dai-ichi.Hotel.Tokyo", the IP packet ON YOUR LAN will say "From 10.0.0.1 To 210.151.247.138". The replies ON YOUR LAN will say "From 210.151.247.138 To 10.0.0.1". But it will only say this because there is an application on the router that is doing NAT or IP Masquerading. When you look at the packet on the OTHER side of the router, your 10.0.0.1 will be replaced by the external IP address of your router - because 10.0.0.x can not exist on the Internet. Outside, it may say "From 83.171.225.52 To 210.151.247.138" and "From 210.151.247.138 To 83.171.225.52". But this is the only place where the addresses will change (unless the owner of the Dai-ichi Hotel is doing something similar with his router - but you don't know or care if that is the case).

Not exactly sure what you mean here, although I think the answer is in the paragraph above.

Old guy

Reply to
Moe Trin

200 Golden Aardvarks per hour - and 10 Silver Llamas per line of text, but there is no shipping charges.

Oh, and the taxes are extra. ;-)

Old guy

Reply to
Moe Trin

Yes part of the firewall was also NAPT, whick i configures it to port forward incomming http, smtp, radmin, emule, azureus connection to

10.0.0.1 :-) Dont really know why it is called NA(P)T instead of just NAT :-) P stands for (P)ort though.

Can i make the router to stop NATing if i want and use software in

10.0.0.1 ro do that? But then again data will never manage to reach 10.0.0.1 if the router aint NATing :-)

Is there really a difference between the "NATing" application of my router and the "Port Forwarder" application? I beleive so.

By your saying, i understand that masquerading only takes place when my localhost initiates a conenction to a remote host or when my localhost reply to an incoming connection by a remote host. As you said the 'source IP address' 10.0.0.1 spoofs to my router's external ip address

83.171.225.52. So we only have "Source" NAT not "Destination" NAT because when the replay comes back from the remote host then no spoofing takes place rahter that just a little push of the packet from routers external to 10.0.0.1

So as i see it NAT and Port Forwarding is 2 different things, but still relative :-) I maybe wrong though....

{snip] Thanks a lot Moe, that was a very nice explanation. :-)

Yes thank you for pointing to me how a routing table looks like. I am on XP but try to install Gentoo and it is good to know. I dont know if XP has something similar to this, but i strongly beleif it is to good to be true :-)

Umm, can you please clarify this a bit more for me? Oh, the routing table says that "10.0.0.0 through 10.0.0.255 are directly attached to eth0 (notice - no gateway is needed to reach the route)."

By directly attached you mean assigned?

Iam a little confused because i thought that only 10.0.0.1 is assigned(directly atatched to eth0.

And also if we see the conenction physically it goes like this, no?

eth0(10.0.0.1) => router(10.0.0.138) => eth1(10.0.0.2)

So, the data must from the intermediate router before it gets to other lan host.

Define direct please. What do you mean by direct?

As eth0(10.0.0.1) => eth1(10.0.0.2)

Sendind to the router equals sending to routers internal ip address first and subsequentally after tohis external one?

OTHER side= my routers external side?!?

I've got the feeling that if we soemhow close the NAT ability of our router then we will still be able to send data to a remote host but we will not get a response back :-

Cause a packet coming from 10.0.0.1 can reach 210.151.247.138 cause the intermediate routers will forward it since the dest ip is a natural public ip address but when a reply will try to come back the first router it will come across after it leaves 210.151.247.138 will reject the packet since its dest ip its a private NON-Routable ip address.

Correct?!

Sendind to the router equals sending to routers internal ip address first and subsequentally after to his external one or packetas can reach at one step the routers external interface?

Reply to
Nicky

Gee, i never heard of such currency before in my life :-)

Well can you NAT the Golden Aardvarks and Silver Llamas to Euros which is soemthign that i can understand? :-)

Oh, i have some Ancient Greek Drachmas if you are interested, it aint of use to me any more sicne we pass to Euros but if you are a collector then i can pay you in those, that way it ll come cheapest for me ;-)

Reply to
Nicky

Then that is the address that will receive the packets - not 10.0.0.2 or

10.0.0.3, because you did not configure it so.

Some of this is advertising. "NAT" usually means many addresses in to many addresses out - as opposed to IP Masquerading, which has only a single address on the Internet side. For a while, we had a setup here where if you connected to the Internet address X.Y.Z.1, the router would forward packets to A.B.C.27, while X.Y.Z.2 went to A.B.C.28, X.Y.Z.3 went to A.B.C.29 and so on - I think there were 9 or 10 Internet addresses that were forwarded to 9 or 10 addresses in the DMZ. Port numbers, which are in the TCP header were unchanged. We've also set up a configuration where traffic to X.Y.Z.21 port 80 went to one internal host, and traffic to X.Y.Z.21 port 1080 went to port 80 on a different host. That's Port Translation in addition to masquerading or NAT.

Technically, yes you could - but it's a much more difficult setup, and not something you are ready for. It might take special software on the router in addition to a strange configuration on 10.0.0.1

Correct.

Yes - see above

No, the address '83.171.225.52' gets changed to '10.0.0.1' in both directions - because if 10.0.0.1 received a packet being sent to

83.171.225.52, it would ignore it - that's not _my_ address, so it must not be for me.

Microsoft discovered TCP/IP about 13 years after everyone else, so they tried to copy some of the stuff. To see the routing table in XP, I'm told

----------------------------------------------

1) open a dos box (Start/Run.../cmd), and then "route print". You want that output to look something like this (my IP address is 10.10.10.136 and my gateway is 10.10.10.7):

C:\\>route print =========================================================================== Interface List

0x1 ........................... MS TCP Loopback interface 0x2 ...00 04 75 c6 82 26 ...... 3Com EtherLink 10/100 PCI For Complete PC Management NIC (3C905C-TX) - Deterministic Network Enhancer Miniport =========================================================================== =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.10.10.7 10.10.10.136 20 10.10.10.0 255.255.255.0 10.10.10.136 10.10.10.136 20 10.10.10.136 255.255.255.255 127.0.0.1 127.0.0.1 20 10.255.255.255 255.255.255.255 10.10.10.136 10.10.10.136 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 240.0.0.0 10.10.10.136 10.10.10.136 20 255.255.255.255 255.255.255.255 10.10.10.136 10.10.10.136 1 Default Gateway: 10.10.10.7 ===========================================================================

----------------------------------------------

Now, while the output is somewhat similar, microsoft got it wrong in a number of places - but they do this to scare users away from technical information. As I look at the printout above, I can see several items that are wrong, and one that is a lie. For a comparison, the same data would look like this in Linux

Destination Gateway Genmask Flags Metric Ref Use Iface

10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 95017 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 420 lo 0.0.0.0 10.10.10.7 0.0.0.0 UG 0 0 1547 eth0

The '10.10.10.136', '224.0.0.0' and '255.255.255.255' routes are implied and not therefore needed, and the 10.255.255.255 is a mistake.

No, I mean that they are on the same wire. In the old days of coaxial cable (rather than twisted pair) network cabling, they would LITERALLY be on the same wire. With twisted pair, one cable goes to each interface and come together in a 'hub' or a 'switch' but the concept is the same. See RFC1180.

What's on the other end of the wire? The 'router' which from your description has a built in hub or switch, so that you can connect several other computers (or in your case, several interfaces) all together.

Not quite true. In the router, there are actually two boxes - one that connects all 10.0.0.0/24 together (probably a hub), and then there is another box which is the router. Hope you're using that fixed font again:

| you call all of this the router | when it really is only this | | V

10.0.0.1 10.0.0.2 10.0.0.3 | [===============] 10.0.0.138 | | | | | | | | | | | --------- | | --------------- | ------------------------- | ------------------------------------------ | this is actually | | a hub or switch |

Nope. It goes to the hub or switch. You just can't see that the router is actually two boxes - one to connect the network together, and the other being the actual router.

There are _four_ people in this room - do you need to use a telephone to talk to each other? No. What about the person in the house down the street? Yes - because that person can't hear you (I hope) through the walls of your house, the space between the houses, and the wall of their house. So, these four people you can talk to directly, but the person in the other house needs a gateway (the telephone).

Yes - except the computer knows eth0 and eth1 are on the same system, so in this case - send it via the loopback so we don't waste bandwidth on the wire. On the other hand, if you had two computers, each with one interface, you would send 10.0.0.1 --> 10.0.0.2 (computer1.eth0 --> computer2.eth0).

No, the IP address is that of the destination - the "Dai-ichi.Hotel.Tokyo". The packet on the wire would have the MAC address of the router as the destination, because that is where the packet on the wire is going. When it gets to the router, the router will look at the IP address of the destination, and send it on it's way.

Yes

Basically, yes. HOWEVER, a good ISP would also throw away such a packet when it reaches the border - because there can be no reply, so why waste bandwidth "out there" sending such a packet?

True - but see above

[compton ~]$ whois -h whois.apnic.net 210.151.247.138 [whois.apnic.net] inetnum: 210.144.0.0 - 210.159.255.255 netname: JPNIC-NET-JP descr: Japan Network Information Center [...]

inetnum: 210.151.247.136 - 210.151.247.143 netname: DAICHI-HOTEL descr: HE DAI-ICHI HOTEL, LTD country: JP

Yes - there looks to be just a few addresses there, so it is almost certain that the first router would drop the RFC1918 address. The actual requirement is not that this happens at the first router, but it has to happen at the edge of your property. You can't tell it, but my host is actually five hops away from the Internet - and as four of those five belong to the company I work for, they could (and do) use RFC1918 addresses inside the company.

No - packets sent to your router's internal ip address only go to the router - because the IP address is the DESTINATION, not the next stop along the way. See above.

Old guy

Reply to
Moe Trin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.