Re: First PPP or first CIPE?!|
Peter van den Heuvel <peter,AT,asylum,DOT,xs4all,DOT,nl>|
Wed, 11 Jul 2001 17:28:22 +0200|
> > > + (i think the real problem) i've setup the network with the ippp0
> > > interfaces all the time up (isdnutils works in this manner), and also
> > > with cipcb5 interfaces all the time up, simply putting in
> > > ip-up-d/0cipe a ping to the remote end as documentation raccomand for
> > > dialup.
> > Is the perfect way to run it IF you have a static IP. Otherwise (dynamic
> > IP) I guess you have to do something if you (re)establish a connection
> > (like routes and addresses). Check the list archive for some more info
> > on dynaic IP's if that's what you got.
> Mmmh... i think i've not explained well my situation.
Somethimes that's just as hard as getting it to work ;^)
> I was used with ppp (plain analog modem ;), and in pppd world simply the
> link goes up&down.
> In ISDN (ipppd) instead, a ``fake link'' are ever up, listen for IP
> packets and bring up&down the (real) connection when needed.
> In this configuration, in ip-up scripts, there's only need to bring
> down the defaultroute and setup a new one (standard isdnutils setup).
As far as I know you can get both (pppd and ipppd) to behave in exactly
the same way. Once you have a static IP you would most likely prefer the
way you describe under ipppd.
What I did was NOT use ANY ip-up or ip-down scripts at all, be it cipe
or ipppd. I set up the ipppd with it's static IP, add the default route
to ippp0, set up cipe on top of ippp0, add the route for cipe; all from
my /etc/rc.d boot scripts (so not from the ip-up stuff). When I ping
some 10 range address on the other side of cipcb1 (for axample) then the
following things happen: make ICMP packet, routing table points to cipe
interface, encryption and construction of UDP packet, routing table
points to default interface ippp0, it's not up so it will dial out. For
this top work you need the routes in place BEFORE you perform the ping.
If you would set the routes from ip-up they would not be in place during
the ping and the packet would not know where to go. Your firewall rules
will be also quite helpfull to prevent unnecessary dial-out. Samba and
DNS are notorious. Some simple "OUTPUT" rules can stop that effectively.
> So i've also put cipe ever up, i don't bring up cipe interface in ip-up
> and down in ip-down. This simplify my routing and firewall rules.
> But clearly with this setup i cannot ``ping other end ASAP the
> interface bring up'', simply i ping other end ASAP the ippp0 interface
> got active. So in the ip-up script the firt thing i do is to setup
> defaultrouting, the other is to setup firewalling rules (relative to
> ippp0) and then to ping other end of the cipe interface.
You need the default route in place BEFORE you can do the ping.
Otherwise the UDP packet would not find it's way to the ippp0 interface.
You could also use a /sbin/route -n add -net official.remote.ip netmask
255.255.255.255 gw my.provider.net to allow you get to the remote part.
Once triggered you could add the default route in ipppd ip-up. That
would also prevent needless dial-out.
> Could be that if traffic to the remote private network goes out, this
> pass thru cipe interface, got converted to ``internet traffic'' that
> bring the ippp0 interface up. In this phase cipe send the initial
> packets of data to the old ippp0 address, then this changed and this
> (could?!) make the all thing (sometime) bad...
That would only be possible if you had dynamic IP. The archive should
have a lot of material about that. CIPE can work quite well with a
dynamic IP from one end, if I remember correctly. The documentation
should explain which config fields should be kept empty.
> I say this because i've the feeling that if some local computer make
> internet traffic, all goes OK because the first traffic passes to cipe
> interface are the ping in ip-up scripts.
There is no need to explicitly ping from the ip-up scripts.
> Instead if the traffic are destined to the private network, cipe start
> the connection but get confused.
> I repeat: i've the ``feeling'' of that. It is hard to debug!!! ;-)
Try to use the firewall there. I often stick some log rules in and do
some test. Then I know better where my packets are going, without the
need for tcpdump.
> ...excuse for my english, i hope i'm more clear now.
Hope this is more help...