[Openswan Users] Traffic not going through the tunnel
BS Registrations
brano.registracie at gmail.com
Mon Feb 2 05:41:41 EST 2015
Hello all,
I'm trying (more or less successfully) to get site-to-site tunnel going. I
got to the point where I am turning to the community for help.
First things first - the setup:
Site A:
LAN(A) ---> CentOS (ClearOS) gateway ---> Asus router ---> Internet
provider
LAN(A): 10.201.1.0/24
CentOS: 10.201.1.1 (LAN); 192.168.111.99 (WAN)
Asus router: 192.168.111.1 (gateway); 192.168.4.96 (wan) / 194.x.x.x
(public)
IPSEC is ran on CentOS server, it is configured via command line (conf
files), not the web interface. Ports (UDP) 500 and 4500 opened on both
CentOS and Asus router.
The Asus router gets a 192.168. range from the provider, but there is the
public ip 194.x.x.x which is I guess NATed - works ok, as other services
public are running well on the server.
Site B:
LAN(B) ---> Synology diskstation (acting as gateway) ---> Internet provider
LAN(B): 10.201.2.0/24
Synology: 10.201.2.1 (LAN); 10.56.166.24 (wan) / 88.y.y.y (public)
IPSEC is ran on Synology (it is their VPN application, which uses
openswan), but configuration is again done via command line (conf files).
Ports (UDP) 500 and 4500 are opened for the WAN interface.
The public side is similar to Site A. Sinology gets an 10.56.166.24
addressed assigned by the provider, but there is a public address 88.y.y.y
mapped and works well for other external services.
Goal: to be able to connect all devices from LAN A to LAN B and vice versa.
What's been done so far:
I started with as simple configuration as possible, thus having only left +
leftsubnet; right + rightsubnet; auto=start; authby=secret (for now...).
This of course did not work and I got to a point, where tunnel gets
established but I can't ping or otherwise reach even the "server" machines,
nor any clients.
*Configuration on "A-side":*
*ipsec.conf **(commented lines omitted)*
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
protostack=netkey
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and
uncomment this.
include /etc/ipsec.d/*.conf
*net-to-net.conf*
conn net-to-net
left=192.168.111.99
leftsubnet=10.201.1.0/24
leftsourceip=10.201.1.1
right=88.212.52.112
rightid=10.56.166.24
rightsubnet=10.201.2.0/24
authby=secret
auto=start
*Configuration on "B-side":*
*ipsec.conf*
version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
oe=off
protostack=netkey
listen=192.168.1.1
#plutodebug=all
#plutostderrlog=/var/log/pluto.log
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
authby=secret
pfs=no
auto=add
keyingtries=3
rekey=yes
ikelifetime=8h
keylife=1h
type=transport
left=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
forceencaps=yes
dpddelay=10
dpdtimeout=90
dpdaction=clear
*net-to-net.conf*
conn net-to-net
left=10.56.166.24
leftsubnet=10.201.2.0/24
leftsourceip=10.201.2.1
right=194.x.x.x
rightid=192.168.111.99
rightsubnet=10.201.1.0/24
authby=secret
auto=start
*Note:* The L2TP-PSK-xxxx connections are generated by the web interface
automatically. I must have them in order to have the ipsec daemon load all
necessary modules and have ipsec running. Afterwards I manually add the
net-to-net connection and bring it up.
Also, tunnel is established (? see below) successfully even without the
leftsourceip directives - I only added them later in an attempt to get the
traffic going.
Once I start the ipsec on both ends, I see:
*A-side (last few lines from log):*
responding to Quick Mode proposal {msgid:b83336f6}
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: us:
10.201.1.0/24===192.168.111.99<192.168.111.99>[+S=C]
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: them:
88.212.52.112<88.212.52.112>[10.56.166.24,+S=C]===10.201.2.0/24
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: keeping
refhim=4294901761 during rekey
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: transition from
state STATE_QUICK_R0 to state STATE_QUICK_R1
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: STATE_QUICK_R1:
sent QR1, inbound IPsec SA installed, expecting QI2
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: transition from
state STATE_QUICK_R1 to state STATE_QUICK_R2
Feb 2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: STATE_QUICK_R2:
IPsec SA established tunnel mode {ESP=>0xd9561dfc <0x2d813a13
xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=88.y.y.y:4500 DPD=none}
*B-side (after bringing the connection up via command line):*
002 added connection description "net-to-net"
104 "net-to-net" #149: STATE_MAIN_I1: initiate
003 "net-to-net" #149: ignoring unknown Vendor ID payload
[4f4568794c64414365636661]
003 "net-to-net" #149: received Vendor ID payload [Dead Peer Detection]
003 "net-to-net" #149: received Vendor ID payload [RFC 3947] method set
to=109
106 "net-to-net" #149: STATE_MAIN_I2: sent MI2, expecting MR2
003 "net-to-net" #149: NAT-Traversal: Result using RFC 3947
(NAT-Traversal): both are NATed
108 "net-to-net" #149: STATE_MAIN_I3: sent MI3, expecting MR3
003 "net-to-net" #149: received Vendor ID payload [CAN-IKEv2]
004 "net-to-net" #149: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "net-to-net" #150: STATE_QUICK_I1: initiate
004 "net-to-net" #150: STATE_QUICK_I2: sent QI2, IPsec SA established
tunnel mode {ESP=>0x2d813a13 <0xd9561dfc xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=194.x.x.x:4500 DPD=none}
>From the last line in both cases I deduct that tunnel is established
(correct?).
>From here on I cannot get the traffic going. From what I read here and
then, the problems might be:
1) firewall issues - but if tunnel gets established and ports are open, how
do I find out (e.g. what should I use? tcpdump? if yes, with what options?)
2) different ciphers on both ends - could be really? would tunnel get even
established then? If yes, should I manually narrow down to just 1 cipher?
3) not enough directives to correctly describe routing for both ends - what
am I missing?
There may be others, but at this moment I don't even know which way to go
first. I'm even thinking whether the default L2TP-PSK-... connections could
be interfering in any way...
Well, enough said. Sorry for a long post, but I wanted to provide as much
info as possible.
I will be looking forward to any suggestions you may have to get me going.
Thank you very much in advance.
Cheers,
Brandon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150202/187ce402/attachment.html>
More information about the Users
mailing list