OpenVPN works fairly well with OpenVPN. The one caveat being that OpenBSD does not have PAM support... making secondary authentication, using a user account, more complicated. It is possible to install /usr/ports/net/openvpn_bsdauth to use local user accounts, but what if you want a group certificate with authentication against a Windows Active Directory installation?
Since AD does have Kerberos support, it is possible.
1. Install OpenVPN from ports
2. Install the p5-Authen-Krb5-Simple perl module from ports (/usr/ports/security/p5-Authen-Krb5-Simple)
3. Add a script like so:
/etc/openvpn/krb5-auth.pl
#!/usr/bin/perl
use strict;
use Authen::Krb5::Simple;
# change the next variable to 1 to log errors to /tmp/autherror.txt
my $debug = 0;
my $user = $ENV{'username'};
my $pass = $ENV{'password'};
chomp ($user, $pass);
my $krb = Authen::Krb5::Simple->new([realm => 'YOURREALM.LOCAL']);
# Authenticate a user.
#
my $authen = $krb->authenticate($user, $pass);
unless($authen) {
my $errmsg = $krb->errstr();
if ($debug == 1) {
open ASD, ">/tmp/autherror.xt";
print ASD "User: $user authentication failed: $errmsg\n";
close ASD;
}
die "User: $user authentication failed: $errmsg\n";
}
Your script can be more complex than this, but this should work.
4. Add the following line to your client config:
auth-user-pass
5. Add the following lines to your server config:
auth-user-pass-verify /etc/openvpn/krb5-auth.pl via-env
6. create /etc/kerberosV/krb5.conf and add something along the lines of:
[libdefaults]
# Set the realm of this host here
default_realm = YOURREALM.LOCAL
# Maximum allowed time difference between KDC and this host
clockskew = 300
# Uncomment this if you run NAT on the client side of kauth.
# This may be considered a security issue though.
# no-addresses = yes
[realms]
YOURREALM.LOCAL = {
# Specify KDC here
kdc = mydomaincontroller.my.domain.local
# Administration server, used for creating users etc.
# admin_server = kerberos.my.domain
}
7. test kerberos:
kinit your_windows_username@YOUR_FQDN_WINDOWS_DOMAIN.IN_ALL_CAPS
If you get no error, run klist and you should see a ticket.
8. Make sure the time is accurate on your OpenBSD server.
Thursday, January 15, 2009
Friday, January 2, 2009
IPSec tunnels on a dual homed Cisco ASA 5510
I recently had an issue where a client wished to route one IPSec tunnel over one ISP, and another tunnel over another ISP. One ISP was on the outside interface, and the other ISP was on an interface called backup-link.
I assumed, incorrectly, that it was going to be as simple as adding a static route for the IP of the destination to route through the second ISP's gateway. That did allow me to bring up the tunnel, but traffic would not pass.
The route I added was something along the lines of:
route backup-link my.external.address my.netmask my.2nd.isps.gateway 1
As it turns out, the ASA assumes that even IPSec tunneled traffic will be using the default gateway, so I had to add another route like so:
route backup-link my.internal.subnet.at.the.other.office my.netmask my.2nd.isps.gateway 1
And that seemed to work.
I assumed, incorrectly, that it was going to be as simple as adding a static route for the IP of the destination to route through the second ISP's gateway. That did allow me to bring up the tunnel, but traffic would not pass.
The route I added was something along the lines of:
route backup-link my.external.address my.netmask my.2nd.isps.gateway 1
As it turns out, the ASA assumes that even IPSec tunneled traffic will be using the default gateway, so I had to add another route like so:
route backup-link my.internal.subnet.at.the.other.office my.netmask my.2nd.isps.gateway 1
And that seemed to work.
Subscribe to:
Posts (Atom)