[TriLUG] Dumb mgetty/pppd question

Jeremy Portzer jeremyp at pobox.com
Thu Oct 28 14:35:13 EDT 2004


On Thu, 2004-10-28 at 13:57, Brian Henning wrote:
> Hey Gang,
>   For my droid wanting outside access to the company financial files, I've 
> decided on direct dial-in access.  I figure that at least removes the 
> vulnerability of his unsecured machine becoming a big fat bridge between our 
> LAN and the internet at large.
>   So my dumb question is, presuming  I have mgetty and pppd correctly 
> configured, will his machine, once connected (using Windows DUN), behave as 
> if it were cabled directly into our network (albeit hideously slowly, of 
> course)?  He'll get an internal IP and be able to ping other internal hosts 
> just like he were in the building, right?  And thereby be able to map a 
> windows share across said link?

I could be wrong, but I don't think this will work "by default."  Your
pppd will be giving out an IP address and default gateway to the remote
client, who will then route its packets up the PPP "tunnel".  However,
these packets will then arrive at your server and not be able to go any
further.  They will not magically "transcend" the barrier between the
PPP interface and the ethernet LAN without help.

Here are two ways I can think of to set this up:

1 - Routing

Give the PPP interface on the server an IP address that's separate from
your LAN.  E.g., if the LAN is using 10.0.0.x, use 192.168.x.1 on the
server's PPP interface.  Configure pppd to give to the CLIENT a
different IP address on that same subnet, e.g. 192.168.x.2, and list the
"router" address of 192.168.x.1 as the client's default gateway.   
Then, enable routing on the server ("man sysctl" for how to do this).

Note: this will require the final application to work okay in a routed
environment.  If you are using WINS servers on the Windows network, and
you specify the WINS IP address on the client side, this shouldn't be a
problem (AFAIK). 

2 - Bridging

There are some nifty kernel modules that allow bridging.  This setup
would allow you to simply give out an IP address that's already on the
local LAN to the remote client, and not have to worry about routing
issues.  Then, the dialin server could automatically bridge the packets
from the ppp interface to the Ethernet interface.  At least, I think
this is possible; I haven't done it.  Hopefully someone else can chime
in.

Related to option 1, the vpn-over-ssh is a neat "poor man's VPN" that
you can set up on any two Linux boxes.  
http://www.tldp.org/HOWTO/ppp-ssh/ for more info.  It will teach you
some about basic routing  with PPP.

Hope this helps,
Jeremy

-- 
/---------------------------------------------------------------------\
| Jeremy Portzer        jeremyp at pobox.com      trilug.org/~jeremy     |
| GPG Fingerprint: 712D 77C7 AB2D 2130 989F  E135 6F9F F7BC CC1A 7B92 |
\---------------------------------------------------------------------/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20041028/7a59374f/attachment.pgp>


More information about the TriLUG mailing list