A question about default routes.
Jimmy Phillips
and really like it. The distro is very complete so that real work can be
done, but since it is really debian underneath it is a good learning
platform also.
I have a dial up for internet access and also a small local intranet. On
this installation, when I first tried to set up the serial connection, it
would dial out and connect but I could never access any internet sites
unless I disabled the ethernet card.
Lots of hacking and research later, I found that the command
"route del default eth0"
would fix the problem for that poweron session and allow both connections
to work.
To workaround the problem, I just made a script with the above command and
put it into the proper runlevel folder.
I have a feeling that this fix is a real hokeum kludge and that there is
another and proper way to handle it. So far I don't have a real good
understanding about routing so haven't found the "proper" way yet.
Any insights anybody.
Thanks all
Jim Phillips
Unruh
>"route del default eth0"
While a bit of a kludge it is precisely the correct way of doing it.
Alternatively you can set up your internal ethernet not to have a default
route at all when it comes up (on a Redhat/Mandrake, remove the GATEWAY=
line in /etc/sysconfig/network, but I have no idea what the procedure is in
Debbian.)
The problem is that ppp refuses to replace a default route if one is
already set up. You do not need a default route for your internal Lan-- it
only has a vary small number of net numbers/subnets.
So
a) Do not have a default route on your eth0 at all
b) remove it before you run ppp
are your two options.
Lew Pitcher
Hash: SHA1
Jimmy Phillips wrote:
[snip]
> I have a dial up for internet access and also a small local intranet. On
> this installation, when I first tried to set up the serial connection, it
> would dial out and connect but I could never access any internet sites
> unless I disabled the ethernet card.
>
> Lots of hacking and research later, I found that the command
>
> "route del default eth0"
>
> would fix the problem for that poweron session and allow both connections
> to work.
[snip]
> I have a feeling that this fix is a real hokeum kludge
[snip]
> Any insights anybody.
If you think about what a "default route" means, then the solution is a
bit simpler.
A "default route" is used when your IP stack doesn't know how to get a
packet to it's destination. Your IP stack effectively asks the router at
the "default route" to forward the packet.
Your intranet consists of addresses known to you. Your IP stack should
be able to figure out exactly how to get a packet to any one of the
nodes on your intranet. You can ensure this by entering explicit "route"
commands that instruct your IP stack exactly where to send packets for
your intranet. For your intranet, you do not need a "default route"
because you already have well-known, pre-established fixed routes for
all the nodes on it.
The Internet, however, consists of address that are not known to you.
You would have a hard time entering explicit routing instructions for
every Internet IP address. For the Internet, you probably need a
"default route" because you don't have foreknowledge of the routes to
each and every node.
So, here's what you can do...
1) remove your existing static "default route" from your configuration
2) place explicit route commands into your configuration for all the
nodes on your intranet
3) permit PPP (assuming you literally meant 'dial out') to set the
default route when you connect to the Internet Both PPPoE (for ADSL)
and DHCP (for Cable) do this as well)
HTH
- --
Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFCcoMLagVFX4UWr64RAgHPAJ0c9dy/0E1Xg1gwv8JJuqghazvF0ACg7USE
ubthR2n+A07dTeSfeeN/BUk=
=3Knq
-----END PGP SIGNATURE-----
John Hasler
> I have a dial up for internet access and also a small local intranet. On
> this installation, when I first tried to set up the serial connection, it
> would dial out and connect but I could never access any internet sites
> unless I disabled the ethernet card.
Edit /etc/network/interfaces. Comment out the gateway line.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Walter Mautner
....
> I have a dial up for internet access and also a small local intranet. On
> this installation, when I first tried to set up the serial connection, it
> would dial out and connect but I could never access any internet sites
> unless I disabled the ethernet card.
>
to a ppp modem connection. The installer didn't know how to connect to the
internet at this time, and the modem link wasn't yet up.
> Lots of hacking and research later, I found that the command
>
> "route del default eth0"
>
> would fix the problem for that poweron session and allow both connections
> to work.
>
will take when no other connection available for them) to the ppp modem
connection.
> To workaround the problem, I just made a script with the above command and
> put it into the proper runlevel folder.
>
That's fine. Maybe when you use the pppd dialler in knoppix, it also should
do other stuff like putting the dhcp-obtained nameserver addresses
into /etc/resolv.conf, as well as set the default gateway to the ppp
connection. But when you are not using the prepared links and scripts, you
are on your own. That's perfectly fine, as you get the best learning
experience out of it :).
> I have a feeling that this fix is a real hokeum kludge and that there is
> another and proper way to handle it. So far I don't have a real good
> understanding about routing so haven't found the "proper" way yet.
>
Each distribution has some slightly different way to handle dynamic
connections. Don't worry, make it work for you.
--
Longhorn error#4711: TCPA / NGSCP VIOLATION: Microsoft optical mouse
detected penguin patterns on mousepad. Partition scan in progress
to remove offending incompatible products. Reactivate MS software.
Linux woodpecker.homnet.at 2.6.11-mm4[LinuxCounter#295241,ICQ#4918962]
Jimmy Phillips
Great! Thanks to all for the information and tutorials.
Jim Phillips
Jimmy Phillips
> Jimmy Phillips writes:
>> I have a dial up for internet access and also a small local intranet.
>> On this installation, when I first tried to set up the serial
>> connection, it would dial out and connect but I could never access any
>> internet sites unless I disabled the ethernet card.
>
> Edit /etc/network/interfaces. Comment out the gateway line.
Ah so. A VERY simple fix! Now I just have to figure out why.
Thanks
JP
John Hasler
> Edit /etc/network/interfaces. Comment out the gateway line.
JP writes:
> Ah so. A VERY simple fix! Now I just have to figure out why.
Because the Debian installer assumes that it you have a LAN it must be how
you reach the Net.
Moe Trin
>Because the Debian installer assumes that it you have a LAN it must be how
>you reach the Net.
I've got to ask. Why?
There has always been a significant number of people trapped this way,
especially when ppp-2.3.6 started barfing if a pre-existing default route
existed (the error message was improved in 2.3.11). I complained to Donnie
Barnes in 1995 about Red Hat's "helpful" installer that asked for a host
IP and netmask, then filled in the primary DNS address as $NETWORK+1, and
the default gateway as $BROADCAST-1, then asked the (often very bewildered)
person doing the install if this was OK. In many cases, the poor sod had
only the faintest idea what these might mean, and very few (even experienced)
people knew the impact of just clicking <OK>. An example is the kernel's
behaviour when there are two routes to the same destination (without today's
advanced routing capability) - which will be used? The dead-tree manual did
mention that the user had a chance to review the data before committing to
the, but assumed (there's that word again) that the person knew what they
were doing. The response I got from both Donnie and Erik was that the user
was offered the choice to say no. I also asked why $NETWORK+1 was chosen as
the primary name server (it certainly wasn't on redhat.com, or any network
I'd worked on), but that's another ball of tar.
Possibly this problem occurs because of microsoft's use of the 'gateway'
term to refer to an interface. The Linux install program should ask for
the IP address of the host that will be forwarding packets to the Internet,
and then checking to see if the answer is one of it's own addresses (in
which case it should ignore the input). The person should be cautioned that
if there is no route to the Internet, this entry should be left blank.
Old guy
John Hasler
>Because the Debian installer assumes that it you have a LAN it must be how
>you reach the Net.
Moe Trin writes:
> I've got to ask. Why?
My guess is that it's because the people who write the installer all work
at large institutions where that is always true and don't think about the
two machine home network on a dialup.
> The Linux install program should ask for the IP address of the host that
> will be forwarding packets to the Internet...
I think the questions need to be at a higher level than that. I'm not part
of the installer team, though.
I may try to think of a way to fix this up in pppconfig.
Moe Trin
>My guess is that it's because the people who write the installer all work
>at large institutions where that is always true and don't think about the
>two machine home network on a dialup.
I'm surprised they haven't heard complaints and bug reports about it.
>> The Linux install program should ask for the IP address of the host that
>> will be forwarding packets to the Internet...
>
>I think the questions need to be at a higher level than that.
The reason I put it that way is to get around the use of the word 'gateway'.
Virtually every installation program I've seen seems to assume that if the
person says that they have a gateway (but not saying where it might lead),
then it _must_ be the default that leads to the internet. Some people (who
should probably know better) use a default route rather than specific
network routes when they have more than one local subnet.
>I'm not part of the installer team, though.
Understood
>I may try to think of a way to fix this up in pppconfig.
I'd certainly have it look to see if there is an existing default, and if
so ask if that default does lead to the world. If it does, the user should
be asked what network the ppp link leads to, and use that information to
create a 'route add' in /etc/ppp/ip-up, and a 'route del' in
/etc/ppp/ip-down. If that's the case, I'd also look at the contents of
/proc/sys/net/ipv4/ip_forward to make sure forwarding is not on - that's
a huge security hole in the making.
I think SuSE, or one of the desktop "helper" applications has added a
'replacedefaultroute' option which then includes 'noauth' and does some
secret hand waving to replace the existing default. While it's better
than nothing, it's still a security mis-feature. At a previous jobsite,
we had an employee dialing in while connected to a broadband. They got
cracked from the broadband, and some kiddie was using that to explore the
company net, tripping alarms while trying to improve his access. Security
was not at all pleased.
Old guy
Unruh
>In article <871x8q9...@toncho.dhh.gt.org>, John Hasler wrote:
>>My guess is that it's because the people who write the installer all work
>>at large institutions where that is always true and don't think about the
>>two machine home network on a dialup.
>I'm surprised they haven't heard complaints and bug reports about it.
>>> The Linux install program should ask for the IP address of the host that
>>> will be forwarding packets to the Internet...
>>
>>I think the questions need to be at a higher level than that.
>The reason I put it that way is to get around the use of the word 'gateway'.
>Virtually every installation program I've seen seems to assume that if the
>person says that they have a gateway (but not saying where it might lead),
>then it _must_ be the default that leads to the internet. Some people (who
>should probably know better) use a default route rather than specific
>network routes when they have more than one local subnet.
>>I'm not part of the installer team, though.
>Understood
>>I may try to think of a way to fix this up in pppconfig.
>I'd certainly have it look to see if there is an existing default, and if
>so ask if that default does lead to the world. If it does, the user should
You can put
route del default
route add default gw $5
into /etc/ppp/ip-up
Unruh
>I'd certainly have it look to see if there is an existing default, and if
>so ask if that default does lead to the world. If it does, the user should
>be asked what network the ppp link leads to, and use that information to
>create a 'route add' in /etc/ppp/ip-up, and a 'route del' in
>/etc/ppp/ip-down. If that's the case, I'd also look at the contents of
>/proc/sys/net/ipv4/ip_forward to make sure forwarding is not on - that's
>a huge security hole in the making.
Why? I assume that you let in only authorised people on the ppp link.
>I think SuSE, or one of the desktop "helper" applications has added a
>'replacedefaultroute' option which then includes 'noauth' and does some
>secret hand waving to replace the existing default. While it's better
>than nothing, it's still a security mis-feature. At a previous jobsite,
>we had an employee dialing in while connected to a broadband. They got
Well, yes, the problem of people connecting to two nets is a problem. In
fact I am astonished at how lax the security is even coming into highly
secure places. With Windows machine highly probably cracked letting any
such system onto a security sensitive system is almost criminal.
Tony Lawrence
> Well, yes, the problem of people connecting to two nets is a problem. In
> fact I am astonished at how lax the security is even coming into highly
> secure places. With Windows machine highly probably cracked letting any
> such system onto a security sensitive system is almost criminal.
Two things that surprise me are vpn's to home machines and vpn's to
"business partners". Both of these situations are often treated with
extraordinary carelessness as to the security on the machines at the
other end.
I know of one case where a distributor had their dealers connect by a
vpn to check stock. When I first learned of it I asked why aren't the
dealers just using a hppts connection but got no good answer. It seemed
like an awful idea to me, and sure enough, the distributor shortly
passed on some nasty viruses right to the dealer networks - or maybe
some dealer's network started it; it doesn't matter: it was the vpns
that gave the path for the problem to spread.
And of course allowing arbitrary home machines vpn connections is just
jaw-dropping, but it happens every day. Another thing I regularly see
is Windows 3389 port forwarding to desktop machines with "bob/bob123"
logins - now gosh, nobody will ever get control of that, will they?
Sure, any connection has some risk to it, but exposing networks is just
leaving yourself wide open.
--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Moe Trin
>ibup...@painkiller.example.tld (Moe Trin) writes:
>
>>I'd certainly have it look to see if there is an existing default, and if
>>so ask if that default does lead to the world. If it does, the user should
>>be asked what network the ppp link leads to, and use that information to
>>create a 'route add' in /etc/ppp/ip-up, and a 'route del' in
>>/etc/ppp/ip-down. If that's the case, I'd also look at the contents of
>>/proc/sys/net/ipv4/ip_forward to make sure forwarding is not on - that's
>>a huge security hole in the making.
>
>Why? I assume that you let in only authorised people on the ppp link.
The authorized person is the one who's dialing in. But a ppp link that
has been set up doesn't check credentials on the packets that are going
over the wire. If a company allows access to their internal net from
authenticated users, it's quite unusual for them to exercise the same
amount of security as the firewall protecting the front door.
>Well, yes, the problem of people connecting to two nets is a problem.
With the introduction of ppp-2.3.0 back in 1997 or so, root could set up
a few options so that the link was somewhat harder to exploit, but it wasn't
until 2.3.6 in early 1999 that the trap for an existing default route was
put in, and I'm sure you remember the wailing and gnashing of teeth when
that happened. However, this really only applies to ANU ppp, and it's
not the only implementation out there.
>In fact I am astonished at how lax the security is even coming into
>highly secure places.
I have to agree with this. In most secure operations, such as government,
military contractors, and so on, there are lots of rules that specify
security requirements that _will_ be met. Real life is often quite
different until something happens, and a bunch of people have the
flaming torch of retribution shoved up their whatever. (Below)
>With Windows machine highly probably cracked letting any such system
>onto a security sensitive system is almost criminal.
Preacher - meet choir.
>>cracked from the broadband, and some kiddie was using that to explore the
>>company net, tripping alarms while trying to improve his access. Security
>>was not at all pleased.
That was one example - yes, it was a windoze box, and at the other end of
the dialin was a military contractor who'd just had a COR that had read the
Riot Act (ALLLLL the way through) to staff and executives over a security
problem he'd noticed. In case you haven't been on the receiving end of such
a reaming, I'm here to tell you that it is NOT pleasant, and may be a major
disaster for your personal career. I'm told that the secret stuff (so stamped
in bright red letters an inch high on the top and bottom of everything down
to and including the toilet paper) was behind a series of locked and guarded
gates, and the networks were isolated by a physical gap of several tens of
feet. None the less, there was hell to pay, and I know one person saw jail
time, and maybe ten others got fired.
Old guy
Moe Trin
>Two things that surprise me are vpn's to home machines and vpn's to
>"business partners". Both of these situations are often treated with
>extraordinary carelessness as to the security on the machines at the
>other end.
This is sorta drifting into the security field, but yeah, it happens all
to often unless management has seen the light and put the necessary
policies in place. I'm at an R&D facility, and they put 'division' level
rules in place more than twelve years ago. Corporate joined the band
wagon about ten years ago. There's no privately own computers doing
company work, and the comparatively few doing company work at home do
so on company computers that can only be connected to the company net.
No floppy, no NIC, no CD, and the case is sealed to slow down the kids.
No connection to other computers in the home - and only the employee is
supposed to be using it. That's why I have two computers on the desk
at home. The same rules also prohibit ANY computer going in/out the
facility without lottsa paperwork.
>I know of one case where a distributor had their dealers connect by a
>vpn to check stock. When I first learned of it I asked why aren't the
>dealers just using a hppts connection but got no good answer.
Yeah, we know about _that_ little problem. Everything here goes through
a firewall, even to corporate or other divisions. Everything else gets
their computing/connection needs handled by systems in the DMZ.
>And of course allowing arbitrary home machines vpn connections is just
>jaw-dropping, but it happens every day. Another thing I regularly see
>is Windows 3389 port forwarding to desktop machines with "bob/bob123"
>logins - now gosh, nobody will ever get control of that, will they?
Hey, at least it _has_ a password. I've seen worse at my wife's company.
We don't allow tunnels. You log in to a server outside the firewall,
that allows you to connect to some internal hosts. It's a PITA, but
is less risky. I don't know about the rest of the company, but we
know the IP blocks of virtually all local providers, and OUTBOUND
connections to those blocks are severely restricted. Inbound direct?
Forget it.
>Sure, any connection has some risk to it, but exposing networks is just
>leaving yourself wide open.
Depends on how enlightened the management is, and how paranoid the staff.
Connections from the outside (other than employees noted above) get to
the DMZ. The hosts there can't initiate connections in to the company OR
out to the world. Need to put a file out onto one of the public servers,
or retrieve a file that has been uploaded from outside? Fine - initiate
the connection from a few designated system inside.
Old guy
John Hasler
> I think SuSE, or one of the desktop "helper" applications has added a
> 'replacedefaultroute' option which then includes 'noauth' and does some
> secret hand waving to replace the existing default.
Replacedefaultroute is a standard pppd option. I see nothing about noauth,
though.
John Hasler
> You can put
> route del default
> route add default gw $5
> into /etc/ppp/ip-up
That will rip out the user's default route and not replace it when the link
goes down. I'd have to save the default route and fix it in a ip-down.d
script. Better to use replacedefaultroute.
Moe Trin
>Moe Trin writes:
>> I think SuSE, or one of the desktop "helper" applications has added a
>> 'replacedefaultroute' option which then includes 'noauth' and does some
>> secret hand waving to replace the existing default.
>
>Replacedefaultroute is a standard pppd option.
[compton ~]$ zgrep -i 'replacedefault' /net/hubble/new/ppp-2.4.3.tar.gz
[compton ~]$ zgrep -i 'replacedefault' /net/hubble/new/ppp-2.4.2.tar.gz
[compton ~]$ zgrep -i 'replacedefault' /net/hubble/new/ppp-2.4.1.tar.gz
[compton ~]$ zgrep -i 'replacedefault' /net/hubble/new/ppp-2.4.0.tar.gz
[compton ~]$ zgrep -i 'replacedefault' /net/hubble/new/ppp-2.3.11.tar.gz
[compton ~]$
I beg your pardon!!! I think you may want to check your ppp source. These
are the tarballs from ftp.samba.org/pub/ppp/.
-rw-r--r-- 1 ftpadm ftpadm 795942 Aug 5 2000 ppp-2.3.11.tar.gz
-rw-r--r-- 1 ftpadm ftpadm 546883 Aug 7 2000 ppp-2.4.0.tar.gz
-rw-r--r-- 1 ftpadm ftpadm 536746 Mar 25 2001 ppp-2.4.1.tar.gz
-rw-r--r-- 1 ftpadm ftpadm 774441 Jan 16 2004 ppp-2.4.2.tar.gz
-rw-r--r-- 1 ftpadm ftpadm 688092 Nov 14 10:49 ppp-2.4.3.tar.gz
and those are current dates and files - checked a few minutes ago.
>I see nothing about noauth,
The only time I've seen the 'replacedefaultroute' option mentioned, I'm
fairly sure it included a 'noauth' option as well, to get around pppd asking
the peer to authenticate.
Old guy
Moe Trin
>Bill Unruh writes:
>
>> You can put
>> route del default
>> route add default gw $5
>> into /etc/ppp/ip-up
>
>That will rip out the user's default route and not replace it when the link
>goes down. I'd have to save the default route and fix it in a ip-down.d
>script.
It also requires the noauth option to stop pppd from demanding authentication
because of the extra route, and doesn't stop the pppd daemon from complaining
about not replacing the existing default route.
>Better to use replacedefaultroute.
Which as noted upthread is not a standard option. Did Debain add this in
their implementation? If so, you'd better ask the Debian maintainer why he
decided to add this "feature".
The real solution is to correct the problem by removing the bogus default
route - not by ignoring the problem by masking the symptom.
Old guy