Guest User!

You are not Sophos Staff.

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

    Liking the looks of this script however some things that I saw in the code that irks the programmer in me. [[:)]] 

    # In command shells like DOS or UNIX, a command returning error level of 0 means it is successful.

    TRUE=0

    FALSE=1


    1) The reversing of TRUE/FALSE will cause confusion amongst programmers. I pretty much have to stop every time there's a $TRUE or $FALSE in the code and mentally negate the result, then use the negated result in the logical operators. Using say, $SUCCESS OR $FAILURE instead would make the code easier to read.

    2) I used logical TRUE's for the debug statements as it makes sense in that context.

    Practicing what I preach, I've submitted my revision back to you for your review. Quite an elegant little piece nevertheless. [[:)]]

    EDIT: Minor update to the script. Forgot that bash doesn't have true/false predefined, you have to do so yourself.
  • 0 in reply to TheDrew 

    # In command shells like DOS or UNIX, a command returning error level of 0 means it is successful.

    TRUE=0

    FALSE=1


    1) The reversing of TRUE/FALSE will cause confusion amongst programmers. I pretty much have to stop every time there's a $TRUE or $FALSE in the code and mentally negate the result, then use the negated result in the logical operators. Using say, $SUCCESS OR $FAILURE instead would make the code easier to read.

    2) I used logical TRUE's for the debug statements as it makes sense in that context.

    Practicing what I preach, I've submitted my revision back to you for your review. Quite an elegant little piece nevertheless. [:)]



    I agree with you. I don't do much BASH programming so didn't know what to name those values as testing just for 0 or 1 confuses me even more than an obvious alias like TRUE/FALSE.  But SUCCESS/FAILURE seems like a fine compromise to that. Thanks.
Reply
  • 0 in reply to TheDrew 

    # In command shells like DOS or UNIX, a command returning error level of 0 means it is successful.

    TRUE=0

    FALSE=1


    1) The reversing of TRUE/FALSE will cause confusion amongst programmers. I pretty much have to stop every time there's a $TRUE or $FALSE in the code and mentally negate the result, then use the negated result in the logical operators. Using say, $SUCCESS OR $FAILURE instead would make the code easier to read.

    2) I used logical TRUE's for the debug statements as it makes sense in that context.

    Practicing what I preach, I've submitted my revision back to you for your review. Quite an elegant little piece nevertheless. [:)]



    I agree with you. I don't do much BASH programming so didn't know what to name those values as testing just for 0 or 1 confuses me even more than an obvious alias like TRUE/FALSE.  But SUCCESS/FAILURE seems like a fine compromise to that. Thanks.
Children
No Data