[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using gre(4), gif(4) ontop of ipsec(4) and other ISAKMPd scalability issues.
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Using gre(4), gif(4) ontop of ipsec(4) and other ISAKMPd scalability issues.
- From: "Brian A. Seklecki" <lavalamp_(_at_)_spiritual-machines_(_dot_)_org>
- Date: 31 Jul 2003 22:18:27 -0400
I'm interested in personal accounts on the use of gre(4) and gif(4)
tunnels between IPSec encrypted nodes and networks on an enterprise
>From scouring mailing list archives, most people assume that ipsec(4)
includes an actually "tunnel" interface for making physically &
logically dis-contiguous network appear connected (perhaps "tunnel" v.s.
"transport" mode confuses them, or too much time using L2TP or PPtP),
however that is not the case.
Are there any other recommended mechanisms for accomplishing this?
I'm interested in in-production implementations of this configuration,
specifically as to how well it scales over time. I find it works well
between several different "client" hosts running IPSec implementations
compatible with OpenBSD; however over time, I foresee a lot of
scalability problems in an enterprise class network configuration,
especially a lot of administrative overhead.
Point-to-point links are straight forward. I'm curious about more
For example, if 10.0.0.0/8 is your organization's CIDR/RFC 1918 reserved
IP space, each "client" node needs to be manually configured to route
traffic destined for that subnet across the gif(4) or gre(4) interface
using a static route. If the client is a workstation on a dialup or
other 3rd part connection, a simple route(8) command will address this.
Additionally, if the "client" is a "leaf" or "branch" office network,
the VPN "server" will need additional static routes for the larger
subnets (say, a /24 or /25 at each branch office) at that remote end
(other than /30s that are known directly connected via gif(4) or gre(4)
interfaces). Additional identical static routes would be needed at the
"central" site's network gear facing the central "server" so that the
routes will propogate rest of the organization's gear.
On the branch side, the OpenBSD box terminating the VPN might be a WAN
router itself, or it may be another box on the ethernet segment with a
public IP. In the former situation, a manual route configuration could
become tricky. In the latter, the WAN router for the branch office will
need configured to route 10.0.0.0/8 to the private IP of a dual-homed
OpenBSD VPN box.
These might sound like typical network design considerations, but at
some point, manual static route configuration will inevitably lead to
overwhelming and sometimes erroneous maintenance. So I guess the issue
becomes: in order to scale well and avoid that administrative overhead,
at some point the OpenBSD VPN "server" or "concentrator" will need to
participate in a routing protocol such a OSPF to manage routes for all
that private IP address space it's advertising via tunnels.
Has anyone implemented routed(8) or Zebra in this fashion? I'm curious
about any other possibilities?
It seems overwhelmingly obvious to me that the VPN concentrator on a
network should be a physically independent of the device acting as a WAN
router, as well as the any box acting as a Firewall/NAT gateway. If for
no other reason than security redundancy, then for ease of maintenance
and configuration. However a lot of commercial "appliances" don't seem
to have any trouble acting as all four devices on smaller networks.
I'm looking for some opinions and personal accounts on integrating these
services onto one machine, especially hardware requirement
Also, as for phase-1 authentication, pre-shared secret keys doesn't seem
to scale well above and beyond simple point-to-point configurations, but
at $100 -> $300 per x.509 certificate from most commercial vendors, and
ungodly pricing on commercial CA inter-organization server software,
that seems to defeat the budgetary purpose of running an OpenBSD
solution. An OpenSSL based "in-house" CA seems to be the best
alternative to me: have a separate single-function server that acts only
as a CA and is guarded very closely (a 486 could do this). Have it act
as a CA for all the devices in the organization.
Once again, some commercial appliances run proprietary CA/PKI management
protocols (SCEP) that simplify the enrollment / cert request procedure,
but for the most part, scp(1)'ing an organization's central CA public
cert to /etc/isakmpd/ca doesn't seem too overwhelming to me (as well as
scp(1)'ing a new device's cert request to the afore mentioned central CA
server for signing).
I do see one X.509 CA software package: http://www.pyca.de/ ... but
that's just a python script to help ease management. Has anyone come up
with any other solutions or found any OpenBSD clients that are
compatible with commercial SCEP protocols (Verisign OnSite, Entrust,
And finally, Net-Policy is an Net-SNMP (ucd-snmp) based package for
managing lewwwwnux IPSec via SNMP. I'm not so interested in *managing*
VPNs via SNMP, but *monitoring* SAs and SADs (i.e., an agent that sends
a trap if a SA goes away *or* if ISAKMPD fails to re-negotiate a SA
after the lifetime expires) would be very useful. Has anyone gotten
UCD-SNMP hacked up for anything like this?
NOTE: When replying to a mailing list post, please be sure to reply to
the /list/ and cc: or bcc: myself as I am unable to promise a timely
Visit your host, monkey.org