Re: [72attendees] In-room network

["LANGE Andrew" <[e-mail]>]

The hotel has been very responsive to our needs.  They jumped on this issues this morning as soon as they came in.

The fix for PPTP passthrough broke IPSec/UDP, since the internal IP's were not set to always map to the same external IP.  This caused multiple sessions from the same host to get mapped to multiple external IPs. This has been fixed.  It's good to hear confirmation that this has cleared up the problem.

The hotel has not been blocking any ports out since we have arrived.  We've arranged for as clear a pipe as possible without breaking their other systems. 

Andrew


-----Original Message-----
From: [e-mail] on behalf of Richard Pruss
Sent: Tue 7/29/2008 8:51 AM
To: Vint Cerf
Cc: [e-mail]; Marshall Eubanks; Jeffrey Hutzelman
Subject: Re: [72attendees] In-room network
 
IPSec/UDP is working again.  Thanks to our hosts for taking on  
repairing this for us, I understand it was outside your  
responsibilities. Thanks for the extra effort,
Ric

On 29/07/2008, at 1:27 PM, Vint Cerf wrote:

> AIM seems to be working now in room block 16XX
>
> v
>
> On Jul 29, 2008, at 8:24 AM, Marshall Eubanks wrote:
>
>> Something that I did not mention that is relevant is that I was  
>> using AIM from the room Sunday night.
>>
>> So, something changed over 24 hours.
>>
>> Regards
>> Marshall
>>
>> On Jul 29, 2008, at 7:29 AM, Jeffrey Hutzelman wrote:
>>
>>> --On Monday, July 28, 2008 08:14:03 PM -0400 Marshall Eubanks <[e-mail] 
>>> > wrote:
>>>
>>>> Tonight from my room, I get connection failures for AIM, but  
>>>> jabber, ssh,
>>>> http, etc., all work fine. It sounds like port blockage to me.
>>>
>>> Really?  Have you collected any data that shows that your packets  
>>> are not getting through?  Or are you simply assuming that if it  
>>> doesn't work, it must be because the port is blocked?
>>>
>>> Someone noted earlier that the hotel's NAT seems to be allocating  
>>> a different outside IP address for each outgoing  
>>> "connection" (which, for UDP, often means each packet).  There are  
>>> certainly a lot of UDP-based protocols that that will break, if  
>>> it's true (I'm not entirely convinced, because I run things that  
>>> it _should_ break pretty badly but that seem to work fine).
>>>
>>> FWIW, I've also noticed AIM breaking from behind other NAT's  
>>> lately, which may indicate the protocol is NAT-unfriendly in some  
>>> way.  That would be news to me, but then, it's not a protocol I  
>>> use often, and I avoid NAT's when I can.
>>>
>>> Of course, it's also possible that some people's VPN connections  
>>> are breaking because they expect to use a particular port, either  
>>> for tunneled traffic or for IKE, or because they expect to use a  
>>> protocol for which the NAT cannot multiplex multiple connections.   
>>> Those of us who've done this a few times presumably know about  
>>> these pitfalls by now, but there will always be someone who's  
>>> never encountered the problem before.
>>>
>>>
>>> I would suggest that if folks are having problems getting  
>>> particular protocols to work, that they collect as much data as  
>>> possible about what is going on and then report the problem to the  
>>> hotel.  Maybe one of the NOC folks can give us an idea of what  
>>> sorts of data are most useful.
>>>
>>> -- Jeff
>>
>> _______________________________________________
>> 72attendees mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/72attendees
>
> _______________________________________________
> 72attendees mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/72attendees

_______________________________________________
72attendees mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/72attendees

_______________________________________________
72attendees mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/72attendees