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 <[email protected]> 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
>> [email protected]
>> 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
______________________________________________________________________
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to