Re: Nmap questions concering my router

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 08/17/05 

Date: Wed, 17 Aug 2005 14:50:48 -0500

In the Usenet newsgroup comp.security.firewalls, in article
<1124286934.951097.237590@g49g2000cwa.googlegroups.com>, Nicky wrote:

>Moe Trin wrote:

>> 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")
>
>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.

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)?

>>> b) Where will the router send this request to? eth0, eth1 or eth2
>>
>> Which IP address is the packet addressed to?
>>
>>> and why?
>>
>> The router does not know that the three addresses reach the same hotel. It
>> only knows to deliver the packet to the interface address.
>
>Which one of the 3?

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

>> 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.
>
>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?!?

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.

>Am i missing soemthing here?!?

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

>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.

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.

>>> c) Another question is why does the router has to have 2 interfaces and
>>> not just 1 the external that we pay for?

>> To separate the traffic.

> LAN traffic form WAN traffic i guess.

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.

>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?

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.

>> 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?"
>
>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?

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?

>I dont see how they can communicate otherwise each other.

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.

>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?

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).

>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?

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

        Old guy

Relevant Pages

  • Re: router causing ssh etc. slowdown?
    ... >> port on their public IP from a host on their own LAN. ... Let's say host A starts a TCP connection from its ... The router sends the SYN packet to ...
    (Fedora)
  • Re: UPNP/SSDP
    ... otherwise it's just a glorified packet filter with a set of rules. ... neither a NAT nor a router are referred to as packet filters. ... a NAT router for broadband internet does not do this, ... router to route traffic b/w two or more private networks and the internet. ...
    (microsoft.public.windowsxp.general)
  • Re: Nmap questions concering my router
    ... has only one interface, ... as having a chunk of space in the computer much like a hotel room. ... >is) directly connected to my router, which i dont set up a NAT yet. ... Which IP address is the packet addressed to? ...
    (comp.security.firewalls)
  • Re: IIS5 Passive FTP Networking problem (long)
    ... or do away with the router entirely (and the hardware based ... > had the ability to run an FTP server behind it without changing the IP ... The NAT changes the PASV response ... translate the address fields of a packet. ...
    (microsoft.public.inetserver.iis.security)
  • Re: MSS on router, why?
    ... The proper way to describe the ICMP packet which is supposed to be ... returned by a router which cannot forward the IP packet which is too ... Because ICMP was defined before Path MTU Discovery (1981 and 1990 ... fragmentation and try to use path MTU discovery, ...
    (comp.dcom.sys.cisco)