Mailing List Archive: vpnc: devel

Unreproducible connection result

Index | Next | Previous | View Threaded

piero.ottuzzi at omnys

Nov 15, 2004, 4:12 PM

Post #1 of 11 (772 views)
Permalink

Unreproducible connection result

Hi there,

using vpnc sometimes I see strange behaviour: sometimes everything is smooth
sometimes not.
So it happens that I always see
VPNC started in background (pid: XXXXX)...

but sometimes I cannot ping hosts in VPN: I can ping hosts in my own private
network but not the "remote" one.

I cannot find under which conditions this happens... does anybody has a tip?
If needed I can provide logs, routing tables (which seems fine) etc etc.

Many Thanks
Piero

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041115/040943d8/attachment.pgp

piero.ottuzzi at omnys

Nov 15, 2004, 5:47 PM

Post #2 of 11 (748 views)
Permalink

Unreproducible connection result [In reply to]

Hi again,

it is always me ;-)

I found something interesting about this problem: if you wait enough things
start working...

So I have a ping running and after many seconds (maybe 3 maybe 50) it begins
to work... this behaviour is something you don't notice with the official
client because it doesn't let you go until a connection is really
established.

Now the question: is there a smart way to simulate this?
Actually the tricky part is that vpnc-connect returns immediately letting you
think everything is working nicely (and probably it is... you have just to
wait some seconds)....

Ciaoo
Piero

Alle 16:12, luned? 15 novembre 2004, Piero Ottuzzi ha scritto:
> Hi there,
>
> using vpnc sometimes I see strange behaviour: sometimes everything is
> smooth sometimes not.
> So it happens that I always see
> VPNC started in background (pid: XXXXX)...
>
> but sometimes I cannot ping hosts in VPN: I can ping hosts in my own
> private network but not the "remote" one.
>
> I cannot find under which conditions this happens... does anybody has a
> tip? If needed I can provide logs, routing tables (which seems fine) etc
> etc.
>
> Many Thanks
> Piero

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041115/bf3e7571/attachment.pgp

massar at unix-ag

Nov 15, 2004, 8:45 PM

Post #3 of 11 (749 views)
Permalink

Unreproducible connection result [In reply to]

hi,

On Mon, Nov 15, 2004 at 05:47:06PM +0100, Piero Ottuzzi wrote:
> I found something interesting about this problem: if you wait enough things
> start working...
>
> So I have a ping running and after many seconds (maybe 3 maybe 50) it begins
> to work... this behaviour is something you don't notice with the official
> client because it doesn't let you go until a connection is really
> established.
>
> Now the question: is there a smart way to simulate this?
> Actually the tricky part is that vpnc-connect returns immediately letting you
> think everything is working nicely (and probably it is... you have just to
> wait some seconds)....

I think that is kind a strange ...

which transport methode is the cisco client using? and which one vpnc?
IPSec over ESP, NAT-T, TCP or UDP?

"private network" means that there is a NAT Device between vpnc and
the concentrator? or are you running vpnc on your gateway?

cu
maurice

piero.ottuzzi at omnys

Nov 16, 2004, 12:30 PM

Post #4 of 11 (749 views)
Permalink

Unreproducible connection result [In reply to]

Hi,

this is my routing table:
[root [at] ap piero]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
gw.cdn.interbus gateway02 255.255.255.255 UGH 0 0 0 eth0
192.168.17.0 * 255.255.255.0 U 0 0 0 tun0
192.168.16.0 * 255.255.255.0 U 0 0 0 tun0
192.168.9.0 * 255.255.255.0 U 0 0 0 eth0
default gateway02 0.0.0.0 UG 0 0 0 eth0

You can see that I send packets to tun0 if and only if they pertain to
networks 192.168.17.* and 192.168.16.* (remote private lans).
My PC is in a private LAN 192.168.9.* and I use vpnc directly on my PC.
If you ifconfig during a PING towards a remote address (say ping
192.168.17.202) here are the results:

tun0 Link encap:Point-to-Point Protocol
inet addr:192.168.16.122 P-t-P:192.168.16.122 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:477 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:39852 (38.9 Kb)

Here you can see TX packets going through tun0 but I don't receive any answer.
As you may guess 192.168.16.122 is my VPN address.

Here are the facts...

If you need more info please ask, I don't fully understand all these things
about VPN, routing etc etc so probably I'm a bit inaccurate.

Ciaoo
Piero

Alle 20:45, luned? 15 novembre 2004, Maurice Massar ha scritto:
> hi,
>
> On Mon, Nov 15, 2004 at 05:47:06PM +0100, Piero Ottuzzi wrote:
> > I found something interesting about this problem: if you wait enough
> > things start working...
> >
> > So I have a ping running and after many seconds (maybe 3 maybe 50) it
> > begins to work... this behaviour is something you don't notice with the
> > official client because it doesn't let you go until a connection is
> > really established.
> >
> > Now the question: is there a smart way to simulate this?
> > Actually the tricky part is that vpnc-connect returns immediately letting
> > you think everything is working nicely (and probably it is... you have
> > just to wait some seconds)....
>
> I think that is kind a strange ...
>
> which transport methode is the cisco client using? and which one vpnc?
> IPSec over ESP, NAT-T, TCP or UDP?
>
> "private network" means that there is a NAT Device between vpnc and
> the concentrator? or are you running vpnc on your gateway?
>
> cu
> maurice
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> http://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041116/8a1bcac9/attachment.pgp

hilse at web

Nov 16, 2004, 1:35 PM

Post #5 of 11 (747 views)
Permalink

Unreproducible connection result [In reply to]

Hi,

On Tue, 16 Nov 2004 12:30:24 +0100 you wrote:

> this is my routing table:
> [root [at] ap piero]# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> gw.cdn.interbus gateway02 255.255.255.255 UGH 0 0 0
> eth0 192.168.17.0 * 255.255.255.0 U 0 0
> 0 tun0
> 192.168.16.0 * 255.255.255.0 U 0 0 0
> tun0 192.168.9.0 * 255.255.255.0 U 0 0
> 0 eth0
> default gateway02 0.0.0.0 UG 0 0 0
> eth0
>
> You can see that I send packets to tun0 if and only if they pertain to
> networks 192.168.17.* and 192.168.16.* (remote private lans).
> My PC is in a private LAN 192.168.9.* and I use vpnc directly on my
> PC.
> [...]
> Here you can see TX packets going through tun0 but I don't receive any
> answer.
> As you may guess 192.168.16.122 is my VPN address.

Resolves 192.168.16.122 to gw.cdn.interbus? otherwise all traffic to
your VPN gateway would be routed through tun0 and would never reach the
VPN gateway.
Has gateway02 an address !=192.168.17.0/23? Otherwise the same would
apply here...

HWH

piero.ottuzzi at omnys

Nov 17, 2004, 12:18 PM

Post #6 of 11 (749 views)
Permalink

Unreproducible connection result [In reply to]

Hi again,

really can't remember where but I read somewhere that vpnc (or vpnc-connect)
setup routing before the tunnel is really opened.
I noted that vpnc always opens a working connection in the first tryout after
a reboot but it not always opens a working connection afterward (sometimes
yes, sometimes not as per thread title).

Is there a way to be absolutely sure that the tunnel is open?
Is there a way to know if the tunnel close for whatever reason?

Many thanks.
Piero

Alle 20:45, luned? 15 novembre 2004, Maurice Massar ha scritto:
> hi,
>
> On Mon, Nov 15, 2004 at 05:47:06PM +0100, Piero Ottuzzi wrote:
> > I found something interesting about this problem: if you wait enough
> > things start working...
> >
> > So I have a ping running and after many seconds (maybe 3 maybe 50) it
> > begins to work... this behaviour is something you don't notice with the
> > official client because it doesn't let you go until a connection is
> > really established.
> >
> > Now the question: is there a smart way to simulate this?
> > Actually the tricky part is that vpnc-connect returns immediately letting
> > you think everything is working nicely (and probably it is... you have
> > just to wait some seconds)....
>
> I think that is kind a strange ...
>
> which transport methode is the cisco client using? and which one vpnc?
> IPSec over ESP, NAT-T, TCP or UDP?
>
> "private network" means that there is a NAT Device between vpnc and
> the concentrator? or are you running vpnc on your gateway?
>
> cu
> maurice
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> http://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041117/4044cdff/attachment.pgp

massar at unix-ag

Nov 17, 2004, 6:56 PM

Post #7 of 11 (752 views)
Permalink

Unreproducible connection result [In reply to]

hi,

On Wed, Nov 17, 2004 at 12:17:55PM +0100, Piero Ottuzzi wrote:
> Hi again,
>
> really can't remember where but I read somewhere that vpnc (or vpnc-connect)
> setup routing before the tunnel is really opened.
> I noted that vpnc always opens a working connection in the first tryout after
> a reboot but it not always opens a working connection afterward (sometimes
> yes, sometimes not as per thread title).
>
> Is there a way to be absolutely sure that the tunnel is open?
> Is there a way to know if the tunnel close for whatever reason?

when vpnc returns, the "Config Script" is done, so the tunnel device
is fully set up and routing should be in place (this should be done
by the config script, vpnc-connect does that).

I am relatively certain that the vpnc side is ready as soon as vpnc
backgrounds itself.

Maybe using tcpdump could verfiy this.

cu
maurice

piero.ottuzzi at omnys

Nov 18, 2004, 9:54 AM

Post #8 of 11 (749 views)
Permalink

Unreproducible connection result [In reply to]

Hi,

for my work I need to continuosly (5-10 times in the morning) enter and exit
vpn: I noted that, FOR SURE, the first time I connect everything works
smoothly but this smmothness does not happen in later connections.

I saw that tun0 disappear after a vpnc-disconnect so tun0 should not be the
problem...
Is it possible that under some circumstances some garbage remains somewhere
limiting the possibilities of succesful connection after first one?

Many thanks.
Ciaoo
Piero

Alle 18:56, mercoled? 17 novembre 2004, Maurice Massar ha scritto:
> hi,
>
> On Wed, Nov 17, 2004 at 12:17:55PM +0100, Piero Ottuzzi wrote:
> > Hi again,
> >
> > really can't remember where but I read somewhere that vpnc (or
> > vpnc-connect) setup routing before the tunnel is really opened.
> > I noted that vpnc always opens a working connection in the first tryout
> > after a reboot but it not always opens a working connection afterward
> > (sometimes yes, sometimes not as per thread title).
> >
> > Is there a way to be absolutely sure that the tunnel is open?
> > Is there a way to know if the tunnel close for whatever reason?
>
> when vpnc returns, the "Config Script" is done, so the tunnel device
> is fully set up and routing should be in place (this should be done
> by the config script, vpnc-connect does that).
>
> I am relatively certain that the vpnc side is ready as soon as vpnc
> backgrounds itself.
>
> Maybe using tcpdump could verfiy this.
>
> cu
> maurice
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> http://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041118/258e51bf/attachment.pgp

piero.ottuzzi at omnys

Nov 19, 2004, 10:48 AM

Post #9 of 11 (751 views)
Permalink

Unreproducible connection result [In reply to]

Hi,

sorry for stressing this point... but I would like to understand what is
really happening....
This morning I started and used vpnc regularly and disconnected OK.
The I needed to re-enter VPN but then nothing worked OK.
vpnc-connect said it was connected.
As you suggested I made a ping towards a remote vpn machine and then I run
tcpdump:
[root [at] ap piero]# tcpdump -vv -i tun0
tcpdump: listening on tun0, link-type LINUX_SLL (Linux cooked), capture size
96 bytes
10:35:15.489341 IP (tos 0x0, ttl 64, id 529, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 530
10:35:15.526643 IP (tos 0x0, ttl 64, id 22148, offset 0, flags [DF], length:
73) 192.168.16.102.33265 > 213.21.141.2.domain: [udp sum ok] 44168+ PTR?
102.16.168.192.in-addr.arpa. (45)
10:35:16.488862 IP (tos 0x0, ttl 64, id 530, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 531
10:35:17.456691 IP (tos 0x0, ttl 64, id 24079, offset 0, flags [DF], length:
63) 192.168.16.102.33266 > 62.152.33.7.domain: [udp sum ok] 3025+ A?
scs.msg.yahoo.com. (35)
10:35:17.488665 IP (tos 0x0, ttl 64, id 531, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 532
10:35:18.488469 IP (tos 0x0, ttl 64, id 532, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 533
10:35:18.526421 IP (tos 0x0, ttl 64, id 25149, offset 0, flags [DF], length:
73) 192.168.16.102.33267 > 62.152.33.7.domain: [udp sum ok] 44168+ PTR?
102.16.168.192.in-addr.arpa. (45)
10:35:19.488216 IP (tos 0x0, ttl 64, id 533, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 534
10:35:20.488021 IP (tos 0x0, ttl 64, id 534, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 535
10:35:21.487825 IP (tos 0x0, ttl 64, id 535, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 536
10:35:22.487673 IP (tos 0x0, ttl 64, id 536, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 537
10:35:23.456633 IP (tos 0x0, ttl 64, id 30080, offset 0, flags [DF], length:
63) 192.168.16.102.33268 > 213.21.141.2.domain: [udp sum ok] 3025+ A?
scs.msg.yahoo.com. (35)
10:35:23.487432 IP (tos 0x0, ttl 64, id 537, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 538
10:35:24.487570 IP (tos 0x0, ttl 64, id 538, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 539
10:35:24.526380 IP (tos 0x0, ttl 64, id 31150, offset 0, flags [DF], length:
73) 192.168.16.102.33269 > 213.21.141.2.domain: [udp sum ok] 44168+ PTR?
102.16.168.192.in-addr.arpa. (45)
10:35:25.487042 IP (tos 0x0, ttl 64, id 539, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 540
10:35:26.456866 IP (tos 0x0, ttl 64, id 33081, offset 0, flags [DF], length:
63) 192.168.16.102.33270 > 62.152.33.7.domain: [udp sum ok] 3025+ A?
scs.msg.yahoo.com. (35)
10:35:26.486858 IP (tos 0x0, ttl 64, id 540, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 541
10:35:27.486734 IP (tos 0x0, ttl 64, id 541, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 542
10:35:27.527958 IP (tos 0x0, ttl 64, id 34152, offset 0, flags [DF], length:
73) 192.168.16.102.33271 > 62.152.33.7.domain: [udp sum ok] 44168+ PTR?
102.16.168.192.in-addr.arpa. (45)
10:35:28.486839 IP (tos 0x0, ttl 64, id 542, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 543
10:35:29.486272 IP (tos 0x0, ttl 64, id 543, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 544
10:35:30.486078 IP (tos 0x0, ttl 64, id 544, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 545
10:35:31.485930 IP (tos 0x0, ttl 64, id 545, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 546
10:35:32.456893 IP (tos 0x0, ttl 64, id 39082, offset 0, flags [DF], length:
63) 192.168.16.102.33272 > 213.21.141.2.domain: [udp sum ok] 3026+ A?
scs.msg.yahoo.com. (35)
10:35:32.485737 IP (tos 0x0, ttl 64, id 546, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 547
10:35:33.485583 IP (tos 0x0, ttl 64, id 547, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 548
10:35:33.528359 IP (tos 0x0, ttl 64, id 40153, offset 0, flags [DF], length:
71) 192.168.16.102.33273 > 213.21.141.2.domain: [udp sum ok] 44169+ PTR?
2.141.21.213.in-addr.arpa. (43)
10:35:34.485346 IP (tos 0x0, ttl 64, id 548, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 549
10:35:35.458228 IP (tos 0x0, ttl 64, id 42084, offset 0, flags [DF], length:
63) 192.168.16.102.33274 > 62.152.33.7.domain: [udp sum ok] 3026+ A?
scs.msg.yahoo.com. (35)
10:35:35.488084 IP (tos 0x0, ttl 64, id 549, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 550
10:35:36.487887 IP (tos 0x0, ttl 64, id 550, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 551
10:35:36.528975 IP (tos 0x0, ttl 64, id 43155, offset 0, flags [DF], length:
71) 192.168.16.102.33276 > 62.152.33.7.domain: [udp sum ok] 44169+ PTR?
2.141.21.213.in-addr.arpa. (43)
10:35:37.487691 IP (tos 0x0, ttl 64, id 551, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 552
10:35:38.487495 IP (tos 0x0, ttl 64, id 552, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 553
10:35:39.059661 IP (tos 0x0, ttl 64, id 45686, offset 0, flags [DF], length:
62) 192.168.16.102.33277 > 213.21.141.2.domain: [udp sum ok] 21200+ A?
wpop12.libero.it. (34)
10:35:39.487299 IP (tos 0x0, ttl 64, id 553, offset 0, flags [DF], length:
84) 192.168.16.102 > cairoO: icmp 64: echo request seq 554
10:35:39.676286 IP (tos 0x10, ttl 64, id 40, offset 0, flags [DF], length:
76) 192.168.9.15.ntp > 193.204.114.233.ntp: [udp sum ok] NTPv4 client, strat
11, poll 10, prec -20 dist 0.000000, disp 0.012420, ref
127.127.1.0 [at] 3309845704 (2004/11/19 10:35:04) orig
3309844711.892676999 (2004/11/19 10:18:31) rec +2.045191999 xmt
+1027.783578000

38 packets captured
216 packets received by filter
0 packets dropped by kernel

My local address is 192.168.9.15;
My "remote address" was 192.168.16.102.
As you may see NO PACKET return from vpn connection to my PC (and a ping
towards cairoO was running).
Here is my route during vpn connection:
[root [at] ap piero]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
217.169.119.1 192.168.9.2 255.255.255.255 UGH 0 0 0 eth0
192.168.9.0 * 255.255.255.0 U 0 0 0 eth0
default * 0.0.0.0 U 0 0 0 tun0

What is it going on?

Ciaoo
Piero

Alle 18:56, mercoled? 17 novembre 2004, Maurice Massar ha scritto:
> hi,
>
> On Wed, Nov 17, 2004 at 12:17:55PM +0100, Piero Ottuzzi wrote:
> > Hi again,
> >
> > really can't remember where but I read somewhere that vpnc (or
> > vpnc-connect) setup routing before the tunnel is really opened.
> > I noted that vpnc always opens a working connection in the first tryout
> > after a reboot but it not always opens a working connection afterward
> > (sometimes yes, sometimes not as per thread title).
> >
> > Is there a way to be absolutely sure that the tunnel is open?
> > Is there a way to know if the tunnel close for whatever reason?
>
> when vpnc returns, the "Config Script" is done, so the tunnel device
> is fully set up and routing should be in place (this should be done
> by the config script, vpnc-connect does that).
>
> I am relatively certain that the vpnc side is ready as soon as vpnc
> backgrounds itself.
>
> Maybe using tcpdump could verfiy this.
>
> cu
> maurice
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> http://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041119/cc888188/attachment.pgp

massar at unix-ag

Nov 19, 2004, 10:53 AM

Post #10 of 11 (753 views)
Permalink

Unreproducible connection result [In reply to]

hi,

On Fri, Nov 19, 2004 at 10:48:13AM +0100, Piero Ottuzzi wrote:
> Hi,
>
> sorry for stressing this point... but I would like to understand what is
> really happening....
[...]
> What is it going on?

the PIX is doing strange things, see:
http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2004-November/000324.html

cu
maurice

piero.ottuzzi at omnys

Nov 19, 2004, 12:15 PM

Post #11 of 11 (749 views)
Permalink

Unreproducible connection result [In reply to]

Hi Maurice,

as you may guess I would be very happy to beta-test possible solution to this
problem... I would give you a feedback in many minutes if you cantact me
during office time (9:30-13:00/14:00-18:30).

Keep up with your wonderful work!

Ciaoo
Piero

Alle 10:53, venerd? 19 novembre 2004, Maurice Massar ha scritto:
> hi,
>
> On Fri, Nov 19, 2004 at 10:48:13AM +0100, Piero Ottuzzi wrote:
> > Hi,
> >
> > sorry for stressing this point... but I would like to understand what is
> > really happening....
>
> [...]
>
> > What is it going on?
>
> the PIX is doing strange things, see:
> http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2004-November/000324.ht
>ml
>
> cu
> maurice
> _______________________________________________
> vpnc-devel mailing list
> vpnc-devel [at] unix-ag
> http://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
> http://www.unix-ag.uni-kl.de/~massar/vpnc/

--
'Stupid is as stupid does' - Forrest Gump

GPG KeyID: 84AE988E
Fingerprint: F0A0 CA2A 8D8F CC12 3F5E C04C D8D5 9DC3 84AE 988E
gpg --keyserver x-hkp://search.keyserver.net:11371 --recv-key 84AE988E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/attachments/20041119/18e93e4f/attachment.pgp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads