Three replies in one:
Bret Hughes wrote:
> Found it. Bug in script. needed to add fi at the end of the last if
> construct.
Confirmed. Thank you.
> message when forwarding is not on suggests to the user that he do the old echo
> "1" > ....../ip_forward deal. As this is deprecated in the RedHat 6.2 verison of
> the kernel a blurb about sysctl might be in order.
You're probably right. It'll be fixed in a future revision. I'm not
too worried about it yet, since it's not really a functional bug.
> I have not gotten all the way
> through it yet but that it what I have seen so far. I am not familier with the
> action statement. It is used extensively in the init.firewall script.
It's from Red Hat's init scripts. That's why I source
/etc/rc.d/init.d/functions at the beginning of the script. It
defininately won't work on non-RedHat boxes, but those running said
boxes can change action to "echo", and put the command executed on the
following line :)
> Last night I finished working from home and shut down my dialup link with
> ifdown ppp0. Being a dumb user, I did nothing with the vpn connection.
> This morning I noticed a lot of messages in one of my xterms:
The exit status of pppd was not being checked. The script has been
modified so that if pppd fails to bring up the link (as indicated by its
exit status), the scripts will exit and stop trying to bring up the
link. This changes the "persist" behavior to "persist as long as
everything is OK".
> ifdown vpn0
> killed the ppp1 interface used last night for the vpn as reported by
> ifconfig
It's strange that the link was still up. ssh should have detected the
fact that there was no route available to the remote host and exited.
pppd should have also timed out sending requests... Just weird.
> I then ssh'ed to the firewall where I noticed two ppp connections ppp0 and
> ppp1 (should have been only one)
Weird for the same reasons as above... The vpn-start script relies on
pppd to time out and quit. Perhaps ssh is causing pppd to block on a
write? It doesn't make any sense, but I haven't looked at pppd's code.
I'll have to test this further.
> client: check mail (netscape to internal mailserver) works well!
Cool.
> The order of my experience is very close if not dead on what I actually did
> and saw this morning. It looks to me like there need to be some mechanism
> to tie the vpn connection to a working network connection if it cannot
> recover from a dropped dialin.
Well, the client will no longer try to bring up an interface if
transport isn't available, so you won't get failure after failure.
However, closing active connections when the link is down is ssh's job.
why it's not working right, I don't know. I'll have to test this with
1.2.3 and 2.1.0. If I find anything of interest, I'll let you know.
> There are no messages in the server log
> relating to a problem over night with the ssh session. Should I have done
> something different in restarting the ppp connection?
Nope, sounds perfect for now.
> I noticed in my testing before I got it working that I got two ssh -q...
> sessions active at the same time on the client when the timeouts were
> occurring. Has the ssh session on the client dropped and is trying to
> restart it while the server to still thinks it is up?
Not exactly. The client was trying to persist, because it was told to
persist. It's behavior now should be more along the lines of what you
expect. I can't tell you yet what the server thought :)
> Hope this helps. I for one appreciate the work you have done and hope to
> use it often.
Thanks. I hope to use it more myself. I've used vtund in the past, but
this seems like a better solution by far.
> BTW the docs are ok But for the novice user (hell I can't claim novice, so
> maybe that should read non-guru user) some information on the ipchains
> rules necessary would be good.
Good idea. I'll get around to that at some point...
MSG
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
