<div dir="ltr">Hello all,<div><br></div><div>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.</div><div>First things first - the setup:</div><div>Site A:</div><div>LAN(A) --->  CentOS (ClearOS) gateway ---> Asus router ---> Internet provider</div><div>LAN(A): <a href="http://10.201.1.0/24">10.201.1.0/24</a></div><div>CentOS: 10.201.1.1 (LAN); 192.168.111.99 (WAN)</div><div>Asus router: 192.168.111.1 (gateway); 192.168.4.96 (wan) / 194.x.x.x (public)</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Site B:</div><div>LAN(B) ---> Synology diskstation (acting as gateway) ---> Internet provider</div><div>LAN(B): <a href="http://10.201.2.0/24">10.201.2.0/24</a></div><div>Synology: 10.201.2.1 (LAN); 10.56.166.24 (wan) / 88.y.y.y (public)</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Goal: to be able to connect all devices from LAN A to LAN B and vice versa.</div><div><br></div><div>What's been done so far:</div><div>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.</div><div><br></div><div><u>Configuration on "A-side":</u></div><div><div><b>ipsec.conf </b><i>(commented lines omitted)</i></div><div><div>version 2.0     # conforms to second version of ipsec.conf specification</div><div># basic configuration</div><div>config setup</div><div>        protostack=netkey</div><div>        nat_traversal=yes</div><div>        virtual_private=%v4:<a href="http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12">10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12</a></div><div>        oe=off</div><div><div>#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this.</div><div>include /etc/ipsec.d/*.conf</div></div></div><div><br></div><div><b>net-to-net.conf</b></div><div>conn net-to-net</div><div>        left=192.168.111.99</div><div>        leftsubnet=<a href="http://10.201.1.0/24">10.201.1.0/24</a></div><div>        leftsourceip=10.201.1.1</div><div>        right=88.212.52.112</div><div>        rightid=10.56.166.24</div><div>        rightsubnet=<a href="http://10.201.2.0/24">10.201.2.0/24</a></div><div>        authby=secret</div><div>        auto=start</div></div><div><br></div><div><u>Configuration on "B-side":</u></div><div><div><b>ipsec.conf</b></div><div><div>version 2.0</div><div>config setup</div><div>    nat_traversal=yes</div><div>    virtual_private=%v4:<a href="http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12">10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12</a></div><div>    oe=off</div><div>    protostack=netkey</div><div>    listen=192.168.1.1</div><div>    #plutodebug=all</div><div>    #plutostderrlog=/var/log/pluto.log</div><div><br></div><div>conn L2TP-PSK-NAT</div><div>    rightsubnet=vhost:%priv</div><div>    also=L2TP-PSK-noNAT</div><div><br></div><div>conn L2TP-PSK-noNAT</div><div>    authby=secret</div><div>    pfs=no</div><div>    auto=add</div><div>    keyingtries=3</div><div>    rekey=yes</div></div><div><div>    ikelifetime=8h</div><div>    keylife=1h</div><div>    type=transport</div><div>    left=%defaultroute</div><div>    leftprotoport=17/1701</div><div>    right=%any</div><div>    rightprotoport=17/%any</div><div>    forceencaps=yes</div><div>    dpddelay=10</div><div>    dpdtimeout=90</div><div>    dpdaction=clear</div></div><div><b><br></b></div><div><b>net-to-net.conf</b></div><div>conn net-to-net</div><div>        left=10.56.166.24</div><div>        leftsubnet=<a href="http://10.201.2.0/24">10.201.2.0/24</a></div><div>        leftsourceip=10.201.2.1</div><div>        right=194.x.x.x</div><div>        rightid=192.168.111.99</div><div>        rightsubnet=<a href="http://10.201.1.0/24">10.201.1.0/24</a></div><div>        authby=secret</div><div>        auto=start</div></div><div><br></div><div><u style="font-weight:bold">Note:</u> 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.</div><div>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.</div><div><br></div><div>Once I start the ipsec on both ends, I see:</div><div><u>A-side (last few lines from log):</u></div><div><div>responding to Quick Mode proposal {msgid:b83336f6}</div><div>Feb  2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4:     us: <a href="http://10.201.1.0/24===192.168.111.99">10.201.1.0/24===192.168.111.99</a><192.168.111.99>[+S=C]</div><div>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]===<a href="http://10.201.2.0/24">10.201.2.0/24</a></div><div>Feb  2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: keeping refhim=4294901761 during rekey</div><div>Feb  2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1</div><div>Feb  2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2</div><div>Feb  2 11:28:13 keskvisrv01 pluto[25663]: "net-to-net" #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2</div><div>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}</div></div><div><br></div><div><u>B-side (after bringing the connection up via command line):</u></div><div><div>002 added connection description "net-to-net"</div><div>104 "net-to-net" #149: STATE_MAIN_I1: initiate</div><div>003 "net-to-net" #149: ignoring unknown Vendor ID payload [4f4568794c64414365636661]</div><div>003 "net-to-net" #149: received Vendor ID payload [Dead Peer Detection]</div><div>003 "net-to-net" #149: received Vendor ID payload [RFC 3947] method set to=109</div><div>106 "net-to-net" #149: STATE_MAIN_I2: sent MI2, expecting MR2</div><div>003 "net-to-net" #149: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed</div><div>108 "net-to-net" #149: STATE_MAIN_I3: sent MI3, expecting MR3</div><div>003 "net-to-net" #149: received Vendor ID payload [CAN-IKEv2]</div><div>004 "net-to-net" #149: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}</div><div>117 "net-to-net" #150: STATE_QUICK_I1: initiate</div><div>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}</div></div><div><br></div><div>From the last line in both cases I deduct that tunnel is established (correct?).</div><div>From here on I cannot get the traffic going. From what I read here and then, the problems might be:</div><div>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?)</div><div>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?</div><div>3) not enough directives to correctly describe routing for both ends - what am I missing?</div><div><br></div><div>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...</div><div><br></div><div>Well, enough said. Sorry for a long post, but I wanted to provide as much info as possible.</div><div>I will be looking forward to any suggestions you may have to get me going. Thank you very much in advance.</div><div><br></div><div>Cheers,</div><div>Brandon.</div></div>