Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 1 subscriber
  • Views 34031 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.
Parents
  • 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
    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.
Reply
  • 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.
Children
No Data