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
______________________________________________________________________
