From: Craig Taverner (craig.taverner_at_comopt.com)
Date: Wed Nov 27 2002 - 10:15:01 CET
> > I'm interested in when a win2k/XP roadwarrior connects to one of my
main
> > office VPN machines (linux/freeswan), tunnels/route are
automatically
> > setup to all other offices so that the roadwarrior can access the
entire
> > WAN. I have some rather crude solutions to this, but I'd like to
know if
> > there is a neat and tidy way to do it.
>
> I don't envy your situation. You've come up with some excellent
answers,
> however. #2 is the best.
Thanks. I've been trying #3 (dummy ipsec tunnel ala dhcp-over-ipsec)
with no success, so I might have to go with #2 (ssh connections outside
ipsec). I forgot to mention one further idea (#4), and that was setting
up host-host tunnels only between the firewalls, and then using iproute2
facilities to make net-net tunnels through these (possibly GRE), and
continue to use iproute2 to create and terminate any appropriate
tunnels/routes as and when necessary. This option requires I learn a lot
more (I've just started playing with iproute2, and am not familiar
enough to really try this one on (yet)).
> I've got a crazy idea, however. Are Roadwarriors the only machines
going
> to
> connect to this first server? I wonder if there's a way to only
MASQUERADE
> packets, routed to the internal interface, which first came in from
your
> Roadwarriors? What I'm thinking is this: you could MASQUERADE them to
a
> ficticious IP, but one which you've already created static routes for
on
> the
> remote gateway's you are concerned about, leading back to your first
IPSEC
> server.
Fascinating idea. I think it might work, except for one definite
problem, and that is that the public roadwarriors are then not available
as SMB servers (ie. They cannot share their drives on the network). But
personally that is a feature I can live without anyway (especially since
most public roadwarriors are on modems, and SMB performs *very* badly
through IPsec/modem). However, a further problem might arise if SMB
cannot go through masquerading the normal direction (I'm not convinced
it can, so then the roadwarriors will not be able to access internal
shares either, something that is required). I've never tried SMB through
masquerading, does anyone know if the return packets are handled
correctly here (I'm guessing smb uses udp packets).
I'm using an updown script anyway because I use ipchains (on kernel
2.2.22), so adding this should not be too much of a problem.
> /sbin/iptables -t nat -A POSTROUTING -o eth1 --to-source 192.168.0.73
-s
> $PLUTO_PEER_CLIENT_NET -j SNAT
Nice. I've not started using iptables yet, but just comparing this line
with what I would have done with ipchains really shows how much more
powerful iptables is (at least appears to me).
/sbin/ipchains -A forward -s $PLUTO_PEER_CLIENT_NET -d 192.168.0.0/16 -j
MASQ
I cannot see a way to choose the private address in ipchains. All would
masquerade as the firewalls private ip address.
> Consider this brainstorming, and feel free to point out flaws if you
see
> 'em.
Definitely a worthwhile brainstorming session. I think some testing is
required to see if it actually works well enough to use in production,
and resolve the uncertainties around smb through masq.
Any I really think I need to move up to iptables. Problem is that all
firewalls are in production systems, and currently running the live
network. That level of upgrade has downtime consequences I'm not too
keen on :-(
Thanks for the response and ideas.
Cheers, Craig
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Thu Nov 28 2002 - 05:20:52 CET