Guest User!

You are not Sophos Staff.

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)

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
  • I could have helped if I signed on to see this. But I have to re-iterate NAT and VPN are TOTALLY FINE AND GOOD. The problem is Astaro's GUI does not expose the complete  StrongSWAN configuration that it uses. Only a couple of the configurations would be needed to expose and you would not have any issues. You can do this via hacking the config files, but that is not supported.  Check out thread about Astaro VPN with NAT.

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/54446
  • I could have helped if I signed on to see this. But I have to re-iterate NAT and VPN are TOTALLY FINE AND GOOD.

    Hi coewar and thanks for replying.

    The problem is Astaro's GUI does not expose the complete  StrongSWAN configuration that it uses. Only a couple of the configurations would be needed to expose and you would not have any issues. You can do this via hacking the config files, but that is not supported.
     
    I know, but I read the configuration under /var/chroot-ipsec/etc and found everything okay for my setup. In my case it was a broken linux package which offered SHA2 but did not implemented it properly. As a result I got the IPSec up and running without errors on both sides, and I saw encrypted traffic. Without SHA2 build in on one side, there simple couldn't talk to each other.

    Fun fact: Even with debugging set to all on openswan - crypto debug is then also turned on - I did not see one helping output line in the log. Something like: "...hey they send some encryption we could not verify ..." :|

    Check out thread about Astaro VPN with NAT.

    http://www.astaro.org/astaro-gateway-products/vpn-site-site-remote-access/40679-issues-ipsec-site-site-asg-behind-front-nat.html


    Yes I read that. I still have DPD and NAT issue I could not solve properly. But it seems that DPD is working and from time to time (more 30-40% at all) it simply doesn't reload the the IPSec Stack with the new IPs after declaring the peer as dead (on linux/openswan). The reason is nearly everytime a changed dynamic IP on one or both sides, not the SA itself. 

    My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

    Regards Björn


  • My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

    Regards Björn


    Could you share such a script? I have all my VPN remote gateways configured to Initiate connection mode, and I can't believe it but I have a few tunnels now that might go down and the all I do is disable and re-enable them to bring them up!???  What the heck is the DPD for? It's not working. So I have to hack something in so that it ACTUALLY restarts when it detects that it's down. Gosh I hope v9 fixes that and soon. It is silly.
Reply


  • My astaro was set up as "respond only" so I couldn't blame it. The solution was writing a simple script that runs checks on the DNS-entries and restarts the service if needed. Uncool like hell - but working.

    Regards Björn


    Could you share such a script? I have all my VPN remote gateways configured to Initiate connection mode, and I can't believe it but I have a few tunnels now that might go down and the all I do is disable and re-enable them to bring them up!???  What the heck is the DPD for? It's not working. So I have to hack something in so that it ACTUALLY restarts when it detects that it's down. Gosh I hope v9 fixes that and soon. It is silly.
Children
  • Hi coewar,

    my experience is that openswan is not designed with dynamic hosts in mind and NAT brings a lot of trouble. DPD is working and doing what it should do, declaring peers as dead and put some action to the ipsec stack - like hold or restart. But some other problems avoiding the renogiating of the SA, especially behind NAT. I can't pin that exaclty but I guess that there are some paramters for the IKE handshake are not updated correctly. 

    For me the best solution is to restart openswan on linux, I'm not restarting anything on astaros side! A restart (stop) brings them down immediately: "deleting connection..., deleting state (STATE_MAIN_I1, STATE_MAIN_I4 and STATE_QUICK_I2)". 

    and the start it brings them up again - most of the times within the first attempt.

    My script is a very basic bash script for linux, if you are interested I will post it next time I have access to it.

    Regards Björn