1 Feb
2018
1 Feb
'18
2:33 p.m.
---------- Forwarded message ----------
From: fırat sönmez <firatssonmez(a)gmail.com>
Date: 2018-02-01 15:51 GMT+03:00
Subject: Re: icmp encapsulation
To: Pau Espin Pedrol <pespin(a)sysmocom.de>
Hi Pau,
Thank you for your response.
You are right, I should have told the configuration in more detail.
However, you came to the point already. I am talking about the second case
where there is NAT. There is a slight difference though.
After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the IP1
and IP2 to the port range. Since, there is no port in ICMP, both IP1 and
IP2 will be go to uplink as IPg and but on the return there must be problem
for NAT machine to traverse the two different paths from IPnat to IP1 and
IPnat to IP2. I looked into the ICMP header and observed the packets have
different identifiers. So, NAT machine must be using the identifies to
reverse the packets.
Anyways, in my case the *IP1=IP2* (In my experimental architecture, the
GGSN will not be assigning distinct IP for each host. Instead, GGSN will
assign 1 IP address for 32 hosts (seems like NAT). My configuration is
probably out of standard architectures, but I need to understand how would
gtp handle matching these two pdp contexts. I have tried this
configuration, pinging from two different host with same IP and it was
successful!
Two packets coming from the server to the GGSN will be *[src:IPs | dst:IP1]*
and *[src:IPs | dst:IP2]* IP1=IP2, but two packets have different icmp
identifier. And pdp contexts are still resolved successfully. so a big HOW
in my mind?
Fırat
2018-02-01 13:46 GMT+03:00 Pau Espin Pedrol <pespin(a)sysmocom.de>de>:
Hi firat,
I didn't understand fully the configuration you are describing. Something
like this?
Host1 --SGSN1--\GGSN--Server
Host2 --SGSN2--/
Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both
assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and
the GGSN public uplink (non-GTP) IP is IPg.
As far as I understand, it works as follow:
- Case without NAT between GGSN and Server:
Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets encapsulated
through GTP and GGSN decapsulates it. Same for Host2 but in this case the
packet will have saddr=IP2. As there's no NAT (eg. host clients are
assigned a public IP), the server receives 2 ICMP packets with different
saddr, and when answering back using the original saddr now as daddr. As
GGSN keeps track of the saddr assigned to each pdp context, when it
receives a packet from the uplink (non-GTP side), it matches the daddr of
the packet against the saddr of the active pdp ctx to find to which pdp ctx
should forward the packet.
- Case with NAT between GGSN and Server:
Almost the same but with extra steps done by the NAT. When the GGSN sends
the packet saddr=IP1 daddr=IPs to the server, the NAT changes
saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track of
the binding. When the response is received from the server, the NAT
converts back IPg->IP1 and GGSN can again track the pdp ctx as described in
the previous case.
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte