none
Connecting to Virtual Network Gateway via OpenSwan RRS feed

  • Question

  • I'm using OpenSwan to connect to my Virtual Network's Gateway, but the very first packets fail to be exchanged (preventing key exchange, etc.). A quick tcpdump shows packets like this (removed my gateway IP):

    07:22:40.439205 IP 10.0.0.35.isakmp > 168.xx.xx.xxx.isakmp: isakmp: phase 1 I ident
    07:22:57.101864 IP 168.xx.xx.xxx.1032 > 10.0.0.35.isakmp: isakmp: phase 1 I ident

    Is there any reason the gateway is using the port 1032 rather than the normal isakmp port (500, I believe)? It seems to be ignoring all the packets openswan sends it on port 500. I've established successful connections via openswan with other servers via port 500, but I can't configure it to change the port it sends messages on. Any ideas what to do here? I have nat traversal enabled, but i'm not sure if that's relevant here.

    Thanks!


    • Edited by vinod_ Friday, October 5, 2012 6:20 AM
    Wednesday, October 3, 2012 7:38 AM

Answers

  • I ended up setting iptables rules to forward packets to the right port. For anyone looking to use OpenSwan rather than TMG, and still preserve their sanity, here's what I did:

    sudo iptables -t nat -A OUTPUT --destination 168.xxx.xxx.xxx  -p udp --dport 500 -j DNAT --to-destination 168.xxx.xxx.xxx:1032
    sudo iptables -t nat -A OUTPUT --destination 168.xxx.xxx.xxx  -p udp --dport 4500 -j DNAT --to-destination 168.xxx.xxx.xxx:1032

    where 168.xxx.xxx.xxx is the gateway IP address. The ipsec.conf configuration was:

    conn azure-1
            left=10.0.0.35 # This is the private IP of the OpenSwan instance you're running these commands on
            leftsubnet=10.0.10.0/24 # Local subnet
            rightid=10.50.10.8 # This is the private IP of the gateway instance on the Azure side. Don't set rightid to start off with, and you'll see errors in your logs that show you the private instance IP.
            right=168.xxx.xxx.xxx
            rightsubnet=10.50.0.0/16 # Azure-side subnet
            authby=secret
            auto=start
            auth=esp
            rekey=yes
            keyingtries=0
            keyexchange=ike
            ike=aes128-sha1;modp1024 
            esp=aes128-sha1;modp1024
            ikelifetime=28800s
            keylife=3600s
            pfs=no

    And my ipsec.secrets file entry (use gateway public IP to start off with, and when you know what the internal IP is, swap it out after modifying ipsec.conf) :

    10.0.0.35 10.50.10.8 : PSK "secretkeysecretkeysecretkeysecretkey"

    I haven't tested routing completely yet, but at least I have the tunnels somewhat up. You can verify this by trying to ping the internal IP of the and via `sudo service ipsec status` and `sudo ip xfrm state`. Good luck!


    • Marked as answer by vinod_ Friday, October 5, 2012 6:31 AM
    • Edited by vinod_ Friday, October 5, 2012 6:42 AM formatting
    Friday, October 5, 2012 6:31 AM

All replies

  • I ended up setting iptables rules to forward packets to the right port. For anyone looking to use OpenSwan rather than TMG, and still preserve their sanity, here's what I did:

    sudo iptables -t nat -A OUTPUT --destination 168.xxx.xxx.xxx  -p udp --dport 500 -j DNAT --to-destination 168.xxx.xxx.xxx:1032
    sudo iptables -t nat -A OUTPUT --destination 168.xxx.xxx.xxx  -p udp --dport 4500 -j DNAT --to-destination 168.xxx.xxx.xxx:1032

    where 168.xxx.xxx.xxx is the gateway IP address. The ipsec.conf configuration was:

    conn azure-1
            left=10.0.0.35 # This is the private IP of the OpenSwan instance you're running these commands on
            leftsubnet=10.0.10.0/24 # Local subnet
            rightid=10.50.10.8 # This is the private IP of the gateway instance on the Azure side. Don't set rightid to start off with, and you'll see errors in your logs that show you the private instance IP.
            right=168.xxx.xxx.xxx
            rightsubnet=10.50.0.0/16 # Azure-side subnet
            authby=secret
            auto=start
            auth=esp
            rekey=yes
            keyingtries=0
            keyexchange=ike
            ike=aes128-sha1;modp1024 
            esp=aes128-sha1;modp1024
            ikelifetime=28800s
            keylife=3600s
            pfs=no

    And my ipsec.secrets file entry (use gateway public IP to start off with, and when you know what the internal IP is, swap it out after modifying ipsec.conf) :

    10.0.0.35 10.50.10.8 : PSK "secretkeysecretkeysecretkeysecretkey"

    I haven't tested routing completely yet, but at least I have the tunnels somewhat up. You can verify this by trying to ping the internal IP of the and via `sudo service ipsec status` and `sudo ip xfrm state`. Good luck!


    • Marked as answer by vinod_ Friday, October 5, 2012 6:31 AM
    • Edited by vinod_ Friday, October 5, 2012 6:42 AM formatting
    Friday, October 5, 2012 6:31 AM
  • Hi Vinod,

    Can u tell me how do you implement your openSWAN solution ? Do you install OpenSWAN on Azure and on your on-premise infrastructure ?

    I'm trying to make an IPSec Tunnel between my OpenSWAN installed on a public Cloud and Microsoft Azure.

    Thanks in advance,

    Regards

    Wednesday, November 14, 2012 9:10 AM
  • Hey Boris,

    OpenSwan was installed on another public cloud, connecting to Azure. However, after the ports changed on me yet again (meaning I had to modify the firewall rules I listed above), I decided it was too much trouble to pursue this connectivity solution and settled for running all of my machines on the other public cloud.

    I may revisit this at some point in the future if the benefits are great enough.

    Wednesday, November 14, 2012 9:16 AM
  • Thanks Vinod,

    I'll try another solution. For sure, OpenSWAN it's a bit complex to implement with Azure and another public cloud...

    Regards,

    Wednesday, November 14, 2012 9:47 AM