Nils Lichtenfeld wrote:
> Ok, thats impressive.... So is 192.168.64.128 at the same time your ethx
>IP? Or would that be a bad idea?
In the particular case above this is a VPN hub on bonded T's, and there
is no internal interface.
However several of the machines that are spokes do just exactly that,
they use the same IP on the internal eth as the tunnel. In fact they ALL
do just exactly that.
And they are in a rather large VPN web, in particular the 25.128 machine
connects to 12 boxes via CIPE 4 of which overlap this box.
I wrote a "poor mans gated" type program, that sweeps and reads the
route table looking for point-to-point links and sets up routes based on
what it can and can't see. For example from this machine:
# DESTINATION GATEWAY MASK UNLESS FLAGS
#-------------- --------------- --------------- --------------- -----
# oops - This is the cable modem ...
192.168.100.0 192.168.64.1 255.255.255.0 * net
# mail.ksmith.com may as well be direct
22.214.171.124 192.168.64.1 255.255.255.255 * net
# casafiesta is the tunnel target
126.96.36.199 192.168.64.1 255.255.255.255 * net
192.168.4.0 192.168.4.1 255.255.255.0
# VPN to Pittsgrove
192.168.7.0 192.168.7.1 255.255.255.0
192.168.9.0 192.168.9.128 255.255.255.0
192.168.42.0 192.168.42.1 255.255.255.0
192.168.43.0 192.168.43.1 255.255.255.0
# VPN to Ksmith
192.168.0.0 192.168.64.128 255.255.0.0
188.8.131.52 192.168.64.128 255.255.254.0
# b0201 / Terminix-Triad 24.0-31.255
192.168.24.0 192.168.25.128 255.255.248.0
192.168.32.0 192.168.25.128 255.255.248.0
Note that 192.168.0.0/16 is routed to .64.128 but there are other more
specific routes that can come up. In the event say my .4.1 tunnel here
went down the packet would get sent via .64.128.
Unfortunately, ... this appears to be a bit of a problem with CIPE,
because the interface shows up whether you are talking or not. With
ppptcp the underlying daemon would lose connectivity and the interface
would shut down (ie pppd was killed), and would stay down until the two
machines could talk again when the ppptcp code would again fire up the
interface. With CIPE the interface is up as long as the ciped daemon is
This is not good.
I wish it were not true, but I can't tell you how many times I haven't
been able to get from here to say the .4.1 hosts real address direct but
I'll be darned if I can't bounce it off of 64.128 and have it arrive no
problem. (Albeit with a bit more latency :)
I'm thinking in terms of wrappering ciped in a perl script, that
monitors the host links, and then killing the ciped daemon when I can't
get a ping across, or something along those lines.
I hate hacking code like this, but ideally ciped-cb would not bring the
interface up unless the link was actually working. If I get REALLY
motivated I may do a source hack for this, but the last time I fixed an
SCO tty ioctl problem under iBCS I posted a patch and pissed off the
maintainer, who then refused to acknowledge it was a problem. To this
day iBCS is broken if you run a terminal on a serial line over 38.4K.
Dunno about abi.
> to go through network B... Would not a triagle be better?
Teach your mailer to wrap, keep your stuff within 80 columns, and that
will work alot better for visibility. Outlook sucks unless the other
guy is using outlook too. I actually often use a text terminal or
console window for mail. You should look at your messages on one
sometime with 'mail' or another 'simple' client. Your diagram was WAY
over to the right, the sentence prior to the quoted line ended at column
131. That way what YOU see is what I'LL get :)! But I digress...
Yes, as in the above example. I duplicate many of the same tunnels as
64.128, so we all talk to each other. The idea is to set up a web of
VPN'd machines that talk to each other. Unfortunately now, I'm having
problems with the route redundancy aspect.
Setting up metrics may also be a viable alternative, but my experience
is that is slows things down tremendously, and complicates the crap out
of maintaining it. After all the interface is *UP* even if it can't
send any packets. I'm not sure that would even work.
Keith Smith keith,AT,ksmith,DOT,com
655 W Fremont Dr
Tempe AZ 85282 it's hot