[Swan] Can't route back down ipsec tunnel from VPS

Darren Share darren.share at chronos.co.uk
Thu Dec 4 22:16:42 EET 2014


Hi Paul

Can you elaborate? The only use of "elastic IP" I'm aware of is regarding AWS, is that what you mean? I am using a VPS on DigitalOcean for this project if that helps. 


> On 4 Dec 2014, at 20:10, Paul Wouters 🔓 <paul at nohats.ca> wrote:
> 
>> On Thu, 4 Dec 2014, Darren Share wrote:
>> 
>> Thanks for the info. I've got the VPN set up now with packets going from one end to the other as required. Just have a problem now with the
>> VPS refusing to route packets from the VPN out to the internet which I don't think is related to libreswan. 
> 
> Remember the VPS might need to configure the "elastic IP" on loopback or
> else you cannot create packets (to be encrypted) with that source ip.
> 
> Paul
> 
>> Darren
>> On 4 Dec 2014, at 19:14, Nick Howitt <nick at howitts.co.uk> wrote:
>> 
>>      ...... left/rightprotoport are generally for l2tp (but can have other specialised uses)! L2tp is normally for roadwarrior
>>      connections and not net-net. I know Drayteks support it so I was wondering if you were getting mixed up. You would not be using
>>      l2tp in Linux unless you specifically installed (or your script did).
>> 
>>      As for quick and dirty settings, I'd use AES over 3DES. In fact I use ike=aes256-sha1;modp2048 and phase2alg=aes256-sha1 as both
>>      ends support it. I also use pfs.
>> 
>>      Nick
>> 
>>      On 04/12/2014 18:49, Darren Share wrote:
>>      Hi Nick
>> Thanks for the reply. I was originally using right=%any but changed it in an attempt to get it to work. I've changed it to
>> tunnel mode and have now got it working. The biggest blocker was the leftprotoport= and rightprotoport= settings. Removing them
>> actually achieved what I'm trying to do. I do have another problem now though but before I get into that, I'm curious about your
>> question about l2tp. What makes you think I am using l2tp? I didn't think I was but I don't know libreswan (or any of the
>> various *swans) very well and used the aforementioned script because I needed a quick and dirty VPN setting up. 
>> Thanks. 
>> Darren.
>> On 4 Dec 2014, at 18:25, Nick Howitt <nick at howitts.co.uk> wrote:
>> 
>>      Why are you using l2tp and not just plain IPsec? Also why are you using transport mode? Which Draytek are you using?
>>      I am not sure if they support transport mode. I don't think my 2820 and 2710 do.
>> 
>>      Shouldn't right be the public IP of the Draytek or %any if the Draytek has a dynamic IP? rightsubnet then (possibly)
>>      becomes 10.111.1.0/24.
>> 
>>      Do you have the ipsec logs from libreswan
>> 
>>      Nick
>> 
>>      On 03/12/2014 16:16, Darren Share wrote:
>> 
>>      Hi there.
>> 
>>      FYI, I have also posted this on Server Fault. I am trying to establish an ipsec VPN from a Draytek router on
>>      the edge of our corporate network to a VPS on Digital Ocean. I've set up the VPN on the VPS using this script
>>      - https://github.com/philplckthun/setup-simple-ipsec-l2tp-vpn - on an Ubuntu 14.04 machine. I believe the
>>      script downloads and installs libreswan and prompts for a few basic configuration questions etc. I've made a
>>      few changes to the ipsec.conf the script creates. My problem is, I can ping from the router to the VPS and I
>>      can see the packets arriving on the VPS showing as coming from the private IP address of the router, but
>>      nothing I've tried has allowed me to route packets back down the tunnel to the router. Therefore, from the
>>      router's pov it appears the pings are timing out.
>> 
>>      The router is connected directly to the internet on one of its interfaces and it is configured with a local IP
>>      address of 10.111.1.1. The VPS has a single interface connected directly to the internet.
>> 
>>      When the VPN is established this is the routing table on the VPS:
>> 
>>      Kernel IP routing table
>>      Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
>>      default         178.62.64.1     0.0.0.0         UG        0 0          0 eth0
>>      10.111.1.1      *               255.255.255.255 UH        0 0          0 eth0
>>      178.62.64.0     *               255.255.192.0   U         0 0          0 eth0
>> 
>>      Note the second entry is created when the VPN is established.
>> 
>>      If I try to ping 10.111.1.1 I get:
>> 
>>      PING 10.111.1.1 (10.111.1.1) 56(84) bytes of data.
>>      From <public IP address - eth0> icmp_seq=1 Destination Host Unreachable
>> 
>>      Here is the output from ipsec verify:
>> 
>>      Verifying installed system and configuration files
>> 
>>      Version check and ipsec on-path                         [OK]
>>      Libreswan 3.10 (netkey) on 3.13.0-37-generic
>>      Checking for IPsec support in kernel                    [OK]
>>      NETKEY: Testing XFRM related proc values
>>              ICMP default/send_redirects                    [OK]
>>              ICMP default/accept_redirects                  [OK]
>>              XFRM larval drop                               [OK]
>>      Pluto ipsec.conf syntax                                 [OK]
>>      Hardware random device                                  [N/A]
>>      Two or more interfaces found, checking IP forwarding    [OK]
>>      Checking rp_filter                                      [OK]
>>      Checking that pluto is running                          [OK]
>>      Pluto listening for IKE on udp 500                     [OK]
>>      Pluto listening for IKE/NAT-T on udp 4500              [OK]
>>      Pluto ipsec.secret syntax                              [OK]
>>      Checking 'ip' command                                   [OK]
>>      Checking 'iptables' command                             [OK]
>>      Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options
>>                  [OK]
>>      Opportunistic Encryption                                [DISABLED]
>> 
>>      and here is the content of /etc/ipsec.conf (the commented out lines are results of previous experimentation
>>      with the same results) - essentially, nothing I change seems to make any difference:
>> 
>>      version 2.0
>> 
>>      config setup
>>       dumpdir=/var/run/pluto/
>>       nat_traversal=yes
>>       virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.42.0/24
>>       oe=off
>>       protostack=netkey
>>       nhelpers=0
>>       interfaces=%defaultroute
>> 
>>      conn vpnpsk
>>       connaddrfamily=ipv4
>>       auto=add
>>       left=178.62.73.215
>>      #  leftid=178.62.73.215
>>      #  leftsubnet=178.62.73.215/32
>>       leftsubnet=10.10.10.0/24
>>      #  leftnexthop=%defaultroute
>>       leftnexthop=%direct
>>       leftprotoport=17/1701
>>       rightprotoport=17/%any
>>      #  right=%any
>>       right=10.111.1.0/24
>>       rightsourceip=10.111.1.1
>>       leftsourceip=10.10.10.1
>>      #  rightsubnetwithin=0.0.0.0/0
>>       forceencaps=yes
>>       authby=secret
>>       pfs=no
>>       type=transport
>>       auth=esp
>>       ike=3des-sha1,aes-sha1
>>       phase2alg=3des-sha1,aes-sha1
>>       rekey=no
>>       keyingtries=5
>>       dpddelay=30
>>       dpdtimeout=120
>>       dpdaction=clear
>> 
>>      This is the relevant part of the routing table from the router:
>> 
>>      Key: C - connected, S - static, R - RIP, * - default, ~ - private
>>      *            0.0.0.0/ 0.0.0.0          via <public IP address>   WAN2
>>      S~        10.10.10.0/ 255.255.255.0    via 178.62.73.215   VPN-10
>>      C~        10.111.1.0/ 255.255.255.0    directly connected    LAN
>>      C    <public IP address>/ 255.255.255.224  directly connected    WAN2
>> 
>>      Would appreciate someone pointing out what I'm doing wrong.
>> 
>>      Many thanks.
>> 
>>      ______________________________________________________________________
>>      This email has been scanned by the Symantec Email Security.cloud service.
>>      For more information please visit http://www.symanteccloud.com
>>      ______________________________________________________________________
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________


More information about the Swan mailing list