Hello,

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. 

I connected to one client another one over a router and the router is connected to the ospf-network as well. 

But somehow I cannot contact the new client from the first client or even from the server. Iptables are surely disabled now.

My current setting


client3 
192.168.30.2 (eth)
|
|
192.168.30.1 (eth)
routerA
192.168.21.5 (eth)
|
|
192.168.21.1 (eth)
client2
10.29.0.8 (tun)
|
|
10.29.0.1 (tun)
Server
10.29.0.1 (tun)
|
|
10.29.0.4 (tun)
client1
192.168.21.17 (eth)


I ran following commands on client1

route -n (routes with metric 12 are set by bird)

Destination       Gateway         Genmask         Flags Metric Ref    Use Iface
10.29.0.0          0.0.0.0         255.255.252.0   U     0      0        0 tun0
WWWWW        0.0.0.0         255.255.255.252 U     0      0        0 eth1
XXXXXXX        0.0.0.0         255.255.255.255 UH    1024   0        0 eth1
192.168.21.0    10.29.0.8     255.255.255.240 UG    12     0        0 tun0
192.168.21.16  0.0.0.0         255.255.255.240 U     0      0        0 eth0
192.168.30.0    10.29.0.8     255.255.255.240 UG    12     0        0 tun0


traceroute  192.168.21.3
traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 38 byte packets
 1  10.29.0.8 (10.29.0.8)  101.192 ms  111.038 ms  116.587 ms
 2  192.168.21.3 (192.168.21.3)  102.448 ms  72.160 ms  100.151 ms

traceroute  192.168.30.1
traceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 38 byte packets
 1  server(10.29.0.1)  128.053 ms  128.731 ms  117.244 ms
 2  *^C (no response) 


and the server:

route -n (routes with metric 17 are set by bird)

Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.21.16   10.29.0.4       255.255.255.240 UG    17     0        0 tun0
192.168.21.0    10.29.0.8       255.255.255.240 UG    17     0        0 tun0
192.168.30.0    10.29.0.8       255.255.255.240 UG    17     0        0 tun0
192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.29.0.0       0.0.0.0         255.255.252.0   U     0      0        0 tun0
ZZZZZZZZ     0.0.0.0         255.255.0.0     U     1002   0        0 eth0

traceroute  192.168.21.3

traceroute to 192.168.21.3 (192.168.21.3), 30 hops max, 60 byte packets
 1  10.29.0.8 (10.29.0.8)  40.352 ms  96.659 ms  96.643 ms
 2  192.168.21.3 (192.168.21.3)  96.625 ms  96.606 ms  96.586 ms

traceroute  192.168.30.1
no responce

As you can see in route -n, the server has a valid route to 192.168.30.0

Do you have any idea, what I'm missing now? I guess that's the "tricky party", mentioned by Micheal McConnell. 



2018-04-04 13:54 GMT+02:00 dawid k <tookie009smieci@gmail.com>:

2018-04-04 12:31 GMT+02:00 Ondrej Zajicek <santiago@crfreenet.org>:
On Wed, Apr 04, 2018 at 11:35:03AM +0200, dawid k wrote:
> 2018-04-04 10:59 GMT+02:00 Jan Maria Matejka <jan.matejka@nic.cz>:
>
> > Hello,
> >
> > please could you enable 'debug all' for the ospf protocol at server?
> > It should tell you whether it receives the packets and what is it doing
> > with them.
> >
>
> It is enabled, Here the logs:
>
>
> no received packets, but with tcpdump on server I can see, that all devices
> are sending hello messages:

Hello

That is interesting, It is possible that there is some problem with
multicast on OpenVPN, as mentioned by Michael McConnell, but not in the sense
of multicast transmit (which works as seen by tcpdump), but multicast delivery
to userspace sockets (so BIRD does not get them).

One workaround would be to use NBMA interface type in BIRD OSPF. That
uses just unicast, so perhaps there would not be this problem. See 'type
nbma' OSPF option. Then you have to use 'neighbors' option to specify
client IPs on server and at least server IP (marked 'eligible') on clients
and set priority to 0 on clients.

Thank you for your help, but it is still not working. 
 
I tried the nmba connection between one client and server with following settings:

client:

                interface "tun0" {
                        cost 10;
                        type nbma;
                        strict nonbroadcast yes; #tried with disabled as well
                        stub no;
                        hello 10;
                        transmit delay 5;
                        wait 10;
                        dead 40;
                        priority 0;
                        neighbors {
                                10.29.0.1 eligible; #server's IP
                        };
                 };

server
                interface "tun0" {
                        cost 10;
                        type nbma;
                        strict nonbroadcast yes;
                        stub no;
                        hello 10;
                        transmit delay 5;
                        wait 10;
                        dead 40;
                        neighbors {
                                10.26.0.4; # client's IP
                        };
                 };

There are no error messages in logs only the info: HELLO packet sent via tun0. 
I started  tcpdump -v -s 0  proto ospf -i tun0 now on both client and server and there is no traffic at all. 
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. 
I have no idea, why tcpdump shows no traffic. I suppose, that there is an issue with OpenVPN, what Michael McConnel and others mentioned. 


 
--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."