LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 05-02-2017, 12:43 PM   #1
fanoflq
Member
 
Registered: Nov 2015
Posts: 397

Rep: Reputation: Disabled
Source IP address in IP packets


I see examples where the source
and destination IPs are on same
network were used to illustrate the IP header.

If you send a packet to a destination
on a different network, meaning through
the Internet and finally reaching another
network, NAT (network address translation)
at router occurs.

The source IP of local host, e.g. 192.168.1.100,
is a private IP address, and the receiver
cannot just send a respond to 192.168.1.100
because there are thousands if not millions
of such private IP addresses.

How is the source IP preserved (embedded) in the
IP packet by the time the packet reached the
destination network (which is not the same
network as the sender's network) just before
it is unpacked by the destination router?

Last edited by fanoflq; 05-02-2017 at 12:51 PM.
 
Old 05-02-2017, 01:13 PM   #2
MadeInGermany
Senior Member
 
Registered: Dec 2011
Location: Simplicity
Posts: 1,765

Rep: Reputation: 797Reputation: 797Reputation: 797Reputation: 797Reputation: 797Reputation: 797Reputation: 797
The NATting router needs to replace the original source IP by a public source IP, then forward the packet to the outer network.
And vice versa when it receives the answer.
 
Old 05-02-2017, 01:37 PM   #3
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
Quote:
Originally Posted by fanoflq View Post
How is the source IP preserved (embedded) in the
IP packet by the time the packet reached the
destination network (which is not the same
network as the sender's network) just before
it is unpacked by the destination router?
The Private IP is not preserved in the Packet. It is preserved with Connection Tracking.
 
Old 05-02-2017, 02:23 PM   #4
rtmistler
Moderator
 
Registered: Mar 2011
Location: USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 9,354
Blog Entries: 13

Rep: Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411Reputation: 4411
This does not necessarily have to employ NAT either, the function of the router is to allow public access for the local private network, by using the public IP and keeping track of the individual MAC addresses of your local stations for all communications that go through the router.
 
Old 05-02-2017, 03:16 PM   #5
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,229
Blog Entries: 4

Rep: Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260Reputation: 3260
To clarify, (Source ...) NAT ("Network Address Translation") uses a randomly-assigned source port-number to disambiguate the returning traffic. When it makes a connection to the outside world, it associates a randomly-assigned port-number with your internal IP-address, and includes that number in all traffic that "you" are sending. This is what enables it to return the replies to "you."

The public never knows your internal IP-address within your home network. All outbound traffic appears to originate from your router and will be returned to your router. (Where it goes from there is unknown to the outside world.) The assignment of source port-numbers is random and meaningless, and never intrudes into the range of "well-known port numbers."

- - - - -

If inbound traffic, which is not a reply to something that you previously sent, is being sent to your IP, then port forwarding is required to cause the traffic to be delivered to the proper internal IP. For instance, if you are running an HTTP server on your box, your router must have a port-forwarding rule that says that inbound traffic to "port 80" must be sent to "your box" and not your sister's iPhone.

Last edited by sundialsvcs; 05-02-2017 at 03:23 PM.
 
Old 05-02-2017, 03:33 PM   #6
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,555

Rep: Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088
Quote:
Originally Posted by sundialsvcs View Post
To clarify, (Source ...) NAT ("Network Address Translation") uses a randomly-assigned source port-number to disambiguate the returning traffic.
In Linux, at least, it assigns a new source port if necessary to disambiguate the connection. If the tuple of (SPORT, DEST, DPORT) is not currently present in connection tracking, the source port is left as it is.
 
Old 05-02-2017, 04:11 PM   #7
fanoflq
Member
 
Registered: Nov 2015
Posts: 397

Original Poster
Rep: Reputation: Disabled
Thank you for all your responses.
I also read this link:
Quote:
The Private IP is not preserved in the Packet. It is preserved with
http://www.slashroot.in/linux-nat-ne...uter-explained.

Here are what I know when a tcp packet leaves the router from sender:

In tcp header, you have the sender's port and destination port.
In ip header, the sender's IP address was replaced by router's IP address.

When the destination server respond, it send back these information:
In tcp header, you have the respondent's port and destination port.
In ip header, the respondent's IP address was replaced by router's IP address. You also have destination (public) IP address.


Now if you have two local hosts using same port number, and sending a tcp packet to same server's IP address at same port number, and when the local host' router receives a packet from respondent, it was not clear to me these information (respondent's public IP address and its port as well as destination (local host) port number and its public (router) IP address) are adequate to determine the correct destination of the packet since we now have two local hosts using the same port number.

Summary of question:
Respondent (server) sends tcp packet that has:
(respondent IP, respondent port, destination router IP and port number of original sender. )

Destination router has to resolve above tcp packet
from respondent to two local hosts which coincidentally use same port number and tcp protocol when sending packets to same server..
Inadequate information for local hosts' router to resolve destination local host for incoming tcp packet.

What did I missed?

Last edited by fanoflq; 05-02-2017 at 04:57 PM.
 
Old 05-02-2017, 05:01 PM   #8
AwesomeMachine
LQ Guru
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,513

Rep: Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009Reputation: 1009
From wikipedia:

Quote:
PCP allows deployed equipment and applications to create explicit mappings between an external IP address, protocol and port, and an internal IP address, protocol and port. With such explicit mappings in place, inbound communication can reach the hosts behind a NAT or firewall, which either expands their server roles beyond boundaries of local networks, or makes use of various services simplified and less resource-consuming. Created mappings are permanent to the extent of having a known lifetime that can be extended, which is similar to the way Dynamic Host Configuration Protocol (DHCP) implements its leases. At the same time, PCP allows applications to create additional mappings dynamically as required, which reduces or eliminates the need for having ALG-enabled NAT devices and firewalls.[1][3]

Created explicit mappings are permanent, with no need for application-level keepalive messages to be exchanged between hosts and servers for the purpose of preserving the mapping. As a result, network usage and power consumption are reduced, and application-level keepalive logic no longer needs to be implemented at client and server sides. After a PCP-based mapping is created, associated externally visible parameters (IP address, protocol and port) need to be announced to clients so incoming connections can be established, which is performed in application-specific ways. Additionally, PCP provides the functionality required to inform applications when the external IP address is changed while a mapping is already established.[1][3]

Various types of NAT can be handled by PCP, providing support for IPv6/IPv4 NAT (NAT64, sharing of an IPv6 address) and IPv4/IPv4 NAT (NAT44, sharing of an IPv4 address); inclusion of PCP into IPv4 and IPv6 firewall devices is also supported. PCP is designed to be used on both large-scale aggregation points (for example, as part of carrier-grade NATs), and inside low-cost consumer-grade devices. Both long-term (for an IP camera or a temperature sensor acting as a server, for example) and short-term mappings (while playing an online computer game, for example) are supported.
The important part is that the mappings, internal and external port, protocol and address; are unique.

Last edited by AwesomeMachine; 05-02-2017 at 05:05 PM.
 
Old 05-02-2017, 06:00 PM   #9
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,555

Rep: Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088
Quote:
Originally Posted by fanoflq View Post
Now if you have two local hosts using same port number, and sending a tcp packet to same server's IP address at same port number, and when the local host' router receives a packet from respondent, it was not clear to me these information (respondent's public IP address and its port as well as destination (local host) port number and its public (router) IP address) are adequate to determine the correct destination of the packet since we now have two local hosts using the same port number.
For at least one of those connections, NAT will have substituted a different source port number so that the tuple (SPORT, DST, DPORT) uniquely identifies the connection. When a reply packet comes back, the (DPORT, SRC, SPORT) tuple of the reply packet will match the translated (SPORT, DST, DPORT) of exactly one tracked connection, and the destination address and port number can be translated back to the original source address and port number.

Last edited by rknichols; 05-02-2017 at 06:01 PM.
 
1 members found this post helpful.
Old 05-02-2017, 06:05 PM   #10
fanoflq
Member
 
Registered: Nov 2015
Posts: 397

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by rknichols View Post
For at least one of those connections, NAT will have substituted a different source port number so that the tuple (SPORT, DST, DPORT) uniquely identifies the connection. When a reply packet comes back, the (DPORT, SRC, SPORT) tuple of the reply packet will match the translated (SPORT, DST, DPORT) of exactly one tracked connection, and the destination address and port number can be translated back to the original source address and port number.
That solves the posted question.
Thank you.
 
Old 05-04-2017, 07:46 AM   #11
lazydog
Senior Member
 
Registered: Dec 2003
Location: The Key Stone State
Distribution: CentOS Sabayon and now Gentoo
Posts: 1,249
Blog Entries: 3

Rep: Reputation: 194Reputation: 194
Quote:
Originally Posted by rknichols View Post
For at least one of those connections, NAT will have substituted a different source port number so that the tuple (SPORT, DST, DPORT) uniquely identifies the connection. When a reply packet comes back, the (DPORT, SRC, SPORT) tuple of the reply packet will match the translated (SPORT, DST, DPORT) of exactly one tracked connection, and the destination address and port number can be translated back to the original source address and port number.
If I am not mistaking the only time this will happen is when you have 2 internal hosts talking to the same external host using the same internal ports. Now your are talking PAT and not NAT.
 
Old 05-04-2017, 08:54 AM   #12
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,555

Rep: Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088Reputation: 2088
Quote:
Originally Posted by lazydog View Post
If I am not mistaking the only time this will happen is when you have 2 internal hosts talking to the same external host using the same internal ports. Now your are talking PAT and not NAT.
Exactly. The NAT modules will also do port translation automatically if necessary to disambiguate the connection.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Source ip is not changed to Masqurade ip in the reply or ack packets while other packets are masquraded EgAyman Linux - Kernel 3 09-20-2016 03:00 PM
Cannot send out packets with spoofed source address StarGhost Linux - Networking 2 09-14-2008 11:44 AM
Sending Packets to an IP Address Dynamically des_a Linux - Networking 6 04-08-2008 11:13 PM
detect ip address of packets dales79 Linux - Networking 5 01-17-2006 06:29 AM
IPTABLES - How to allow all packets from a certain address exitsfunnel Linux - Networking 3 09-06-2005 10:35 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 06:24 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration