Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 1 subscriber
  • Views 8876 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

Astaro StrongSWAN ipsec wrapper script

coewar
Uploaded in this post is a script file  vpn.sh.txt.
(.txt extension so uploader would let me upload.)

The file has instructions on even how to put it onto your Astaro device through the Terminal.

This script makes it a bit more human friendly to manage and monitor the IPSec VPN connections. But the BEST thing is this: I've had problems with 1 or 2 (out of 30) VPN connections that would go down and stay down until I manually reset them. So one thing this script can do is "monitor" a specific connection and automatically reset it if it detects that it is down.

Quite annoying and may or may not be related to Astaro.. threads seem to try to point fingers at certain types of Cisco routers.

Anyway, because the Astaro router is so brilliantly deployed on a Linux system, that allows Linux folks to fix things and make improvements without having to wait for or get denied by Support. 

In order to do this, you have to SSH into the router and then log into the 'root' account. Doing this will certainly not be supported by their support, however I have had very little that is actually supported from them so doing it by utilizing Linux itself is much more supportable on the Internet. I feel it is almost a crime to provide this router on Linux and start closing down those doors if they choose to do it. Instead of providing means for Linux experts to customize their Astaro functionality, they create roadblocks to prevent it.

So give this script a shot. I'm using it. I may post updates to any fixes if I find them.


This thread was automatically locked due to age.
Parents
  • 0
    Hi everyone. I made an update to the script. It now allows you to include pinging for IP's or testing for IP and ports as part of the VPN monitoring. If they fail it will reset the VPN. So you can put in the protected IP's on the other side to watch for.

    Now why would I need that? Well, because it has happened more than once where the VPN indicates it's running fine but traffic does not get through. And after resetting the VPN suddenly it works. BEATS ME!! but I figured it wasn't much more effort to add it.

    Just for fun, here is the "help" from the script that shows what it can do:


    Commands for this script:

    list        Lists the VPN connection names to use for other commands.

    status      Shows if it detects the named connections listed as parameters
                as UP or DOWN. Shows status for all connections if none listed.

    reset       Resets named connections listed as parameters.

    log         Tails the encrypted TCP dump of the named connection.

    monitor     Watches the status of a named connection and automatically resets
                if it goes down. Also has ability to use ping or an IP[[:P]]ort to
                check while monitoring. If any of the pings or tests or an IP[[:P]]ort
                fail, the VPN will be reset. This is in result of sometimes having
                the VPN indicate it's up while traffic stops working.

    Examples:   (assuming you name this script just 'vpn')
    vpn monitor S_REF_IpsSitVpn***_0 ping 192.168.0.1 ping 192.168.0.2
                This will check the VPN tunnel and also ping those IP's.

    vpn monitor S_REF_IpsSitVpn***_0 ping 192.168.0.1 ipport 192.168.0.2:80
                This will ping 192.168.0.1 and check port 80 on 192.168.0.2
                in the very possible case the ICMP ping is not allowed on a 
                firewall.

    If you specify  --debug  as the first parameter, more verbose output will 
    be created.
  • 0 in reply to coewar
    Hi everyone. I made an update to the script. It now allows you to include pinging for IP's or testing for IP and ports as part of the VPN monitoring. If they fail it will reset the VPN. So you can put in the protected IP's on the other side to watch for.


    Nice, we also have that kind of connections.
    But sadly, that ping and monitor doesn't work (at least for us).
    For example, the tunnel is configured from one IP address in our LAN to another IP address in the remote LAN.
    Ping from the Astaro doesn't work as it has - of course - another IP, it only works from the local IP that's configured in the tunnel.
    So, monitoring from Astaro this way always fails for all connections.

    Which brings me to another idea. Maybe it's possible to have that monitoring run on a local (Windows) client and if ping fails (for a spezified time) a script on the Astaro is executed to reconnet the tunnel (rsh or something like that, maybe?).

    Ciao, Alfred
  • 0 in reply to serpi
    Nice, we also have that kind of connections.
    But sadly, that ping and monitor doesn't work (at least for us).
    For example, the tunnel is configured from one IP address in our LAN to another IP address in the remote LAN.
    Ping from the Astaro doesn't work as it has - of course - another IP, it only works from the local IP that's configured in the tunnel.
    So, monitoring from Astaro this way always fails for all connections.

    Which brings me to another idea. Maybe it's possible to have that monitoring run on a local (Windows) client and if ping fails (for a spezified time) a script on the Astaro is executed to reconnet the tunnel (rsh or something like that, maybe?).

    Ciao, Alfred


    Ahh! Good point! The way we operate is actually we have the encrypted IP for our side be the same as the router's public IP. In some cases that causes problems and so on the router I just make up an IP and use that. Then any traffic going into the router destined for the other side we could SNAT it. But we normally have our servers SSH tunnel into the router. Then everything going through it acts like it's coming from it. This way our servers can be anywhere and we can still use the VPN. And those connections are SSH encrypted to the router. And so I make a SNAT rule that when it's coming from the router make it look like it's coming from its public IP rather than its private one.

    None-the-less, I think you have 2 options.
    #1 - make some SNAT rules to make it work.
    #2 - the nc command actually has options to assign the source IP and even port. Just try using the   nc   command with those options to test the IP/Port and let me know how it works. If it works for you that way, then I can enhance the script to allow that on the command line (or someone else can.)

    Here is the manpage for the nc command: nc(1): arbitrary TCP/UDP connections/listens - Linux man page

    I think I'll publish this script on GitHub or their Gist.
  • 0 in reply to coewar

    None-the-less, I think you have 2 options.
    #1 - make some SNAT rules to make it work.
    #2 - the nc command actually has options to assign the source IP and even port.


    nc also doesn't work as it is only possible to select a source ip that is attached to the Astaro but these aren't part of the VPN connection.
    And I don't know what SNAT rules I could create, maybe you have an idea/example?
    It is not possible for me to change the VPN parameter, the other sides are all not under our control.
    We are a hospital and the VPN connections are used to exchange patient data with other hospitals, offices and so on.
    Most connections are one ip on our side to another on the other side so I don't see how any ip check on the Astaro could work as their ip(s) are never part of the configuration.
  • 0 in reply to serpi
    nc also doesn't work as it is only possible to select a source ip that is attached to the Astaro but these aren't part of the VPN connection.
    And I don't know what SNAT rules I could create, maybe you have an idea/example?
    It is not possible for me to change the VPN parameter, the other sides are all not under our control.
    We are a hospital and the VPN connections are used to exchange patient data with other hospitals, offices and so on.
    Most connections are one ip on our side to another on the other side so I don't see how any ip check on the Astaro could work as their ip(s) are never part of the configuration.


    Hmm..  That's unfortunate. Well, for test purposes, try adding an Additional IP to the router. In Astaro you can add additional IP's and attach them to an existing NIC. Then perhaps the NC command will let you use it.

    Otherwise, the SNAT rule would look something like this:
    192.168.0.10 - Pretend that's your private source server's IP.
    192.168.0.1  - Pretend that's your Astaro's private IP.
    172.16.5.5    - Pretend that's your partner's protected IP on other side of VPN.

    SNAT rule would be: 
    Traffic source: 192.168.0.1
    Traffic service: Any
    Traffic dest: 172.16.5.5    
    NAT mode: SNAT
    Source: 192.168.0.10
    Source Service: blank
    Log packets and Automatic FW rule so you can see it going through and allow it to do so.
    There is also the Advanced option "Rule applies to IPSec packets". I don't normally use that, but if it does not work, you can try with it.

    What I did not think about, however, is that the returning data might not stop at the router. If that's the case, then simply your NC command (or telnet) will just not get a response. However you should be able to see the traffic go through your VPN tunnel if you watch the output. You can watch the output via the script with  "vpn log S_REF_***x" in a separate command window.
  • 0 in reply to serpi

    It is not possible for me to change the VPN parameter, the other sides are all not under our control.
    We are a hospital and the VPN connections are used to exchange patient data with other hospitals, offices and so on.
    Most connections are one ip on our side to another on the other side so I don't see how any ip check on the Astaro could work as their ip(s) are never part of the configuration.


    By the way, you do not have to change the VPN parameters to set up the way we are. You can keep those parameters the same. Then with that SNAT rule I posted just now traffic from the router would get there, and then your source PC can SSH into the router and actually suddenly you can have any PC do the same. The only thing is that if the other side needs to send data back, you'd need to add a DNAT rule to make the traffic actually get to your PC.

    After thinking about this, I think the SNAT rule I posted previously should work just fine. This is basically what we do. So your test scenario using the SNAT rule would actually be how we do production traffic.
  • 0 in reply to coewar
    Then with that SNAT rule I posted just now traffic from the router would get there, and then your source PC can SSH into the router and actually suddenly you can have any PC do the same. 


    The SSH part would be actually setting up SSH tunnels. You can do that using plink or BitVise Tunnelier SSH client as a couple of examples. So what that would do is on your PC you'd have some 127.x.x.x IP (you make it up) and some Port that you'd specify in your application and sending to that IP/Port would send the traffic right to the router and it would be encrypted.
Reply
  • 0 in reply to coewar
    Then with that SNAT rule I posted just now traffic from the router would get there, and then your source PC can SSH into the router and actually suddenly you can have any PC do the same. 


    The SSH part would be actually setting up SSH tunnels. You can do that using plink or BitVise Tunnelier SSH client as a couple of examples. So what that would do is on your PC you'd have some 127.x.x.x IP (you make it up) and some Port that you'd specify in your application and sending to that IP/Port would send the traffic right to the router and it would be encrypted.
Children
No Data