<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Re[6]: Communication breakdown....
From: "Damion K. Wilson" <dwilson,AT,ibl,DOT,bm>
Date: Fri, 28 Feb 2003 19:41:19 +0100
In-reply-to: <15319914906.20030226134401@wanadoo.fr>

CIPE-Win32 isn't modal like that. All it cares about is the source IP address 
of the last correctly decrypted tunnel packet, which it uses as the 
destination address for any outgoing packets.

DKW

On Friday 28 February 2003 02:09 pm, you wrote:
> Hello Damion,
>
> well I had to get my hands dirty. I knocked up a quick UDP packet
> capture program. What I did was this: get things running normally and
> then stop the local peer and start my packet capture program. Because
> it's encrpyted the only usual info for me is the sorce ip and port
> number I also waited for the connection to crack and did the same (not
> crack but drop inthe my udp capture prog). Here are the results:
>
> when things work normally the packets out of the NATed peer look like
> this
>
> source:  virtual_ip:6023
> dest:    local_ip:6023
>
> when things are busted the packets out of the NATed peer look like
> this
>
> source:  NAT_box_ip:32768 (port can vary)
> dest:    local_ip:6023
>
> So clearly there is a problem with NAT setup. Normally this should not
> be a problem as I have hard wired the ip:port at my local end so that
> the source of the packets shouldn't make a difference. Unfortunately
> this is not the case and my local peer appears to pick up this dodgy
> source pair for it destination as I imagine it would if I had
> configured for 0.0.0.0:6023 and not virtual_ip:6023, which the
> firewall then kills as the destination port is not valid (6023).
>
> I haven't got into the source code but is it possible that if the link
> is down long enough then any peer might fallback to a 0.0.0.0:anyport
> setup, and latch on to the first incoming packet?
>
> In the meantime we're looking at solving our NAT problems....





<< | Thread Index | >> ]    [ << | Date Index | >> ]