Guest User!

You are not Sophos Staff.

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

Use Astaro site-to-site with VPN proxy service?

LazLong
Can I use Astaro's site-to-site VPN with an IPSEC VPN proxy provider/service?


This thread was automatically locked due to age.
  • 0
    As long as you can get the settings exactly the same on both ends, it should work.

    Barry
  • 0 in reply to BarryG
    If you find a provider that support this, let us know.

    Thx
  • 0 in reply to BarryG
    As long as you can get the settings exactly the same on both ends, it should work.

    Barry


    Yeah, that's what I thought. But getting the settings the same isn't proving so easy. What I have is an IPSec vpn proxy service that provides a certificate and then authenticates you with an ID and password. It works with Window XP+ built-in IPSec connectivity. Unfortunately I haven't been able to get it working with Astaro.

    Here are the steps I took and the settings I used.

    First I imported the VPN service's cert. The password I used is correct.



    Next I set up the remote gateway. I enabled XAUTH and used the ID and password pair Giganews' XP VPN instructions give.



    Then I created the IPSec connection. I chose the "Microsoft Windows" policy using the logic that I'm using Giganews' XP instructions.



    After saving the connection settings Astaro enables the connection.



    However, the Dashboard's Site-to-Site VPN tunnel status shows the following (sorry, can't use an image as the board only allows four images per post).

    SA:  10.8.26.0/24=10.8.26.254  138.199.67.149=0.0.0.0/0
    VPN ID: dikobraz.tanstaafl.cc
    Error: No connection

    Here is the log output when I enable the IPSec connection on the 'Connections' tab of the IPSec Dashboard:

    2011:09:12-23:52:53 dikobraz ipsec_starter[9698]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2011:09:12-23:52:53 dikobraz pluto[9705]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2011:09:12-23:52:53 dikobraz pluto[9705]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve 
    2011:09:12-23:52:53 dikobraz pluto[9705]:   including NAT-Traversal patch (Version 0.6c)
    2011:09:12-23:52:53 dikobraz pluto[9705]: Using Linux 2.6 IPsec interface code
    2011:09:12-23:52:53 dikobraz ipsec_starter[9704]: pluto (9705) started after 20 ms
    2011:09:12-23:52:53 dikobraz pluto[9705]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_BgjAvdUcuF.pem'
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerGiganCertVerif.pem'
    2011:09:12-23:52:53 dikobraz pluto[9705]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2011:09:12-23:52:53 dikobraz pluto[9705]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2011:09:12-23:52:53 dikobraz pluto[9705]: Changing to directory '/etc/ipsec.d/crls'
    2011:09:12-23:52:53 dikobraz pluto[9705]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2011:09:12-23:52:53 dikobraz pluto[9705]: listening for IKE messages
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface eth1/eth1 10.8.26.254:500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface eth1/eth1 10.8.26.254:4500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface eth0/eth0 108.83.100.13:500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface eth0/eth0 108.83.100.13:4500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface lo/lo 127.0.0.1:500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface lo/lo 127.0.0.1:4500
    2011:09:12-23:52:53 dikobraz pluto[9705]: adding interface lo/lo ::1:500
    2011:09:12-23:52:53 dikobraz pluto[9705]: loading secrets from "/etc/ipsec.secrets"
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded private key from 'REF_TcKJTYwUSK.pem'
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded XAUTH secret for smbrannon C=US ST=Texas L=Austin O=Giganews-Inc CN=giganews-client E=admin@giganews.com 
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded host certificate from '/etc/ipsec.d/certs/REF_TcKJTYwUSK.pem'
    2011:09:12-23:52:53 dikobraz pluto[9705]:   loaded host certificate from '/etc/ipsec.d/certs/REF_IpsX501_ea40c07a.pem'
    2011:09:12-23:52:53 dikobraz pluto[9705]: added connection description "S_REF_IpsSitGiganVpnUk_0"
    2011:09:12-23:52:53 dikobraz pluto[9705]: "S_REF_IpsSitGiganVpnUk_0" #1: initiating Main Mode
    2011:09:12-23:52:53 dikobraz pluto[9705]: added connection description "X_REF_IpsSitGiganVpnUk_0"
    2011:09:12-23:52:53 dikobraz pluto[9705]: added connection description "X_REF_IpsSitGiganVpnUk_1"
    2011:09:12-23:52:53 dikobraz pluto[9705]: added connection description "X_REF_IpsSitGiganVpnUk_2"
    2011:09:12-23:52:53 dikobraz pluto[9705]: added connection description "X_REF_IpsSitGiganVpnUk_3"


    I tried pinging the remote gateway from my desktop machine and got a return. A tracert shows traffic hitting the ASG (it's my router) and then my ISP's router, and not the Giganews VPN. Grrr...

    Next I changed the remote gateway's "Remote Networks" setting to the built-in "Internet IPv4" definition and restart the IPSec connection and there was no change.

    I'm stumped. Anyone have any suggestions?
  • 0
    In the 'Remote Gateway', do use the default "Internet IPv4" object instead of "Any IPv4".

    In the 'IPsec Connection', use the External interface instead of Internal.

    Any luck now?

    Cheers - Bob
  • 0 in reply to BAlfson
    In the 'Remote Gateway', do use the default "Internet IPv4" object instead of "Any IPv4".

    In the 'IPsec Connection', use the External interface instead of Internal.

    Any luck now?

    Cheers - Bob


    Unfortunately no. 

    I had actually originally tried using the External interface as the terminus, but not concurrently with "Internet IPv4," instead it was with "Any IPv4." Anyway, here is the log output I get now in case it provides any clues.

    2011:09:13-07:21:28 dikobraz ipsec_starter[7150]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
    2011:09:13-07:21:28 dikobraz pluto[7158]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
    2011:09:13-07:21:28 dikobraz ipsec_starter[7156]: pluto (7158) started after 40 ms
    2011:09:13-07:21:28 dikobraz pluto[7158]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve 
    2011:09:13-07:21:28 dikobraz pluto[7158]:   including NAT-Traversal patch (Version 0.6c)
    2011:09:13-07:21:28 dikobraz pluto[7158]: Using Linux 2.6 IPsec interface code
    2011:09:13-07:21:29 dikobraz pluto[7158]: loading ca certificates from '/etc/ipsec.d/cacerts'
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_BgjAvdUcuF.pem'
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerGiganCertVerif.pem'
    2011:09:13-07:21:29 dikobraz pluto[7158]: loading aa certificates from '/etc/ipsec.d/aacerts'
    2011:09:13-07:21:29 dikobraz pluto[7158]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
    2011:09:13-07:21:29 dikobraz pluto[7158]: Changing to directory '/etc/ipsec.d/crls'
    2011:09:13-07:21:29 dikobraz pluto[7158]: loading attribute certificates from '/etc/ipsec.d/acerts'
    2011:09:13-07:21:29 dikobraz pluto[7158]: listening for IKE messages
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface eth1/eth1 10.8.26.254:500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface eth1/eth1 10.8.26.254:4500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface eth0/eth0 108.83.100.13:500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface eth0/eth0 108.83.100.13:4500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface lo/lo 127.0.0.1:500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface lo/lo 127.0.0.1:4500
    2011:09:13-07:21:29 dikobraz pluto[7158]: adding interface lo/lo ::1:500
    2011:09:13-07:21:29 dikobraz pluto[7158]: loading secrets from "/etc/ipsec.secrets"
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded private key from 'REF_TcKJTYwUSK.pem'
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded XAUTH secret for smbrannon C=US ST=Texas L=Austin O=Giganews-Inc CN=giganews-client E=admin@giganews.com 
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded host certificate from '/etc/ipsec.d/certs/REF_TcKJTYwUSK.pem'
    2011:09:13-07:21:29 dikobraz pluto[7158]:   loaded host certificate from '/etc/ipsec.d/certs/REF_IpsX501_ea40c07a.pem'
    2011:09:13-07:21:29 dikobraz pluto[7158]: added connection description "S_REF_IpsSitGiganVpnUk_0"
    2011:09:13-07:21:29 dikobraz pluto[7158]: "S_REF_IpsSitGiganVpnUk_0" #1: initiating Main Mode
    2011:09:13-07:21:29 dikobraz pluto[7158]: added connection description "X_REF_IpsSitGiganVpnUk_0"
    2011:09:13-07:21:29 dikobraz pluto[7158]: added connection description "X_REF_IpsSitGiganVpnUk_1"
    2011:09:13-07:21:29 dikobraz pluto[7158]: added connection description "X_REF_IpsSitGiganVpnUk_2"
    2011:09:13-07:21:29 dikobraz pluto[7158]: added connection description "X_REF_IpsSitGiganVpnUk_3"

    I appreciate your help with this.
  • 0
    You aren't even getting a response from 138.199.67.149, but that IP is uk1.vpn.giganews.com.  That leaves the Policy which must have IKE settings that don't match.  The "Microsoft Windows" policy is old, slow technology.  "AES 128 PFS" is as secure, but is much faster, so maybe you could get them to use it.

    Cheers - Bob
  • 0 in reply to BAlfson
    What does the green status mean on the "Connections" tab of the IPSec window on the dashboard? Simply that the entries are valid, but noting to do with connectivity?

    Is disabling and reenabling the IPSec connection on the "Connections" tab a valid way to ensure that settings are reloaded when I make a change to the Site-to-Site VPN settings?
  • 0
    What does the green status mean on the "Connections" tab of the IPSec window on the dashboard? Simply that the entries are valid, but noting to do with connectivity?

    All it means is that the rule has been activated - it might be totally incorrect.

    Is disabling and reenabling the IPSec connection on the "Connections" tab a valid way to ensure that settings are reloaded when I make a change to the Site-to-Site VPN settings?
     
    That's not necessary.  Whenever you make a configuration change, the Connection is dropped and re-established.

    Cheers - Bob
    PS The other possibility is that Giganews doesn't have their side configured to work with you yet.
    PPS I just googled and found information that Giganews uses VyperVPN, and that they support only PPTP and L2TP over IPsec - you can't connect with the Astaro at all, as it only offers VPN servers, and not the client side software.

    Apparently, for an extra $5/month, you can get an OpenVPN connection, and, with help from one of the guru's here, you might be able to make that work.
  • 0 in reply to BAlfson

    PS The other possibility is that Giganews doesn't have their side configured to work with you yet.
    PPS I just googled and found information that Giganews uses VyperVPN, and that they support only PPTP and L2TP over IPsec - you can't connect with the Astaro at all, as it only offers VPN servers, and not the client side software.

    Apparently, for an extra $5/month, you can get an OpenVPN connection, and, with help from one of the guru's here, you might be able to make that work.


    Thanx. I guess I didn't understand that L2TP over IPSec isn't supported by ASG's IPSec site-to-site. Hurm....

    Using Site-to-Site over SSL for an extra $5/mo wouldn't put me into the poor house. I guess I'll try that next.

    I have another question. It appears from the docs that the 'Automatic Firewall rules' check box simply pokes a hole in the firewall for this new traffic, and doesn't implement any other rules. I will have to define a whole new set of rules to protect my internal network from this VPN hole I punch in my firewall, correct?

    I appreciate your helping me with this....
  • 0
    Don't use the Automatic Firewall rules; just create a rule for each of your LANs for the outgoing traffic.

    Barry