"Mark Maas" <[EMAIL PROTECTED]> writes:
>
> Situation:
Okay, your diagram got a little botched up on this end, but you've got
a gateway interconnecting the three private LANs, and you've got a
Debian box---the only connection to the outside world---with eth0 on
the 192.168.8 net and the rest of the Internet on eth1 with a single
(static) IP address 217.149.34.117.
How do the other hosts on the private LANs (besides the Debian box)
access the Internet? Or do they?
> Id like to give my road warriors access to the three Lan's
[ . . . ]
> Sometimes though they also need to acces, ftp site, and website's
> while also on the lan.
It's not difficult to configure the Debian box to do source NATting
for road warriors (or anybody else). Assuming the kernel is
iptables-ready, it's enough to do:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
If your default forwarding policy allows all packets through, this
rule means that any host that manages to get a packet to the Debian
box that's destined for someplace besides your three private LANs will
have the Debian box do source NATting on its behalf.
(Note that this will work nicely for web traffic. FTP traffic
requires that the "ip_nat_ftp" kernel module be loaded to correctly
handle the data connection. Other forms of traffic may require other
modules.)
In practice, this means that the road warriors' Windows
machines---which, if the "Use Default Gateway on Remote Network"
checkbox is on, will create a default route to the Debian box when the
PPTP connection is established---will route *all* their traffic to the
Debian box. Traffic destined for the private LANs will be routed
through "eth0", and traffic destined for the Internet-at-large will go
out the "eth1" interface where it will be automagically masqueraded
(source NATted) by the rule above.
It also means that *any* host on the 192.168.8.x net that uses your
Debian box as a default route will have access to the Internet through
the Debian box's source NATting. If the private gateway is configured
to know about the Debian box's route to the Internet (either manually
or because the Debian box is broadcasting it somehow), then all the
hosts on all the private LANs will have Internet access by means of
the above rule.
There are security issues here, of course, and security issues that
arise just by virtue of connecting a Debian box between your private
LANs and the Internet. For example, if the Debian box has forwarding
enabled (as it presumably does right now) and isn't doing any packet
filtering, an attacker might be able to use IP source routing to get a
packet destined for 10.1.0.5, say, delivered to your Debian box (which
will happily deliver it to the appropriate host on the "private" LAN).
Your ISP might filter out source-routed packets at its perimeter (as
mine does), but then again it might not. And, you may not want every
host on the private LANs to have unrestricted Internet access; maybe
only road warriors are supposed to see the Internet. For this, you
might want an "/etc/ppp/ip-up.d/*" script that adds a tailored rule:
iptables -t nat -A POSTROUTING -i $PPP_IFACE -o eth1 -j MASQUERADE
that *only* masquerades for packets coming in from the newly added
road warrior's interface, and a matching command in "ip-down.d/*" to
remove the rule when the road warrior disconnects.
An alternate solution to the whole business is to configure the road
warriors' Windows PPTP clients so they only route traffic for the
three LANs through the PPTP tunnel and route other Internet traffic
normally. If you uncheck that "Use Default Gateway on Remote Network"
setting in the PPTP client configuration, I believe the client
machines will route traffic for 192.168.8.x through the PPTP tunnel
and all other traffic normally. This would give your road warriors
access directly to the whole Internet but to only one of the three
private LANs, but you could run a batch file on the Windows machines
to add manual routes for the other two LANs, or you could broadcast
routing information to the Windows machines. I'm not sure if they
listen to, say, RIP packets by default or not. Anyway, this setup
comes with its own set of security issues.
I'd need to understand the overall security policy at your site to
give you better advice. Normally, you'd want to configure a firewall
on the Debian machine to better protect the internal machines, and the
appropriate rule to do source NATting for road warriors or other
machines would have to be tailored to integrate with the overall
security policy you're trying to implement.
> You don't happen to know how to get mppe encryption working do you? I
> installed the kernel-patch-mppe but the howto's and manuals tell me I have
> to compile the kernel. Any doc's on that?
I've gotten MPPE working for the PPTP client, but I compile my kernels
the old-fashioned way, not using the Debian-sanctioned
"kernel-package" way. I assume it's relatively straightforward: once
the "kernel-patch-mppe" package is installed, install the appropriate
"kernel-source-*" package and the "kernel-package" package, and follow
the latter's instructions to recompile a patched kernel and create
Debian "kernel-image-*" and "kernel-headers-*" packages. Then,
install those, and you've got an MPPE-patched kernel. To make any
real use of this, though, you also need an MPPE-patched PPP daemon.
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
