Forums

kfox
kfox
Offline
Resolved
0 votes
I can't seem to find the IPsec app for ClearOS 6.3

I see the paid "dynamic vpn" app in the market place and it appears to reference an independent IPsec app.

The Dynamic VPN app is an extension to ClearOS's IPSec VPN app. The service allows IPSec to be used in situations where either one or both of the gateways are on a dynamic IP address issued by the ISP or in cases where instability using unmanaged IPSec tunnels exists.
In VPN
Wednesday, August 29 2012, 08:45 PM
Share this post:
Responses (56)
  • Accepted Answer

    Sunday, February 17 2013, 08:00 PM - #Permalink
    Resolved
    0 votes
    My father has a Ubee router. I've opened a new thread with a screenshot.

    Configuring the static IPSEC VPN app
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 01:36 PM - #Permalink
    Resolved
    0 votes
    Marcel van Leeuwen wrote:
    What do you mean with "bells and whistles" the tools to configure IPSEC?

    Mostly on Sundays i'm visiting my dad so i can take a look how i have to configure his modem. Any tips are appreciated! I have to use Perfect Forward Security and Main Mode? I already opened port 500 (IPSEC) in my firewall.
    "Bells and Whistles" are things like control over PFS and the use of aggressive mode. Also if you have a pretty dynamic IP at the ClearOS end you can use things like %defaultroute rather than an IP address to identify your end of the tunnel and FQDN's for both ends. You also get the ability to set it up behind another NAT firewall.

    At your end of the tunnel, rather than open up UDP:500, it is better to open up the Standard Service "IPsec". This also opens the firewall to the ESP protocol and helps with some internal firewalling.

    When setting up initially, it may be better to set ClearOS to Listen Only. Treat your and your father's IP address as fixed. What router does he have?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 01:24 PM - #Permalink
    Resolved
    0 votes
    Sent a email to you Tim!

    Thank you for the link.., I'm in reading mode :)
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 01:19 PM - #Permalink
    Resolved
    0 votes
    If you are unfamiliar with IPsec implementation have a look here (it also indicates the differences between the two)
    http://www.clearcenter.com/support/documentation/user_guide/static_ipsec_vpn
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 01:12 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    @Marcel,
    The basic app is still very powerful and should allow connectivity with third party routers as well as ClearOS <-> ClearOS. It is considerably more flexible than in 5.2. It is only the "bells and whistles" that are are missing. In a third party router, you will need to use Perfect Forward Security (PFS) and Main Mode (as opposed to aggressive mode), but otherwise a connection should be straightforward.


    @Nick

    What do you mean with "bells and whistles" the tools to configure IPSEC?

    Mostly on Sundays i'm visiting my dad so i can take a look how i have to configure his modem. Any tips are appreciated! I have to use Perfect Forward Security and Main Mode? I already opened port 500 (IPSEC) in my firewall.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 12:56 PM - #Permalink
    Resolved
    0 votes
    Hi Marcel, the basic app *may* work with your dads router, but there is no guarantee and may require you to tinker with the configs from the command line if that's the route you want to go. The basic app permits you to setup a tunnel using your connection details, but does not you to tweak the encryption options for the oddities of other IPsec implementations. Hence why it is advertised for ClearOS connections only, as Openswan tunnels do not need that kind of control, they just 'work'.

    Other third party kit, particularly if you don't have control over the settings at both ends, require you to match exactly the IPsec config - hence why the full version has all the extras. This gives you the level of control required to connect to as much third party kit. The full version of the app includes support for connection 'ID's which help with dynamic or roadwarrior type connections.

    Your IP addresses are more static than dynamic so you will be OK. The configs are generally static, (i.e. contain a hostname or IP) therefore if your IP did change you'd have to reconfigure and restart your tunnels, not something you want to do on a regular basis. That's also the reason why ClearCenter offer the dynamic IPsec VPN app which monitors and manages the address changes.

    Marcel send me a PM or email to trburgess @ gmail .com and I'd be happy to send you one.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 12:33 PM - #Permalink
    Resolved
    0 votes
    Hmm, i understand when you use the basic IPSEC app you can only connect a ClearOS to ClearOS server. What i like to do is connect my dad's router to my ClearOS server. So that's a third party device so i need the paid app. True? If i'm correct you need a static IP address. My IP address only changes when my my modem detects a other NIC connected to WAN so that practically never happens. Also this applies for my dad's IP address. Actually i want to try this app before i buy this...

    Or do i belong to the category of contributing forum members.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 12:29 PM - #Permalink
    Resolved
    0 votes
    @Marcel,
    The basic app is still very powerful and should allow connectivity with third party routers as well as ClearOS <-> ClearOS. It is considerably more flexible than in 5.2. It is only the "bells and whistles" that are are missing. In a third party router, you will need to use Perfect Forward Security (PFS) and Main Mode (as opposed to aggressive mode), but otherwise a connection should be straightforward.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 09:52 AM - #Permalink
    Resolved
    0 votes
    Thanks for the feedback, I should of of added that regular community contributors can ping me or the dev team for a license for the full version :)

    Marcel I hear you, and it is aimed for business, the free app should provide enough functionality for home users
    The reply is currently minimized Show
  • Accepted Answer

    kfox
    kfox
    Offline
    Sunday, February 17 2013, 09:04 AM - #Permalink
    Resolved
    0 votes
    The free basic version of the app at least restores the level of functionality to that which was available for free with 5.x and earlier distros.

    I can't complain about that.

    Thanks Tim, great work, I look forward to trying it out.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 17 2013, 08:36 AM - #Permalink
    Resolved
    0 votes
    Hi Tim,

    First it's not possible to leave a reaction in the other thread because Peter has locked the thread.

    I have a bit of mixed feelings with the price of the app. Is 50 dollar not a bit high for this app? I can understand you ask this price from a business perspective but from a perspective of a home user... I think this price is right for a company to pay but home users... but then you can say this applies also for other apps and services of Clearfoundation. Also i can buy Mac OS X Lion two times for this price a complete OS! It's not that i award (not sure if it is the right word) Clearfoundation or you but yeah mixed feelings...
    The reply is currently minimized Show
  • Accepted Answer

    Friday, February 15 2013, 09:24 PM - #Permalink
    Resolved
    0 votes
    Just to conclude this thread the app is now released :) Feedback always welcomed!
    http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,21/func,view/id,50307/
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 09 2013, 07:17 PM - #Permalink
    Resolved
    0 votes
    If i can help with something let me know. I'm very interested in this app.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 07 2013, 12:15 PM - #Permalink
    Resolved
    0 votes
    Tim,
    I was not sure if we'd also want to maintain compatibility with 5.2. It makes things harder as we'd need 4 conns per tunnel and the "ipsec auto" commands would need to act on all four conns. I *think* with our 1 conn method to 5.2 a LAN-LAN connection will work, nothing to or from the 5.2 gateway will work but from the 5.2 LAN it may work to the 6.x gateway.
    Nick
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, January 06 2013, 11:46 PM - #Permalink
    Resolved
    0 votes
    Nick, sorry missed your append - the basic 4 tunnel config is something like the following with combinations of left, leftnexthop, leftsubnet, right, rightnexthop, and rightsubnet.

    I believe with the newer versions of Openswan and the usage of leftsourceip / rightsourceip, you no longer need this setup as it can be accomplished with one tunnel.

    (Head = Headquarters end, Sat = Satellite end)
    HeadNet <> SatNet
    HeadGate <> SatNet
    HeadNet <> SatGate
    HeadGate <> SatGate
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, January 06 2013, 11:37 PM - #Permalink
    Resolved
    0 votes
    Hi everyone, just to update on progress, with the help of Nick Howitt and David Clayton (thank you!) the Static IPsec app is taking shape and nearing completion. We have pushed its features beyond what was available in 5.2, in the hope that it will make ClearOS much more interoperable with third party VPN hardware and bespoke network configurations. If there is anyone who is able to provide working Openswan <-> Third party configs or hardware for testing I'd be interested to hear from you.

    Please send an email to trburgess @ gmail dot com, or drop me a forum IM

    Thanks!
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 30 2012, 12:55 PM - #Permalink
    Resolved
    0 votes
    David (or anybody),

    I'm on 6.3 and my play 5.2 VM has natted interfaces so the IPSec VPN app does not work. Is there any chance you can post your ipsec.conf and the 4 /etc/ipsec.d/ipsec.*.conf files relating to one ClearOS <-> ClearOS VPN. I'd like to look at how the ClearOS tunnel is configured.

    Thanks.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 29 2012, 03:11 PM - #Permalink
    Resolved
    0 votes
    Hi Tim,

    The IPSEC VPN is now so well established I consider it 'rock solid', well okay 'reliable enough'. The majority of issues people experience with IPSEC is due to incorrect configuration of one, or both sides of the tunnel - even small things like both endpoints referencing an NTP server to ensure second by second accuracy.

    There is no denying that setting up an IPSEC VPN is not an 'easy job', but then again enterprise security is never likely to always be one hundred percent user friendly.

    I would be more than happy to write a 'case study' user guide to show how my 'hub and spoke' VPN is setup.

    David
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 29 2012, 01:55 PM - #Permalink
    Resolved
    0 votes
    Thanks for the feedback - sorry its still on my todo list to get something out there (life has been too busy). I'd like to get some beta testing done and will report back here when / if available.

    There are some hesitations about IPsec reliability, but i'd like to put together a tool for third party hardware - even if it does come with a big health warning.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 29 2012, 12:33 PM - #Permalink
    Resolved
    0 votes
    David,

    I recently produce a spreadsheet mock up with notes for Tim to look at. I went for a bigger than basic solution and I have said to Tim I would propose a couple of very basic configs, one for ClearOS to ClearOS and one for ClearOS to 3rd party. I have not yet done that.

    If you want to PM me with your e-mail address I can send you the spreadsheet. Comments would be appreciated.

    Nick
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 29 2012, 10:25 AM - #Permalink
    Resolved
    0 votes
    Hi all,

    I know that this thread is a a month or two old now, but I want to add some comments:

    1) The vast majority of 'small business' Router hardware (Netgear, DrayTek etc) use IPSEC as their standard 'site-to-site VPN protocol, therefore I feel that it is important that we get a basic IPSEC application included in Clear OS.

    2) Even if we start at a very basic 'IP based policy' application, once the 'page' has been created, adding some extra fields (and validation), that write to the config and secrets files, can be enhanced at a later date.

    3) I will be more than happy to provide my box as a guinea pig for testing purposes for a web GUI, although I will try and get a working CL version first. (I'm waiting on 6.4 for the proxy and mail reports, before I switch over from 5.2).

    David
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, September 11 2012, 11:59 AM - #Permalink
    Resolved
    0 votes
    @Tim
    Another few bits of info:
    In the IPSec Overview, linked to earlier in the thread, it only lists the init commands. Using them exclusively to manage IPSec can be a bit brutal. For example if you create a new conn, the implication is that you need to do a "service ipsec restart" to start using the conn. Doing this will temporarily cut any other tunnels you may be running. There is another whole series of commands "ipsec auto ....." which allow you to manage individual conns. The main commands are "ipsec auto --{add,delete,replace} conn_name". So, if you edit a connection, rather than restarting the ipsec service you can do an "ipsec auto --replace conn_name". If you wanted to stop a conn you could do an "ipsec auto --delete conn_name" and so on. This would allow you to have a front screen where you can list start, stop and edit conns. You may also be able to see the conn status from "ipsec auto --status" but I can't check 'til I get home.

    It is worth bearing in mind that adding or replacing a conn does not reread the secrets. This has to be done in a separate command "ipsec secrets" which should probably be run just before an add or replace command. It is safe to run it as often as you want as it does not interfere with running conns.

    Lastly, on the subject of secrets, if you have the key word %any in any of the ipsec.secrets files you can only have a single PSK associated with it. This means all conns coming from dynamic remote end points must either share the same PSK, or to have different PSK's use @rightid instead of %any or use an FQDN (and suffer propagation DNS delays).

    [edit]
    "ipsec auto --status" does not give anything useful. I am not sure how to get a conn status.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 07 2012, 10:49 PM - #Permalink
    Resolved
    0 votes
    Thanks Nick!, and Herballizard
    The reply is currently minimized Show
  • Accepted Answer

    Friday, September 07 2012, 05:28 PM - #Permalink
    Resolved
    0 votes
    From searching the forums for ipsec.conf:
    Cisco ASA
    Netgear FV318
    Sonicwall - you should not now need the nhelpers line
    Nortel Contivity
    Possible DLink 804HV
    Linksys RV042, possibly with the Linksys natted.
    Another RV042 thread
    Thread with Fortigate
    Possible Sonicwall thread

    In these threads you do not always see the final working config which is a pity.

    I am not sure if we want to support aggressive mode straight off. Among other things it is less secure. Also to support it you need to fully specify the ike algorithm as it is not negotiated. There is is no phase2. You may also need leftid/rightid (which I would like).

    If you want the interface to specify the algorithms, ike (the first phase) is made up of three bits, the algorithm (like 3DES), the hashing function (SHA1, MD5 and possibly SHA2) and the Diffe-Hellman group (like G2 or modp1024, G5 or modp1536). The phase2alg is just the algorithm and hashing function. ike and phase2alg do not have to be the same. For main mode (as opposed to aggressive mode) no algorithm is needed to be specified. If neither end demands an algorithm, Openswan will use 3DES. You can specify the algorithm on its own, or with the hashing function and, for ike, or with the hashing function and DH group. This lends itself to 3 dropdown boxes for ike and two for phase2alg.

    At some time I will try a dial-out config to my Draytek, but I'm not sure when I'll get to do it.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 05 2012, 06:36 PM - #Permalink
    Resolved
    0 votes
    Here are my (sanitised) configs for a remote Draytek to me. Both ends are vaguely dynamic.

    ipsec.conf
    # The config file changed quite a bit from 1.x.
    # See http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/upgrading.html

    version 2.0

    # Default policy
    #---------------

    config setup
    interfaces=%defaultroute
    plutodebug=none # plutodebug="all crypt"
    klipsdebug=none
    oe=no
    protostack=netkey

    conn %default
    type=tunnel
    authby=secret
    left=%defaultroute
    leftsubnet=192.168.2.0/24
    leftsourceip=192.168.2.1

    # Tunnels defined in separate files
    #----------------------------------

    include /etc/ipsec.d/ipsec.*.conf


    ipsec.draytek2930.conf
    conn MumIn
    auto=add
    rekey=no
    right=%any
    rightsubnet=192.168.10.0/24
    leftid=@FromNick # this does nothing useful in this set up
    dpdtimeout=120
    dpddelay=30
    dpdaction=restart_by_peer


    ipsec.draytek2930.secrets
    %any : PSK "mypsk"


    ipsec.draytek2900.conf
    conn MumIn
    auto=add
    rekey=no
    right=%any
    rightsubnet=192.168.10.0/24
    leftid=@FromNick
    rightid=@FromMum
    dpdtimeout=120
    dpddelay=30
    dpdaction=restart_by_peer


    ipsec.draytek2900.secrets
    @FromNick @FromMum : PSK "mypsk"

    In their wisdom, on the 2930 Draytek stopped transmitting what they call the LocalID which is equivalent to the Openswan rightid which is why my config changed.

    With both ends on a dynamic IP, the devs say left=%defaultroute and right=%any should not work nut it does if you have protostack=netkey. Although this is the default, if you leave it out this set up does not work.

    With dynamic IP's if you are happy to wait for the DNS system to propagate, this iw what I really use for my 2930:ipsec.draytek2930.conf
    conn MumIn
    auto=add
    rekey=no
    right=damim.dtdns.net
    rightsubnet=192.168.10.0/24
    leftid=@FromNick
    dpdtimeout=120
    dpddelay=30
    dpdaction=restart_by_peer


    ipsec.draytek2930.secrets
    @FromNick damim.dtdns.net : PSK "mypsk"


    You can similarly build the FQDN's into the ipsec.secrets file. It relies on DPD to reread the conn and re-evaluate the FQDN's. I have not tested it as the I have VirginMedia "dynamic" IP's. They just about never change. Mine never has since I started with CC4.3. I also have a watching script which pings a remote IP every 5 minutes and resets the conn anyway, just in case the DPD stuff does not work (and for other historic reasons).

    When building a conn it may be easier not to use the "conn %default" as much as I have done. most of those entries could be in the conn itself, but it would have to be in every conn (I used to have 2 VPN's until a lightening strike and it made configuring easier).

    There are other working configs in this forum for things loke a Linksys RV042 and Netgear DG834 and possibly Cisco and Fortigate stuff. I'll try and hunt them down in a while.

    I'm happy to act as a VPN endpoint to one or two people for some limited testing, but this would only really help with Openswan-Openswan testing.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 05 2012, 01:19 PM - #Permalink
    Resolved
    0 votes
    I can't get anything for you right now tim I am waiting on some etho hwics for my 1841's

    But I can grab some cisco configs off some baby 877's etc when I get into work

    Also could grab some cyber roam configs if they want o give up their secrets
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 05 2012, 12:47 PM - #Permalink
    Resolved
    0 votes
    All very useful stuff here Nick! I'll see what I can do :)

    Does anyone have some working .conf files they can post for third party devices? Cisco etc?

    Kfox, your offer of a test ClearOS VM may come in handy... I'll report back here if needed - thanks!
    The reply is currently minimized Show
  • Accepted Answer

    kfox
    kfox
    Offline
    Sunday, September 02 2012, 10:41 PM - #Permalink
    Resolved
    0 votes
    All of my networks use FQDNs like (host.)network.domain.tld so I just use the "network" portion.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 09:19 PM - #Permalink
    Resolved
    0 votes
    Do you have any naming convention for the conns the files contain?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 05:58 PM - #Permalink
    Resolved
    0 votes
    Make sure on the app class to exclude creating and exclude configuring any .conf and .secrets in /etc/ipsec.d that have the word 'managed' in them. The Dynamic VPN service creates its configs files like this:


    -rw-------  1 root root   326 Sep  1 09:55 ipsec.managed.vpnid192837.conf
    -rw------- 1 root root 49 Sep 1 09:55 ipsec.managed.vpnid192837.secrets
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 05:58 PM - #Permalink
    Resolved
    0 votes
    Make sure on the app class to exclude creating and exclude configuring any .conf and .secrets in /etc/ipsec.d that have the word 'managed' in them. The Dynamic VPN service creates its configs files like this:


    rw-------  1 root root   326 Sep  1 09:55 ipsec.managed.vpnid192837.conf
    -rw------- 1 root root 49 Sep 1 09:55 ipsec.managed.vpnid192837.secrets
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 05:43 PM - #Permalink
    Resolved
    0 votes
    Just to add, that if we go down this route, the configuration we come up with will not be fully backward compatible with ClearOS 5.2 and prior. Having said that I am sure it is the right way to go.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 02:45 PM - #Permalink
    Resolved
    0 votes
    If you guys want to make app I appreciate if you support third party devices. The only help I can offer is testing. I have no experience programming.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 01:44 PM - #Permalink
    Resolved
    0 votes
    OK, some comments on the ClearOS IPSec guide:
    In the guide there is no "config setup" or "conn %default". In config setup you want something like:
    config setup
    interfaces=%defaultroute # This is good in a single WAN. I am not sure in multi-WAN
    plutodebug=none
    klipsdebug=none
    oe=no
    protostack=netkey


    In conn %default you do not need anything as all the details can be controlled in the individual conns, but it saves repeating stuff (which does not matter if you are writing the conns programatically). It is pretty safe to use conn %default for the local settings in a single LAN/single WAN environment (left, leftubnet, leftsourceip, type, authby and possibly dpd stuff). Programmatically it may be easier to have everything in the individual conns.

    In the example conn there is no leftsourceip specified. This should be the LAN IP of ClearOS. Without it pings from ClearOS to any remote device will fail (but LAN-LAN pings will still work)

    If we want Openswan to be able to interoperate with other devices or to work with devices on dynamic IP's there are some simple changes and more complex configuration changes we can make. In the example set up Openswan is listening for connections and trying to make them at the same time. It can be a lot easier with third party devices and is (almost) mandatory if the remote end is on a dynamic IP to have ClearOS acting as a responder only. In this case you want the ability to make the following changes:
    auto=add
    rekey=no
    right=%any # only if right has a dynamic IP
    If we are allowing right=%any then we need to allow %any in ipsec.secrets to replace the remote IP (it actually replaces the need for any IP in the file). If you are having multiple dynamic end points then it is a good idea to expose the leftid/rightid conn parameters and allow them to be used in ipsec.secrets. Note that in the Netgear example the liftid and rightid have been specified. This is often not necessary as they default to the Left/Right WAN IP's and that is satisfactory.

    Other parameters we may want to expose are the DPD ones and the key lives (keylife, ikelifetime) to increase interoperability.

    On the security front I would suggest not supporting aggressive mode as it saves having to specify crypto algorithms. I would possibly avoid RSA/X.509 certificates at least initially as it complicates things. If not specified, Openswan proposes a combination of 3DES/SHA1 DH groups 2 and 5, and 3DES/MD5 DH groups 2 and 5. I would certainly like to see the option of proposing better algorithms (AES128 as it is about as secure as 3DES but uses one third of the processing power and AES256 and higher DH groups). If we want to be able to specify algorithms, we'd need three dropdown boxes for phase1 and 2 for phase2 to allow us to generate the various options.

    I am not sure what to do about multiple LAN subnets. Openswan can handle this in a couple of ways - either separate conns or using the keyword leftsubnets instead of leftsubnet. If you allow multiple subnets automatically then you lose the ability of allowing only one subnet through the tunnel. Also, in my case, my remote Draytek does not support multiple remote subnets to Openswan. It may be that we have to allow lots of subnets to be specified and then parse the line to decide which key word to use. Perhaps one for the future.

    I've seen Apple an Android mentioned. These both use L2TP over IPSec. If you want to configure them for the future, you'd need an l2tp daemon such as this one from the same people who write Openswan, but a number of extra parameters need to be exposed when configuring Openswan and you need to be able to create a configuration file for xl2tpd as well. Also there is the possibility of allowing devices to have IP's overlapping with your own subnet. This is a little more obscure and will need the klips module of Openswan to be compiled and loaded instead of netkey. Again it could be one for the future.

    There is currently an annoying bug which the example configuration would fall prey to. If you use FQDN's instead of IP addresses for left/right, and in ipsec.secrets, if the DNS lookup fails during the DPD (dead peer detection), for example if you lose your WAN, ipsec terminates rather than waits for the WAN to recover. This is a bit unfriendly and I am waiting for a fix to it.

    I had problems in the past and wrote a watching script which pinged the remote end periodically and restarted the conn if necessary. It could be tarted up and added to anything produced here.

    I am happy to try to help with this sort of project. I'm not really a programmer but I can hack scripts. I know no php but if someone writes a basic working model I may be able to look at adding some bells and whistles.
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, September 02 2012, 08:19 AM - #Permalink
    Resolved
    0 votes
    Here is my routing table using the default updown scripts::
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
    192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
    192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
    10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
    192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    82.20.248.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
    0.0.0.0 82.20.248.1 0.0.0.0 UG 0 0 0 eth0
    The IPSec VPN is to 192.168.10.0/24 and it works fine.

    I've just checked my 6.3VM (I don't have a proper installation yet) and for the firewall, Webconfig > Network > Incoming Firewall > Allowed Incoming Connections > Add > Standard Service > IPsec still works fine and adds the necessary rules.
    The reply is currently minimized Show
  • Accepted Answer

    kfox
    kfox
    Offline
    Saturday, September 01 2012, 09:47 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    kfox wrote:
    Looks like there is a need to carry over the _updown.app (PFA) to get automagic route adding.
    I'm not with your here. Which automagic routing are you after? I've always used the default openswan updown scripts. In fact I went that way because the ClearOS (Clearconnect) ones started causing me problems with CC5.0.

    Ahh, I didn't know to look for anything other than _updown.app since that's what was listed in the 5.2 config. I see there is a default one already in there, simply named "_updown"

    The automagic routing I'm referring to is where the uppdown script adds a route for the private network on the other end of the tunnel. i.e.

    192.168.0.0 gw.gw.gw.gw 255.255.255.0 UG 0 0 0 eth0


    Cheers
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, September 01 2012, 09:01 PM - #Permalink
    Resolved
    0 votes
    kfox wrote:
    Nick Howitt wrote:
    I'll study all this later - just back from holiday - but the standard incoming IPSec firewall rule should be fine on its own. No need for custom rules unless your default outbound policy is DROP.


    I don't think there is a standard incoming IPsec rule with 6.x; in 5.x you were given an easy-click button that let you apply the rules I posted but due to the lack of an app for IPsec in 6.x we don't have that option anymore.
    That is possible but I'll need to check my VM later. The 5.2 rules were simpler than what you have and the mangle table was used for setting the mark. Again, I'll look at them later.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, September 01 2012, 08:59 PM - #Permalink
    Resolved
    0 votes
    kfox wrote:
    Looks like there is a need to carry over the _updown.app (PFA) to get automagic route adding.
    I'm not with your here. Which automagic routing are you after? I've always used the default openswan updown scripts. In fact I went that way because the ClearOS (Clearconnect) ones started causing me problems with CC5.0.

    Also disable OE with a line oe=no in config setup. It is neater compared to all the stuff at the bottom of the file. Or even better is use a late version of Openswan where it is turned off by default anyway, but I am not sure which version you need to run to have this change. 2.6.32 may be OK.
    The reply is currently minimized Show
  • Accepted Answer

    kfox
    kfox
    Offline
    Saturday, September 01 2012, 08:50 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    I'll study all this later - just back from holiday - but the standard incoming IPSec firewall rule should be fine on its own. No need for custom rules unless your default outbound policy is DROP.


    I don't think there is a standard incoming IPsec rule with 6.x; in 5.x you were given an easy-click button that let you apply the rules I posted but due to the lack of an app for IPsec in 6.x we don't have that option anymore.
    The reply is currently minimized Show
  • Accepted Answer

    kfox
    kfox
    Offline
    Saturday, September 01 2012, 08:44 PM - #Permalink
    Resolved
    0 votes
    Looks like there is a need to carry over the _updown.app (PFA) to get automagic route adding.

    You can drop it in /usr/libexec/ipsec/

    I also swapped the new ipsec.conf with the old 5.2:


    version 2.0

    #config setup
    # klipsdebug=all
    # plutodebug=all

    config setup
    protostack=netkey
    klipsdebug=none
    plutodebug=none

    conn %default
    authby=secret
    auto=start
    rightupdown=/usr/libexec/ipsec/_updown.app
    leftupdown=/usr/libexec/ipsec/_updown.app

    # Disable OE
    #-----------

    conn block
    auto=ignore

    conn private
    auto=ignore

    conn private-or-clear
    auto=ignore

    conn clear-or-private
    auto=ignore

    conn clear
    auto=ignore

    conn packetdefault
    auto=ignore

    # Tunnels defined in separate files
    #----------------------------------

    include /etc/ipsec.d/*.conf
    The reply is currently minimized Show
Your Reply