SCTP Discussions

Text archives Help


[SCTP-Discussion] Re: INIT from private IP address to public IP address never received


Chronological Thread 
  • From: "La Monte Henry Piggy Yarroll" <piggy AT baqaqi.chi.il.us>
  • To: "Eng Se-Hsieng" <g0202512 AT nus.edu.sg>
  • Cc: sctp_impl AT external.cisco.com, discussion AT sctp.de
  • Subject: [SCTP-Discussion] Re: INIT from private IP address to public IP address never received
  • Date: Mon May 5 14:37:02 2003
  • List-id: SCTP Discussions <discussion.sctp.de>

On Fri, 2 May 2003 22:31:17 +0800, "Eng Se-Hsieng"
<g0202512 AT nus.edu.sg>
wrote:
> >> Dear all,
> >>
> >> I have tried the following scenario using the Reference Implementation
> >> with actual existing networks. Host A is on a GPRS network and Host B is
> >> on a university network and is assigned a fixed IP.
> >>
> >> Results using the University of Essen's implementatino were very
> >> similar.
> >>
> >> Host A (private IP 172.18.56.36) towards Host B (fixed IP
> >> 137.132.165.205)
>
> > That means you are using NAT. The NAT firewall almost certainly
> > does NOT support SCTP. I don't know of ANY SCTP NAT firewalls
> > available yet.
>
> The following is the tcpdump output from the operator, although it's
> probably not the NAT machine. Two surprising things occured.
>
> 1. DNS queries of the source machine hostname (CYRILLE) with
> variations CYRILLE.nus.edu.sg and CYRILLE

Where does the DNS query originate? I wouldn't expect such a query,
but it doesn't surprise me.

> 2. for every SCTP packet sent, we noticed one corresponding ICMP
> packet on Ethereal, from the operator's network, with the Destination
> Unreachable (3) code and Host Unreachable subcode (1). Surprisingly,
> the Protocol Unreachable subcode wasn't received.

Your NAT box didn't recognize the protocol, so it passed the packet
out to the live Internet, thus leaking an RFC1918 address, which is of
course unreachable.

> Would you happen to have any ideas on what these ICMP packets are
> for or why the DNS queries are carried out? Path MTU discovery?
>
> Also, what are the chances of UDP encapsulation being supported on
> actual NATs today? We are thinking of trying that out.

Good point, UDP encapsulation should work fine. Of course, that
severely limits your interoperability...

> Thank you.
>
> Regards,
> Se-Hsieng
>
> 14:30:39.826588 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:30:39.947056 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:30:45.826561 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:30:57.126663 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:31:21.266795 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:32:12.178799 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
> 14:33:04.639663 I 172.22.83.100.32770 > 137.132.123.4.53: 53768+ A?
> CYRILLE.nus.edu.sg. (36) (DF)
> 14:33:04.659178 O 137.132.123.4.53 > 172.22.83.100.32770: 53768 NXDomain*
> 0/1/0 (83)
> 14:33:05.719556 I 172.22.83.100.32770 > 137.132.123.4.53: 53769+ A?
> CYRILLE. (25) (DF)
> 14:33:05.724976 O 137.132.123.4.53 > 172.22.83.100.32770: 53769 Refused
> 0/0/0 (25)
> 14:33:06.399734 I 172.22.83.100.32770 > 137.132.5.2.53: 53769+ A? CYRILLE.
> (25) (DF)
> 14:33:06.405689 O 137.132.5.2.53 > 172.22.83.100.32770: 53769 Refused
> 0/0/0 (25)
> 14:33:07.279830 I 172.22.83.100.32770 > 137.132.123.4.53: 53769+ A?
> CYRILLE. (25) (DF)
> 14:33:07.285648 O 137.132.123.4.53 > 172.22.83.100.32770: 53769 Refused
> 0/0/0 (25)
> 14:33:07.999634 I 172.22.83.100.32770 > 137.132.5.2.53: 53769+ A? CYRILLE.
> (25) (DF)
> 14:33:08.859617 I 172.22.83.100 > 137.132.165.146: ip-proto-132 48
>
>
>




Archive powered by MHonArc 2.6.19+.

Top of page