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 <[email protected]> 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 <[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 ______________________________________________________________________ ______________________________________________________________________ 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
