Openswan is a opensource ipsec implementation that runs under most linux and bsd OSes. It's common for linux based firewalls to be built around it or Freeswan.
You can find information about both here;
http://en.wikipedia.org/wiki/Openswan
http://en.wikipedia.org/wiki/FreeS/WAN
1st the topology;
NOTE: In this vpn, we will use PSK ( aka common secret ) between both parties
The fortigate unit has been configured for the one single cipher of aes128-sha1, with pfs & dead-peer-detect disable.
Here's my phase1-interface configuration;
config vpn ipsec phase1-interface
edit "openswan"
set interface "wan1"
set dpd disable
set nattraversal disable
set dhgrp 1
set proposal aes128-sha1
set remote-gw 1.2.3.254
set psksecret ENC BAAAANB/SA4YD9zsecG97tEeiGhLF+7BS6Tj4a5l7HkqkRFBS+5W7aHGKy5ocI+gFFWVE2JX4gZjyABz/UsfQMU9ZbsW0Gl0yEPQ5xQvTgHJgGSS
next
end
The phase2-interface configuration is configured as;
config vpn ipsec phase2-interface
edit "openswan-p2"
set auto-negotiate enable
set keepalive enable
set pfs disable
set phase1name "openswan"
set proposal aes128-sha1
set replay disable
set dst-subnet 10.10.10.0 255.255.255.0
set keylifeseconds 3600
set src-subnet 192.168.254.0 255.255.255.0
next
end
And lastly, we need a static route to the remote destination;
config router static
edit 28
set device "openswan"
set dst 10.10.10.0 255.255.255.0
set weight 50
next
end
Outside of the above and a firewall policy or two, you should have the based for a 100% functional route-based ipsec-vpn.
NOTE: a routed-based vpn is based on having a vpn phase1-interface and a route to the remote network(s)
Now onto the openswan side of things, this is where the fun starts. You will need to install openswan if the package is not already included on the linux server
apt-get install openswan
After the install, we typically need to modify only 2 files ( ipsec.secret ipsec.conf ) . The 1st file is simply the psk secret that we will use between the 2 vpn-gateway
NOTE: sample ipsec.secret file
mybloglinuxserv01 cat /etc/ipsec.secrets
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication. See ipsec_pluto(8) manpage, and HTML documentation.
# RSA private key for this host, authenticating it to any other host
# which knows the public part. Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
# this file is managed with debconf and will contain the automatically created RSA keys
include /var/lib/openswan/ipsec.secrets.inc
#
# fortigate appliance at HQ public address
1.1.1.1: PSK "mysecuredkeyhere"
NOTE: I should not have to explain , but the 2 keys should match, and make it a strong key ;)
Next, we will modify the /etc/ipsec.conf file. Before we dive into this file, I would like to explain some interesting behavior within openswan that pertains to this file.
Openswan is cool in that if you don't define a cipher, it will present all ciphers during the incoming proposal. This could be a good or bad thing, and could confuse the far-end device. I myself like to define the actual proposal(s) that we want to use between peers.
Next, if you don't define the cipher and authentication method, it will auto-proposal the authentication hash type between the peers using md5 and sha
e.g
ike=aes128
vrs
ike=aes128-md5
The former will present both sha1 and md5 in it's outgoing proposal request, the latter will present md5 only;
(example of a diag debug on a fortigate with both md5 and sha has been offered to the peer during the IKEv1setup )
ike 0:openswan:45771: incoming proposal:
ike 0:openswan:45771: proposal id = 0:
ike 0:openswan:45771: protocol id = ISAKMP:
ike 0:openswan:45771: trans_id = KEY_IKE.
ike 0:openswan:45771: encapsulation = IKE/none
ike 0:openswan:45771: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC.
ike 0:openswan:45771: type=OAKLEY_HASH_ALG, val=MD5. <---- HERE
ike 0:openswan:45771: type=AUTH_METHOD, val=PRESHARED_KEY.
ike 0:openswan:45771: type=OAKLEY_GROUP, val=1536.
ike 0:openswan:45771: ISKAMP SA lifetime=28800
ike 0:openswan:45771: proposal id = 0:
ike 0:openswan:45771: protocol id = ISAKMP:
ike 0:openswan:45771: trans_id = KEY_IKE.
ike 0:openswan:45771: encapsulation = IKE/none
ike 0:openswan:45771: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC.
ike 0:openswan:45771: type=OAKLEY_HASH_ALG, val=SHA. <---HERE
ike 0:openswan:45771: type=AUTH_METHOD, val=PRESHARED_KEY.
ike 0:openswan:45771: type=OAKLEY_GROUP, val=1536.
vrs a single defined authentication hash
(example of a diag debug on a fortigate with sha only enabled on the ipsec.conf file )
ike 0:openswan:46589: incoming proposal:
ike 0:openswan:46589: proposal id = 0:
ike 0:openswan:46589: protocol id = ISAKMP:
ike 0:openswan:46589: trans_id = KEY_IKE.
ike 0:openswan:46589: encapsulation = IKE/none
ike 0:openswan:46589: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC.
ike 0:openswan:46589: type=OAKLEY_HASH_ALG, val=SHA. <---HERE
ike 0:openswan:46589: type=AUTH_METHOD, val=PRESHARED_KEY.
ike 0:openswan:46589: type=OAKLEY_GROUP, val=1536.
ike 0:openswan:46589: ISKAMP SA lifetime=28800
Next, the terms in openswan's ipsec.conf of "left" and "right" can be looked at as local and remote. So any where in the cfg that you see left or right , just substitute in your mind ; "local" & "remote".
Next, configure values under the basic general configuration area is overridden by the configure value within the connection area.
e.g
# general global area
config setup
nat_traversal=no
# individual connections
conn FGT
nat_traversal=yes
NOTE: the latter will over-ride the global area configuration in regards to NAT transversal
vpn connections that has the wording of "auto=start" , will always start up on a reboot or restart of the services
Here's my base configuration for simple site2site vpn using openswan
=================================================================
cat /etc/ipsec.conf
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
protostack=netkey
# Enable core dumps (might require system changes, like ulimit -C)
# This is required for abrtd to work properly
# Note: incorrect SElinux policies might prevent pluto writing the core
dumpdir=/var/run/pluto/
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
# nat_traversal=yes
oe=off
# tunnel specific for each gateway
#
conn FGT
type=tunnel
authby=secret
left=1.2.3.254
leftnexthop=%defaultroute
leftsubnet=10.10.10.0/24
# here we define the remote-vpn-gateway address
right=<ip_address of the fortigate firewall public the same one we have in the ipsec.secret file >
# remote subnet that we want to connect to
rightsubnet=192.168.254.0/24
ike=aes128
# ike=aes128-sha
esp=aes128
ikelifetime=28800s
keyexchange=ike
pfs=no
# dpdaction=restart_by_peer
# dpdtimeout=10
# dpddelay=10
auto=start
=====================================================================
After you make any changes to any configurations files, it's customary to restart the services;
mybloglinuxserv01 service ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.37/K3.8.0-29-generic
mybloglinuxserv01
Any connections with the "auto=start" will automatically start upon the services restarts. You can now test the vpn for connectivity and by using my t-shoot vpn fortigates from one of my earlier post, you can perform detail diagnostics if a problem develops.
Keep these thoughts in the back of your mind;
- ensure the PSK is enclosed with " " quotations
- make sure no whitespace in any PSK entries
- narrow your cipher proposals to what you "want" and don't rely on automatic propsoals
- make sure you define the left/right subnet correctly ( same applies for the fortigate src-subnet or dst-subnet )
- you can use the tcpdump on the linux host for troubleshooting things like ike and ipsec
- just like with the fortigate, ensure the correct iptables or firewall rules if your running iptables
- the fortigate offers great diagnostic information
- linux offers great diagnostic also ( var/log, tcpdump, tshark, ipsec commands etc......)
- try to always match the IKE=keylife and IPSEC-SA lifetime between peers
- openswan works with almost everything that I've tried from cisco ASA , Juniper, Vyatta, Fortigate, etc.......
Ken Felix
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
^ ^
=( @ @ )=
o
/ \
No comments:
Post a Comment