On the “client” side :
iperf -u -c 239.192.95.98 -p 10000 -b 1 -i 5 -T 10 -t 120
-u : use UDP
-c : run in client mode
-p : port
-b : bandwidth in bits/sec
-i : interval in second
-T : TTL
-t : time to transmit in seconds
On the “server” side :
iperf -s -i 1 -u -B 239.192.95.98 -p 10000
-s : run in server mode
-B : bind to multicast address
Belgacom ISP force IP renewal for their residential ADSL customers every 36 hours for whatever stupid purpose (annoy us, sell their fixed IP option, etc.).
Here’s how I force my Cisco 837 router to renew its WAN IP every night at 01:00am :
kron occurrence RENEW_IP at 1:00 recurring
policy-list RENEW_IP
kron policy-list RENEW_IP
cli clear interface Dialer 1I’m less likely to lose my SSH/VPN connections now..
This one is a bit less complex than http://www.wains.be/index.php/2009/09/13/wpa2-freeradius-eap-tls/
This is actually the most basic RADIUS configuration ever, useful for quick tests. I can only recommend checking the post mentioned above if you want to do something serious.
# apt-get install freeradius
# vim /etc/freeradius/users
login Cleartext-Password := "password"
login2 Cleartext-Password := "password2"#vim /etc/freeradius/clients.conf
client localhost {
ipaddr = 127.0.0.1
secret = radiuspassword
}
client router {
ipaddr = 10.0.0.1
secret = radiuspassword
}# /etc/init.d/freeradius restart
Check if RADIUS is working :
# radtest login password localhost 1812 radiuspassword
Sending Access-Request of id 222 to 127.0.0.1 port 1812
User-Name = "login"
User-Password = "password"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=222, length=20
# radtest login2 password2 localhost 1812 radiuspassword
Sending Access-Request of id 1 to 127.0.0.1 port 1812
User-Name = "login2"
User-Password = "password2"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=1, length=20
We expect Access-Accept from the server, not Access-Reject…
Configure your wireless access point :
Usually found under Security tab (or RADIUS, 802.1X, etc.)
Configure your device at 10.0.0.1 to authenticate against the Radius server with password radiuspassword.
Try to connect to your wireless access point using login and password.
Tested under Debian Lenny
BUILDING AND INSTALLING FREERADIUS WITH TLS SUPPORT
Install the necessary packages :
apt-get install dpkg-dev fakeroot
Download the source :
cd /root
mkdir freeradius-tls
cd freeradius-tls
apt-get source freeradius
Make the changes :
Edit /root/freeradius-tls/debian/rules :
and change
--with
by
--without
for eap_tls, eap_ttls, eap_peap and openssl
Just as :
--with-rlm_eap_tls \
--with-rlm_eap_ttls \
--with-rlm_eap_peap \
--without-rlm_eap_tnc \
--without-rlm_otp \
--with-rlm_sql_postgresql_lib_dir=`pg_config --libdir`\
--with-rlm_sql_postgresql_include_dir=`pg_config --includedir` \
--with-openssl \
--without-rlm_eap_ikev2 \
--without-rlm_sql_oracle \
--without-rlm_sql_unixodbc \
Then, comment the following :
for pkg in ${pkgs} ; do \
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then \
echo "$$pkg links to openssl" ;\
exit 1 ;\
fi ;\
done
Edit /root/freeradius-tls/debian/control :
On the line beginning by “Build-Depends”
Add the folowing :
", libssl-dev"
at the end of the line (without the quotes)
Install dev libraries :
apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev
Build freeradius :
dpkg-buildpackage -rfakeroot
Building will end by a warning message, this is not important.
Put the packages on hold to avoid upgrading with a non-TLS version of FreeRADIUS :
echo “freeradius hold” | dpkg --set-selections
echo "libfreeradius2 hold" | dpkg --set-selections
echo "freeradius-common hold" | dpkg --set-selections
Install the packages we’ve just built :
dpkg --install freeradius-common_2.0.4+dfsg-6_all.deb libfreeradius2_2.0.4+dfsg-6_i386.deb
CERTIFICATES
Creating the CA
apt-get install openssl
Edit /etc/ssl/openssl.cnf
[ CA_default ]
dir = ./PKI
Edit /usr/lib/ssl/misc/CA.sh
CATOP=./PKI
Then type :
cd /etc/ssl
/usr/lib/ssl/misc/CA.sh -newca
Set a challenge password and a passphrase. This is needed.
The CA created will be copied to the server and clients later on.
Optional : if you have Windows XP clients
Create /etc/openssl/PKI/xpextensions
[xpclient_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.2
[xpserver_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.1Server certificate signing request :
cd /etc/ssl
openssl req -new -nodes -keyout PKI/server_key.pem -out PKI/server_req.pem -days 730 -config openssl.cnf
Set a challenge password
Sign the server certificate request (if winxp clients) :
cd /etc/ssl
openssl ca -config openssl.cnf -policy policy_anything -out PKI/server_cert.pem -extensions xpserver_ext -extfile PKI/xpextensions -infiles PKI/server_req.pem
Mac clients :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/server_cert.pem -infiles PKI/server_req.pem
Then :
cp server_cert.pem server_cert.pem-backup
Edit server_cert.pem
Remove everything before the line —–BEGIN CERTIFICATE—– (this is needed for winxp clients)
Next :
cat server_key.pem server_cert.pem > server_keycert.pem
Create a client certificate signing request :
cd /etc/ssl
openssl req -new -keyout PKI/client_key.pem -out PKI/client_req.pem -days 730 -config openssl.cnf
Sign client cert request :
cd /etc/ssl
Windows xp client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -extensions xpclient_ext -extfile PKI/xpextensions -infiles PKI/client_req.pem
Mac OS X client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -infiles PKI/client_req.pem
Export P12 certs (Windows and Mac clients ) :
openssl pkcs12 -export -in client_cert.pem -inkey client_key.pem -out client_cert.p12 -clcerts
FREERADIUS CONFIG
FreeRadius
Do :
cp /etc/ssl/PKI/cacert.pem /etc/freeradius/certs/cacert.pem
cp /etc/ssl/PKI/server_keycert.pem /etc/freeradius/certs/server_keycert.pem
Then :
cd /etc/freeradius/certs
openssl dhparam -check -text -5 512 -out dh
dd if=/dev/urandom of=random count=2
chown freerad dh
chmod o-w dh
Next :
cp /etc/freeradius/eap.conf /etc/freeradius/eap.conf-default
/etc/freeradius/eap.conf :
eap {
default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
tls {
certdir = ${confdir}/certs
cadir = ${confdir}/certs
private_key_password = whatever
private_key_file = ${certdir}/server_keycert.pem
certificate_file = ${certdir}/server_keycert.pem
CA_file = ${cadir}/cacert.pem
dh_file = ${certdir}/dh
random_file = ${certdir}/random
fragment_size = 1024
include_length = yes
check_cert_cn = %{User-Name}
cipher_list = "DEFAULT"
}
} Edit /etc/freeradius/clients.conf
We will consider the access-point that will authenticate users against the RADIUS server has the IP 192.168.7.45 :
client localhost {
ipaddr = 127.0.0.1
secret = testing123
require_message_authenticator = no
nastype = other # localhost isn't usually a NAS...
}
client 192.168.7.45 {
secret = suchasecurepassword
shortname = linksys
}Start FreeRADIUS :
freeradius -X -f
Set up wifi access point for authentication against our new RADIUS server
It depends on your hardware here.
You must usually go under the security panel of your device, where you can specify the IP/hostname and port of the RADIUS server, and the password (in our example : suchasecurepassword)
Configure clients
This will be the subject of a separate post as I will try to publish the method for all majors OSes (Linux, Mac and Windows) but don’t have much time for now.
Stay tuned !
This post is a stripped down version of the following howto by my colleague Jérôme :
http://hanoteau.blogspot.com/2009/03/howto-setup-eap-tls-wpa-network-with.html
I’m under Debian Lenny at work.
I installed the VPNC plugin (Cisco VPN) for NetworkManager today.
I usually always connect to OpenVPN tunnels with the OpenVPN plugin, which works pretty well (at least on NM 0.6.6).
After installing the VPNC plugin, I started having issues with my OpenVPN tunnels.. I was not able to resolve remote hostnames correctly.
The problem was that my resolv.conf didn’t get updated upon connection to the OpenVPN.
When installing network-manager-vpnc-gnome, a dependency named “resolvconf” got installed along. The package somewhat protected /etc/resolv.conf from being updated.
After getting rid of resolvconf, my OpenVPN VPNs are working again !
Also, this didn’t prevent the Cisco VPN from working..
I need to check out what that resolvconf package is all about.. if someone has a clue, please comment 
This article quickly explains how to set up a VPN for your remote users based on OpenVPN in around 5 minutes.
If you want detailed informations about OpenVPN, certificates or other stuff, this is not the right place.
This applies to Debian Etch but will work will little difference in paths under Red Hat.
On the server
Install OpenVPN and the dependencies :
# apt-get install openvpn
Copy the scripts that will help us generate all the necessary files (certificates, keys, etc.) :
Under Debian :
# cp -aR /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/pki
Under RedHat :
# cp -aR /usr/share/doc/openvpn-2.0.9/easy-rsa/2.0 /etc/openvpn/pkiLet’s start :
# cd /etc/openvpn/pki
Edit the variables :
# vim vars
export KEY_COUNTRY=US
export KEY_PROVINCE=SC
export KEY_CITY=GREENVILLE
export KEY_ORG=”Green Company, LLC”
export KEY_EMAIL=”admin@example.org”
Set the scripts executable :
# chmod +x *
Source the variables :
# . ./vars
Set up the keys environment :
# ./clean-all
Build the certificate authority (CA) :
# ./build-ca
Build the certificate and private key for the server :
# ./build-key-server server
It’s not necessary to set a password.
Then, build the Diffie Hellman file :
# ./build-dh
Build the client certificate for your first user :
# ./build-key-pass client1
You’ll be asked questions about the client.
Now under /etc/openvpn/pki/keys you must find a bunch of files.
Copy the files necessary for the server on the server under /etc/openvpn :
ca.crt
server.crt
server.key
dh1024.pem
Do so with a single command :
# cp /etc/openvpn/pki/keys/{server.crt,server.key,dh1024.pem,ca.crt} /etc/openvpn
Send the following files to the client, store them wherever pleases you :
ca.crt
client1.crt
client1.key
Send the following configuration to the user “client1″ (vpn.conf which would reside in the same directory as the certificates and key) :
remote vpn.example.org
port 10000
proto udp
dev tun
comp-lzo
client
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
verb 3
ca ./ca.crt
cert ./client1.crt
key ./client1.key
route 172.30.0.0 255.255.0.0
#up ./up.sh
#down ./down.sh
ping 10
ping-restart 60The up and down scripts are respectively executed when the connection is opened and closed.
You can for example change the name server the client will use when connected to the VPN using those scripts (or opening ports in the firewall, etc.).
Server (/etc/openvpn/vpn.conf on the server) :
port 10000
proto udp
dev-type tun
dev vpn-user
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
# enable compression
comp-lzo
# allow several users to connect with the same certificate
duplicate-cn
server 10.30.0.0 255.255.255.0
client-to-client
keepalive 10 120
push "dhcp-option DOMAIN local.example.org"
push "dhcp-option DNS 172.30.0.254"
persist-key
persist-tun
user nobody
group nogroup
log vpn.log
verb 1The server will “push” the DNS settings to the client, this will modify your /etc/
resolv.conf so you will use the DNS server and hostname resolution of your office (or whatever place you are connecting to) when connected to the VPN.
On the server, make sure openvpn starts at boot by uncommenting the following line under /etc/default/openvpn (Debian) :
AUTOSTART="all"
When done, restart OpenVPN on the server :
# /etc/init.d/openvpn restart
Now, connect from the client (as root, or use sudo) from a remote network :
# openvpn --config vpn.conf
The client will get an IP in the range 10.30.0.x on the device tun0, it will add a route to the range 172.30.0.0/16 through the VPN (172.30.x.x in this example is supposed to be the network subnet on the server side).
Tested under Debian Etch
This is the network configuration of our DHCP/DNS server
Hostname : router.static.example.org
WAN interface (eth0) : 192.168.99.254 mask 255.255.255.0
LAN interface (eth1) : 172.30.200.254 mask 255.255.0.0
Default gateway : 192.168.99.1
First, we need to tell the DHCP server to only run on eth1 :
/etc/default/dhcp3-server :
INTERFACES="eth1"
/etc/dhcp3/dhcpd.conf :
This is the DHCP server configuration.
When a computer requests network information from the DHCP server, the DHCP will update the DNS zones
- dyn.example.org : the zone that will map hostnames to IP address
- 201.30.172.in-addr.arpa : the zone in charge of reverse lookups
ddns-domainname is the domain name that the DHCP server will try to update in the zone. For example if my computer is named mycomputer, it will try to upload the dyn.example.org zone with mycomputer.dyn.example.org.
That option is absolutely needed if you have several domains in the “option domain-name” field (the “search” domains that will be in /etc/resolv.conf), or it could try to add the hostname mycomputer.static.example.org to the dyn.example.org zone.
If you only have one domain in the “option domain-name” field, you can go without ddns-domainname as it will upload the zone with the domain specified there.
ddns-update-style interim;
include "/etc/bind/rndc.key";
zone dyn.example.org. {
primary 127.0.0.1;
key "rndc-key";
}
ddns-domainname "dyn.example.org";
option domain-name "static.example.org dyn.example.org";
option domain-name-servers 172.30.200.254;
option routers 172.30.200.254;
option broadcast-address 172.30.255.255;
option ntp-servers 172.30.200.254;
default-lease-time 86400;
max-lease-time 86400;
authoritative;
log-facility local7;
subnet 172.30.0.0 netmask 255.255.0.0 {
range 172.30.201.10 172.30.201.200;
# DNS zones to update
zone 201.30.172.in-addr.arpa. {
primary 172.30.200.254;
key "rndc-key";
}
zone dyn.example.org. {
primary 172.30.200.254;
key "rndc-key";
}
}/etc/bind9/named.conf :
Make sure the file contains the following :
include "/etc/bind/named.conf.local";
You should not change that file, as you will specify your options in two other files.
/etc/bind9/named.conf.options :
Your options.
The zone files will be stored under /var/cache/bind/
The queries for unauthoritative domains will be forwarded to 192.168.99.1. You can put the DNS provided by your ISP there (or put the DNS from opendns.com)
options {
directory "/var/cache/bind";
query-source address * port 53;
forwarders {
192.168.99.1;
};
recursion yes;
version "REFUSED";
allow-recursion {
127.0.0.1;
192.168.99.0/24;
172.30.0.0/16;
};
allow-query {
127.0.0.1;
192.168.99.0/24;
172.30.0.0/16;
};
};/etc/bind9/named.conf.local :
This will contain your zone declarations
### options #########
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};
### "static" zones #########
zone "static.example.org" {
type master;
file "db.static.example.org";
};
zone "200.30.172.in-addr.arpa" {
type master;
notify no;
file "db.172.30.200";
};
### dynamic zones (updated by DDNS) #########
zone "dyn.example.org" {
type master;
file "db.dyn.example.org";
allow-update { key "rndc-key"; };
};
zone "201.30.172.in-addr.arpa" {
type master;
notify no;
file "db.172.30.201";
allow-update { key "rndc-key"; };
};Now let’s focus on DNS zones.
In this example we have several zones :
- static.example.org : static zone (like servers with static IP’s)
- dyn.example.org : dynamic zone, updated by DHCP when a computer gets an IP from it
- 172.30.200 : static zone (servers, etc.), which is not updated by DDNS
- 172.30.201 : dynamic zone, will contain information about machines using DHCP
I advise to split the static zones from the dynamic zones, DDNS has a tendency to mess up the zone files, which make them barely readable and manageable.
/var/cache/bind/db.172.30.200 :
$ORIGIN .
$TTL 86400 ; 1 day
200.30.172.in-addr.arpa IN SOA static.example.org. postmaster.example.org. (
200806299 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns.static.example.org.
$ORIGIN 200.30.172.in-addr.arpa.
253 IN PTR server.static.example.org.
254 IN PTR router.static.example.org./var/cache/bind/db.172.30.201 :
$ORIGIN .
$TTL 86400 ; 1 day
201.30.172.in-addr.arpa IN SOA static.example.org. postmaster.example.org. (
200806327 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns.static.example.org.
$ORIGIN 201.30.172.in-addr.arpa./var/cache/bind/db.static.example.org :
$ORIGIN .
$TTL 86400 ; 1 day
static.example.org IN SOA ns.static.example.org. postmaster.example.org. (
200806327 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns.static.example.org.
A 172.30.200.254
$ORIGIN static.example.org.
server A 172.30.200.253
router A 172.30.200.254
ns A 172.30.200.254
ntp CNAME router.static.example.org.
smtp CNAME router.static.example.org./var/cache/bind/db.dyn.example.org
$ORIGIN .
$TTL 86400 ; 1 day
dyn.example.org IN SOA ns.static.example.org. admin.example.org. (
200806341 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS ns.dyn.example.org.
A 172.30.200.254
$ORIGIN dyn.example.org.Now, make sure the zones will be writable by the user “bind” and restart the services :
# chown bind. /var/cache/bind/*
# /etc/init.d/bind restart
# /etc/init.d/dhcp3-server restart
On a computer on the network :
As root :
Edit /etc/dhcp3/dhclient.conf and set :
send host-name "mycomputer";
Now request an IP :
# dhclient eth0
Let’s imagine the computer has received the IP 172.30.201.200
You should see on the server’s syslog that the DNS zones have been updated.
- mycomputer.dyn.example.org is now bound to 172.30.201.200
- 172.30.201.200 will return mycomputer.dyn.example.org
From your computer, you should be able to verify the zones have been updated properly :
$ nslookup mycomputer
Server: 172.30.200.254
Address: 172.30.200.254#53
Name: mycomputer.dyn.example.org
Address: 172.30.201.200$ nslookup 172.30.201.200
Server: 172.30.200.254
Address: 172.30.200.254#53
200.201.30.172.in-addr.arpa name = mycomputer.dyn.example.org.You don’t need to type the whole mycomputer.dyn.example.org thing since it will lookup for either :
- mycomputer.dyn.example.org
- mycomputer.static.example.org if the previous wasn’t found
- mycomputer if the previous two were not found
This actually means that if you lookup www.google.be, it would try to resolve www.google.be.dyn.example.org first, then www.google.be.static.example.org, and finally www.google.be
You can avoid those unnecessary lookups by adding a dot to the end of the hostname you are trying to resolve :
# nslookup www.google.be.
This is the purpose of the search domains in /etc/resolv.conf
Pay attention to the syntax in /etc/resolv.conf.
You should be able to specify up to 6 domains to look up automatically.
Each domains should be on one line, separated by spaces.
I made a mistake and had domains separated by commas.
It was working perfectly fine with up to 2 domains on the search line.
With 3 domains or more, the computer would just not try to resolve on the domains at all.
Edit : between two or MORE subnets. Check out the exchange between Michael Antal and me in the comments. He’s been able to interconnect 3 subnets using this method and some slight tweaks in routes.
The following is the configuration needed to create a routed OpenVPN network between two remote subnets, both behind NAT gateways. On each side, the gateways will act as the VPN gateways.
Network subnets on both side must be different. In this example, we connect 192.168.1.0/24 to 192.168.200.0/24.
With this setup, we don’t even need to open ports at the NAT level on either side of the VPN.
Network configuration
Network A :
Subnet : 192.168.1.0/24
Gateway for Network A
VPN interface (tun0) : 10.0.0.1
Eth0 : 192.168.1.254
Eth1 / Public IP : 212.x.x.x (machineA.example.org)
Network B :
Subnet : 192.168.200.0/24
Gateway for Network B
VPN interface (tun0) : 10.0.0.2
Eth0 / Public IP : 66.x.x.x (machineB.example.org)
Eth1 : 192.168.200.254
If we imagine forwarding is rejected at the firewall level on machine B, we would need to allow traffic between the tun device created by OpenVPN and the LAN interface, as root you would then type :
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT
Make sure the rules remain applied across reboots (using iptables-save or storing the rules in /etc/rc.local or else)
Enabling IP routing :
We need to enable routing on both VPN gateways..
echo “1″ > /proc/sys/net/ipv4/ip_forward
Using this method, routing is not persistent across reboots, check the following link :
http://www.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/ (which works for Debian as well)
Static key generation :
We will use simple static key for our example…
openvpn --genkey --secret /etc/openvpn/vpn.key
Share the key between the VPN gateways over a secure channel (scp, etc.).
If you want to use certificates instead (which I recommend), check out : http://www.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/
OpenVPN configuration :
machine A : /etc/openvpn/vpn.conf
remote machineB.example.org
float
port 8000
dev tun
ifconfig 10.0.0.1 10.0.0.2
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.200.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
machine B : /etc/openvpn/vpn.conf
remote machineA.example.org
float
port 8000
dev tun
ifconfig 10.0.0.2 10.0.0.1
persist-tun
persist-local-ip
persist-remote-ip
comp-lzo
ping 15
secret /etc/openvpn/vpn.key
route 192.168.1.0 255.255.255.0
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1
Establishing the connection :
On machine A type :
openvpn --config /etc/openvpn/vpn.conf
Machine A will try to establish the connection. Type the same command on machine B to initialize the connection.
As soon as the connection is up, hosts on network A should be able to ping hosts on network B and vice-versa. If you can’t ping from one side to the other, it’s probably a routing issue.
We can use traceroute from a machine on network A to see the path taken to reach a host on network B :
$ traceroute 192.168.200.30
traceroute to 192.168.200.30 (192.168.200.30), 30 hops max, 40 byte packets
1 192.168.1.254 (192.168.1.254) 2.128 ms 2.378 ms 2.781 ms
2 10.0.0.2 (10.0.0.2) 132.761 ms 137.342 ms 141.130 ms
3 192.168.200.30 (192.168.200.30) 136.752 ms 133.869 ms 135.960 ms
We can see the traffic is going through the 10.0.0.2 interface.
We also can check the routing table on the VPN gateway on network A :
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.200.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
0.0.0.0 212.x.x.x 0.0.0.0 UG 0 0 0 eth1
We see any traffic directed to 192.168.200.0/255.255.255.0 must go through interface 10.0.0.2 on device tun0.
Making sure the VPN connection is established at boot (Debian way) :
Edit /etc/defaults/openvpn and specify which VPN network must be started.
Make OpenVPN starts at boot with this command :
update-rc.d openvpn defaults
OpenVPN will start any VPN configuration named *.conf found in /etc/openvpn/
So don’t store copies of config like test.conf test-backup.conf as OpenVPN will try to start them at boot.
I’ll explain the few commands used to enable DHCP snooping on our Catalyst switch at work.
The users aren’t really tech savvy or anything, but it is painless to configure so it is worth having it enabled.
switch1>enable
First, we need to know which VLAN the DHCP server belongs to, “show arp” has that info :
switch1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.3 1 0004.75XXXXXX ARPA Vlan1
Then we enable configuration mode :
switch1#conf term
Enabling DHCP snooping on VLAN 1 :
switch1(config)#ip dhcp snooping
switch1(config)#ip dhcp snooping vlan 1
switch1(config)#ip dhcp snooping information option
The DHCP server is connected to the second port, we will add that interface to the trusted list :
switch1(config)#interface fastEthernet 0/2
switch1(config-if)#ip dhcp snooping trust
Let’s review the config :
switch1#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
———————— ——- —————-
FastEthernet0/2 yes unlimited
DHCP snooping is enabled on VLAN 1 for interface 2 !
Saving the config :
switch1#copy running-config startup-config
Finally, I have decided to take 5 minutes and focus on the gratuitous ARP broadcast issue I have with our Windows 2000 server (Fujitsu Siemens server).
The problem is described here :
http://www.wains.be/index.php/2007/03/24/unsolvable-gratuitous-arp-from-our-windows-2000-server-with-intel-pro-1000/
I have installed Wireshark on the Windows box, had to reboot (oh !) to get it working.
Thanks to Wireshark, I figured out the gratuitous ARP traffic was generated as some lower level than Windows.
Indeed, the whole network is seeing the gratuitous ARP broadcast except the Windows box. Conclusion : the broadcast is not generated by the OS but probably by the hardware itself.
I have checked the BIOS for any interesting setting but I don’t find anything relevant. The BIOS is really minimal actually.
I found another person having the same issue with the same network interface :
http://techrepublic.com.com/5208-6230-0.html?forumID=101&threadID=224471&messageID=2245929
I will avoid Fujitsu Siemens for servers in the future : cheap RAID controller (Promise), Maxtor drives, minimal BIOS, etc.
Next : figuring out why the Windows printer spooler randomly stops working (printing blank pages actually), restarting the service fixes the issue….. (edit : seems fixed by updating the drivers while the changelog didn’t mention the issue, damn HP)
