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.
Parents
  • 0
    Thanks. I see that this is to restart the entire services. I was wondering if someone knew how to restart just a specific tunnel using ipsec command. From what I gather, I've only found ways to restart the whole thing.

    The %ANY% use I think would be for road-warrior if used in the RIGHT side, but if you put some public IP for RIGHT and then RIGHTID would have a private NAT for those peers behind a NAT, setting that to %ANY% might then allow it to work regardless of the private IP of the peer router.
Reply
  • 0
    Thanks. I see that this is to restart the entire services. I was wondering if someone knew how to restart just a specific tunnel using ipsec command. From what I gather, I've only found ways to restart the whole thing.

    The %ANY% use I think would be for road-warrior if used in the RIGHT side, but if you put some public IP for RIGHT and then RIGHTID would have a private NAT for those peers behind a NAT, setting that to %ANY% might then allow it to work regardless of the private IP of the peer router.
Children
  • 0 in reply to coewar
    Thanks. I see that this is to restart the entire services. I was wondering if someone knew how to restart just a specific tunnel using ipsec command. From what I gather, I've only found ways to restart the whole thing.

    You can easily change it in the script:

    ipsec auto --down ; 
    ipsec auto --up ;

    This will be best served with a little delay between. But my experience is, that you better restart the whole stack. If you trying to reenable a specific tunnel the same errors will come back. That's why DPD has sometimes no effect. It does the right thing, but the error resist somewhere else in the stack.

    And: A restart of ipsec results in a new SA and maybe updated routes. I can restart my openswan within 5-10s, it doesn't affect running ssh connections or a backup on another tunnel! And if the connection with the changed IP is affected, the data flow has been interrupted already.

    The %ANY% use I think would be for road-warrior if used in the RIGHT side, but if you put some public IP for RIGHT and then RIGHTID would have a private NAT for those peers behind a NAT, setting that to %ANY% might then allow it to work regardless of the private IP of the peer router.

    Okay, but why do you need %ANY% as left on site-to-site? I think left=, right= and rightid=, or rightsourceip= do the trick? Or do I miss something in your setup?