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 <tme@multicasttech.com 
>>> > 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
>> 72attendees@ietf.org
>> https://www.ietf.org/mailman/listinfo/72attendees
>
> _______________________________________________
> 72attendees mailing list
> 72attendees@ietf.org
> https://www.ietf.org/mailman/listinfo/72attendees

_______________________________________________
72attendees mailing list
72attendees@ietf.org
https://www.ietf.org/mailman/listinfo/72attendees