<div dir="ltr"><div>Hello,</div><div><br></div>I got the server to work. The issue was, that I didn't disable iptables correct. Now two client and the server are exchanging own routes. <div><br></div><div>I connected to one client another one over a router and the router is connected to the ospf-network as well. </div><div><br></div><div>But somehow I cannot contact the new client from the first client or even from the server. Iptables are surely disabled now.</div><div><br></div><div>My current setting</div><div><br></div><div><br></div><div>client3 </div><div>192.168.30.2 (eth)</div><div>|</div><div>|</div><div>192.168.30.1 (eth)</div><div>routerA</div><div>192.168.21.5 (eth)</div><div>|</div><div>|</div><div>192.168.21.1 (eth)</div><div>client2</div><div>10.29.0.8 (tun)</div><div>|</div><div>|</div><div>10.29.0.1 (tun)</div><div>Server</div><div>10.29.0.1 (tun)<br></div><div>|</div><div>|</div><div>10.29.0.4 (tun)<br></div><div>client1</div><div>192.168.21.17 (eth)</div><div><br></div><div><br></div><div>I ran following commands on client1</div><div><br></div><div>route -n (routes with metric 12 are set by bird)</div><div><br></div><div>Destination Gateway Genmask Flags Metric Ref Use Iface<br></div><div><div>10.29.0.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0<br></div><div>WWWWW 0.0.0.0 255.255.255.252 U 0 0 0 eth1</div><div>XXXXXXX 0.0.0.0 255.255.255.255 UH 1024 0 0 eth1</div><div>192.168.21.0 10.29.0.8 255.255.255.240 UG 12 0 0 tun0<br></div><div>192.168.21.16 0.0.0.0 255.255.255.240 U 0 0 0 eth0</div><div>192.168.30.0 10.29.0.8 255.255.255.240 UG 12 0 0 tun0</div></div><div><br></div><div><br></div><div><div>traceroute 192.168.21.3</div><div>traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 38 byte packets</div><div> 1 10.29.0.8 (10.29.0.8) 101.192 ms 111.038 ms 116.587 ms</div><div> 2 192.168.21.3 (192.168.21.3) 102.448 ms 72.160 ms 100.151 ms</div></div><div><br></div><div><div>traceroute 192.168.30.1</div><div>traceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 38 byte packets</div><div> 1 server(10.29.0.1) 128.053 ms 128.731 ms 117.244 ms</div><div> 2 *^C (no response) </div><div><br></div><div><br></div><div>and the server:</div><div><br></div><div>route -n (routes with metric 17 are set by bird)</div><div><div><br></div><div>Ziel Router Genmask Flags Metric Ref Use Iface</div><div>192.168.21.16 10.29.0.4 255.255.255.240 UG 17 0 0 tun0<br></div><div>192.168.21.0 10.29.0.8 255.255.255.240 UG 17 0 0 tun0</div><div>192.168.30.0 10.29.0.8 255.255.255.240 UG 17 0 0 tun0</div><div>192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0</div><div>10.29.0.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0</div><div>ZZZZZZZZ 0.0.0.0 255.255.0.0 U 1002 0 0 eth0</div><div><br></div></div><div><div>traceroute 192.168.21.3</div><div><br></div><div>traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 60 byte packets</div><div> 1 10.29.0.8 (10.29.0.8) 40.352 ms 96.659 ms 96.643 ms</div><div> 2 192.168.21.3 (192.168.21.3) 96.625 ms 96.606 ms 96.586 ms</div></div><div><br></div><div>traceroute 192.168.30.1<br></div><div>no responce</div><div><br></div><div>As you can see in route -n, the server has a valid route to 192.168.30.0</div></div><div><br></div><div>Do you have any idea, what I'm missing now? I guess that's the "tricky party", mentioned by Micheal McConnell. </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-04 13:54 GMT+02:00 dawid k <span dir="ltr"><<a href="mailto:tookie009smieci@gmail.com" target="_blank">tookie009smieci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span class="">2018-04-04 12:31 GMT+02:00 Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-8897870227229372464gmail-">On Wed, Apr 04, 2018 at 11:35:03AM +0200, dawid k wrote:<br>
> 2018-04-04 10:59 GMT+02:00 Jan Maria Matejka <<a href="mailto:jan.matejka@nic.cz" target="_blank">jan.matejka@nic.cz</a>>:<br>
><br>
> > Hello,<br>
> ><br>
> > please could you enable 'debug all' for the ospf protocol at server?<br>
> > It should tell you whether it receives the packets and what is it doing<br>
> > with them.<br>
> ><br>
><br>
> It is enabled, Here the logs:<br>
><br>
><br>
</span><span class="m_-8897870227229372464gmail-">> no received packets, but with tcpdump on server I can see, that all devices<br>
> are sending hello messages:<br>
<br>
</span>Hello<br>
<br>
That is interesting, It is possible that there is some problem with<br>
multicast on OpenVPN, as mentioned by Michael McConnell, but not in the sense<br>
of multicast transmit (which works as seen by tcpdump), but multicast delivery<br>
to userspace sockets (so BIRD does not get them).<br>
<br>
One workaround would be to use NBMA interface type in BIRD OSPF. That<br>
uses just unicast, so perhaps there would not be this problem. See 'type<br>
nbma' OSPF option. Then you have to use 'neighbors' option to specify<br>
client IPs on server and at least server IP (marked 'eligible') on clients<br>
and set priority to 0 on clients.<br>
<span class="m_-8897870227229372464gmail-"><br></span></blockquote></span><div>Thank you for your help, but it is still not working. </div><div> </div><div>I tried the nmba connection between one client and server with following settings:<div><br></div><div>client:</div></div><div><div><br></div><div> interface "tun0" {</div><div> cost 10;</div><div> type nbma;</div><div> strict nonbroadcast yes; #tried with disabled as well</div><span class=""><div> stub no;</div><div> hello 10;</div><div> transmit delay 5;</div><div> wait 10;</div><div> dead 40;</div></span><div> priority 0;</div><div> neighbors {</div><div> 10.29.0.1 eligible; #server's IP</div><div> };</div><div> };</div></div><div><br></div><div>server</div><div><div> interface "tun0" {</div><div> cost 10;</div><div> type nbma;</div><div> strict nonbroadcast yes;</div><span class=""><div> stub no;<br></div><div> hello 10;</div><div> transmit delay 5;</div><div> wait 10;</div><div> dead 40;</div></span><div> neighbors {</div><div> 10.26.0.4; # client's IP</div><div> };<br></div><div> };</div></div><div><br></div><div>There are no error messages in logs only the info: HELLO packet sent via tun0. </div><div>I started tcpdump -v -s 0 proto ospf -i tun0 now on both client and server and there is no traffic at all. </div><div>The routes are set properly and ping is working. I tried ptp as well with similar result. Im using iptables, but for the test I deactivated it. </div><div>I have no idea, why tcpdump shows no traffic. I suppose, that there is an issue with OpenVPN, what Michael McConnel and others mentioned. </div><span class=""><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-8897870227229372464gmail-">
--<br>
Elen sila lumenn' omentielvo<br>
<br>
</span>Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
<div class="m_-8897870227229372464gmail-HOEnZb"><div class="m_-8897870227229372464gmail-h5">"To err is human -- to blame it on a computer is even more so."<br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>