Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 1 subscriber
  • Views 34045 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Site-to-Site IPSec VPN between Astaro and Openswan (routing, parameters)

stufe3
Hello @all,

I'm trying to create a Site-to-Site VPN between an Astaro Security Gateway (v8.301) and openswan (2.6.28 on ubuntu server). Auth is handled through RSA-Keys on both sides. Currently I'm able to establish the IPSec tunnel without errors (STATE_QUICK_R2: IPSec SA established tunnel mode {..para..}), but I can't send packets over the connection in any direction. 

This is my setup:
Site-to-site between 10.10.10.0/24 (office) and 192.168.100.0/24 (branch)

10.10.10.0/24===10.10.10.1office.dyn.ip---{internet}---branch.dyn.ip192.168.100.1===192.168.100.10192.168.100.0/24

Openswan is located behind a NAT-Router. Because the fact that everything is fine with IPSec (IKE, ESP, SA, RSA-Pubkeys) itself I assume that the problem don't relate to this parameters. No, I'm sure I made something wrong related to the routing. 

So without any specific configuration files, just to understand the topic and for qualified bug hunting:

What do I have to put inside openswan config (local=left and remote=right) for left and right, especially behind a NAT-Router? My current settings:
left="192.168.100.10"
leftnexthop=%defaultroute
leftsourceip="192.168.178.10"
leftsubnet="192.168.178.0/24"
right="office.dyn.ip"
rightsourceip="10.10.10.1"
#rightnexthop=%defaultroute
rightsubnet="10.10.10.0/24"

My current routing table on openswan server:
[FONT="Courier New"]root@openswan:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.100.1   0.0.0.0         UG        0 0          0 eth0
10.10.10.0     192.168.100.1   255.255.255.0   UG        0 0          0 eth0
192.168.100.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0[/FONT]

Shouldn't 10.10.10.0 point to the gateway 192.168.100.10, because the tunnel starts/ends here? 

[FONT="Courier New"]root@openswan:~# ip xfrm policy show
src 192.168.100.0/24 dst 10.10.10.0/24 
dir out priority 2344 
tmpl src 192.168.100.10 dst 1.1.1.1(


This thread was automatically locked due to age.
  • 0
    oh cool thanks for the ipsec command.
    I didn't know about the restart not affecting things..  not sure I trust that yet but I'll play with it.

    I would not use %ANY% for LEFT. But I would use this:
    left=
    leftid=
    right=
    rightid=%ANY%   to allow their NAT IP be whatever they want it to be without affecting the connection.

    Though I'm not an expert if it's RIGHTID or RIGHTSOURCEIP.
  • 0
    Apparently the command syntax you gave was just for OpenSWAN. Astaro uses StrongSWAN and synax is a little different:

    Usage: ipsec command argument ...
    where command is one of:
            start|restart  arguments...
            update|reload|stop
            up|down|route|unroute 
            status|statusall []
            ready
            listalgs|listpubkeys|listcerts [--utc]
            listcacerts|listaacerts|listocspcerts [--utc]
            listacerts|listgroups|listcainfos [--utc]
            listcrls|listocsp|listcards|listall [--utc]
            leases [ [
    ]]
            rereadsecrets|rereadgroups
            rereadcacerts|rereadaacerts|rereadocspcerts
            rereadacerts|rereadcrls|rereadall
            purgeocsp|purgeike
            scencrypt|scdecrypt  [--inbase ] [--outbase ] [--keyid ]
            openac
            pluto
            scepclient
            secrets
            starter
            version
            whack
            stroke


    Linux strongSwan U4.4.1git20100610/K2.6.32.54-9.g924d2d5-virtual
    Institute for Internet Technologies and Applications
    University of Applied Sciences Rapperswil, Switzerland
    See 'ipsec --copyright' for copyright information.
  • 0 in reply to coewar
    Apparently the command syntax you gave was just for OpenSWAN. Astaro uses StrongSWAN and synax is a little different:

    Usage: ipsec command argument ...
    where

    ... snip ...


    Yes it is for openswan, for strongswan it is:

    [FONT="Courier New"]ipsec down ;
    ipsec up ;
    ipsec route ;
    ipsec unroute ;[/FONT]

    But astaro may differ here, check for the chroot enviroment...
  • 0 in reply to stufe3
    And as addition: as you may know, Astaro uses some random NameFoo for the tunnel names, like S_REF***x. Also the configuration will be rewritten everytime something is changing, IP-change, click on/off... You might have some trouble in scripting that.
  • 0
    Yes, I know about the Astaro config issue... In the past I created a way to change the .default script so that it would use that. But it's set up to be quite difficult to adjust past the GUI's capability.
  • 0
    Gosh darn it.

    So it seems you're on the right track on the UP/DOWN ROUTE/UNROUTE commands actually not helping. When that specific tunnel goes "bad", doing that causes the UP command to just sit and eventually timeout.  While the connection is "good" though, doing those commands works fine.

    So I go into the GUI, disable and enable. When doing that in the GUI it actually deletes the whole configuration and I can't find how to do that in the version of StrongSWAN we're running here. There is no DELETE commandline option.

    From what I can tell, when using the GUI to do that, it does not take down the other tunnels.

    I can't risk taking them down because we have transactions that fly through the system and doing a total reset could knock something in-flight out and that is not something I want to script.
  • 0 in reply to coewar
    I would not use %ANY% for LEFT. But I would use this:
    left=
    leftid=
    right=
    rightid=%ANY%   to allow their NAT IP be whatever they want it to be without affecting the connection.


    Okay now I got it. 
    rightid and leftid are only the identifier used for IKE, you can put "@hostname.fqdn.com", "ip", "my@email.com". As far as I know you don't have to put existing hostnames or IPs here, but I read something about to better do so. Otherwise there might be some strange behavior.
     
    rightsourceip tells your ipsec from what ip the packets of the remote endpoint comes from, normally you don't need it. It is useful for strongswan/openswan behind NAT setups.

    rightid=%ANY% tells your local ipsec to accept any identifier the other side comes around. I'm not sure if this is working and you won't do this in a normal scenario, even more you should know about the remote identifier. For instance you can set "ONE" identifier for the astaro, and it will be used for "ALL" connections. Which is fine in most scenarios.

    If you want access to one or more subnets behind the VPN, you should put it in leftsubnet/rightsubnet on two or more configurations. Remember VPNs are cheap. Astaro clones the configuration in the config and put it togehter in the GUI. You will end up with S_REF_IpsAAAA_0 and S_REF_IpsAAAA_1.

    Just my 2 cents.
  • 0
    I only gave you some of the configs in the topic of the NATed networks. I always set up each one with some subnets.. and for some clients in the same configuration that has more than 1 network I see how Astaro creates separate tunnel configurations or whatever.. all that's fine.

    The issue with this particular tunnel going down and not coming up after some time is not happening to my other ones.. but in general it's all on an AWS Astaro and I'm going to try on a different Astaro to try to eliminate the NAT confusing Astaro.
  • 0 in reply to coewar
    Gosh darn it.

    So it seems you're on the right track on the UP/DOWN ROUTE/UNROUTE commands actually not helping. When that specific tunnel goes "bad", doing that causes the UP command to just sit and eventually timeout.  While the connection is "good" though, doing those commands works fine.

    So I go into the GUI, disable and enable. When doing that in the GUI it actually deletes the whole configuration and I can't find how to do that in the version of StrongSWAN we're running here. There is no DELETE commandline option.

    From what I can tell, when using the GUI to do that, it does not take down the other tunnels.

    Is your configuration still okay at this moment? Then you maybe can try to reload the secrets and certs and the just reload the config? A normal reload of the config file triggers the deletion of the connections and reconfiguration without losing connectivity. You got new desciptions and new SAs, same happens if there is a TTL timeout.

    ...but use with caution, I'm not a stongswan expert.

    I can't risk taking them down because we have transactions that fly through the system and doing a total reset could knock something in-flight out and that is not something I want to script.

    I totally understand that.