Wednesday, May 7, 2014

OpenSwan to fortigate route-based vpn

In this blog we will look at a route-based vpn using OpenSwan.

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