- Posts: 4
- Thank you received: 0
TCP SEGMENTS..THROUGH NAT
19 years 10 months ago #6742
by noddy938
TCP SEGMENTS..THROUGH NAT was created by noddy938
Hi Everybody,
Am a newbie into networking. There are some things for which I am not able to get a proper and logical explanation. It might sound very stupid…but I never like to keep these doubts in my head. Ok let me come to the point…
Let’s consider a scenario
Computer-->Router-->Cable Modem-->Internet
Computer is hardwired to the router and the router in turn is hardwired to the modem which leads to the internet. Let me also describe the characteristics of the router. The router is used as a GATEWAY and has NAT enabled, just like any of our Netgear, Linksys, D-link routers…etc.
Computer – IP 192.168.0.10/24 GW: 192.168.0.1
Router – LAN
IP: 192.168.0.1/24
WAN
IP: A valid public IP address and a default gateway within the subnet of the IP address
All requests from the computer that goes through the router (NAT) have its source IP address changed.
For instance…..
When you request for a webpage from Firewall.cx having the IP address of 66.45.237.140, the packet that leaves the computer has its Source IP address as the IP address of the computer which in our case is a Class C Private address, and the destination address as that of Firewall.cx. As soon as the packet crosses NAT, the Source IP address of the packet changes into the public IP address of the router, but the destination still remains the same. Now considering the TCP header flag CHECKSUM….
CHECKSUM = PSEUDO HEADER + TCP HEADER + DATA
PSEUDO HEADER is calculated at source and later at destination with these values
1) SOURCE IP ADDRESS
2) DESTINATION IP ADDRESS
3) PROTOCOL
4) TCP LENGTH
That means when a TCP connection has to be established the CHECKSUM calculated and put into the TCP segment at source and the TCP CHECKSUM recalculated at the destination would not match as the SOURCE IP ADDRESS in the segment, when the segment was at the computer is different from the SOURCE IP ADDRESS of the segment when the segment is at the destination.
Since this scenario works beautifully fine and that you get the firwall.cx page displayed, my doubt is if the router would recalculate the CHECKSUM in the TCP segment?
Am a newbie into networking. There are some things for which I am not able to get a proper and logical explanation. It might sound very stupid…but I never like to keep these doubts in my head. Ok let me come to the point…
Let’s consider a scenario
Computer-->Router-->Cable Modem-->Internet
Computer is hardwired to the router and the router in turn is hardwired to the modem which leads to the internet. Let me also describe the characteristics of the router. The router is used as a GATEWAY and has NAT enabled, just like any of our Netgear, Linksys, D-link routers…etc.
Computer – IP 192.168.0.10/24 GW: 192.168.0.1
Router – LAN
IP: 192.168.0.1/24
WAN
IP: A valid public IP address and a default gateway within the subnet of the IP address
All requests from the computer that goes through the router (NAT) have its source IP address changed.
For instance…..
When you request for a webpage from Firewall.cx having the IP address of 66.45.237.140, the packet that leaves the computer has its Source IP address as the IP address of the computer which in our case is a Class C Private address, and the destination address as that of Firewall.cx. As soon as the packet crosses NAT, the Source IP address of the packet changes into the public IP address of the router, but the destination still remains the same. Now considering the TCP header flag CHECKSUM….
CHECKSUM = PSEUDO HEADER + TCP HEADER + DATA
PSEUDO HEADER is calculated at source and later at destination with these values
1) SOURCE IP ADDRESS
2) DESTINATION IP ADDRESS
3) PROTOCOL
4) TCP LENGTH
That means when a TCP connection has to be established the CHECKSUM calculated and put into the TCP segment at source and the TCP CHECKSUM recalculated at the destination would not match as the SOURCE IP ADDRESS in the segment, when the segment was at the computer is different from the SOURCE IP ADDRESS of the segment when the segment is at the destination.
Since this scenario works beautifully fine and that you get the firwall.cx page displayed, my doubt is if the router would recalculate the CHECKSUM in the TCP segment?
19 years 10 months ago #6763
by mew
Replied by mew on topic Re: TCP SEGMENTS..THROUGH NAT
Yes.
19 years 10 months ago #6770
by noddy938
Replied by noddy938 on topic Re: TCP SEGMENTS..THROUGH NAT
mew,
As the router can DECAPSULATE the TCP SEGMENT and recalculate the CHECKSUM and again ENCAPSULATE it......this would mean that NAT works at Layer 4 of the OSI and not at Layer 3
More over as port number apear only in a TCP segment....and that Access List can be implemented in a router where traffic can be blocked or allowed using port numbers....this also means that the router works at Layer 4 of the OSI and not at Layer 3
As the router can DECAPSULATE the TCP SEGMENT and recalculate the CHECKSUM and again ENCAPSULATE it......this would mean that NAT works at Layer 4 of the OSI and not at Layer 3
More over as port number apear only in a TCP segment....and that Access List can be implemented in a router where traffic can be blocked or allowed using port numbers....this also means that the router works at Layer 4 of the OSI and not at Layer 3
19 years 10 months ago #6786
by sahirh
Sahir Hidayatullah.
Firewall.cx Staff - Associate Editor & Security Advisor
tftfotw.blogspot.com
Replied by sahirh on topic Re: TCP SEGMENTS..THROUGH NAT
A router with access lists works at layer 4, however *routing* itself is a layer 3 activity..
Similarly a switch works at layer 2, but a switch that understands IP addressing works at layer 3.. if you have a content switch, it works at layer 7.. the application protocol layer
its all a matter of perspective, these things are never cut and dried.
Similarly a switch works at layer 2, but a switch that understands IP addressing works at layer 3.. if you have a content switch, it works at layer 7.. the application protocol layer
its all a matter of perspective, these things are never cut and dried.
Sahir Hidayatullah.
Firewall.cx Staff - Associate Editor & Security Advisor
tftfotw.blogspot.com
Time to create page: 0.124 seconds