If your routing table looks good, then I believe that's a networking issue, you'll have to figure who cuts these packets. ocserv/openconnect do not filter any traffic, they just forward whatever they see from the kernel. regards, Nikos On Wed, Apr 10, 2019 at 12:29 PM Wolfgang Dautermann <wolfgang@xxxxxxxxxxxxx> wrote: > > (sorry for the late answer) > > On 05.04.19 18:13, Nikos Mavrogiannopoulos wrote: > > That's how the tun device is. Have you pushed the routes of your local > > network to your clients? Most likely the clients do not know that the > > network is handled by the vpn server. > > A local routing table on a client looks like that: > > $ route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 0.0.0.0 10.12.1.254 0.0.0.0 UG 0 0 0 > enp6s0 > 0.0.0.0 10.12.1.254 0.0.0.0 UG 100 0 0 > enp6s0 > 8.8.8.8 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 > 10.12.0.0 0.0.0.0 255.255.0.0 U 100 0 0 > enp6s0 > 91.229.57.28 10.12.1.254 255.255.255.255 UGH 0 0 0 > enp6s0 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 > enp6s0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 > > The last entry seems to be okay - I think? On the second client it is > simliar. > > In /etc/ocserv.conf I have set: > > ipv4-network = 192.168.1.0 > ipv4-netmask = 255.255.255.0 > > route = 192.168.1.0/255.255.255.0 > > # not really sure, if that is necessary > expose-iroutes = true > > (I hope, thats all, that is relevant...) > > And the clients get their expected IP-address (e.g. 192.168.1.31, > 192.168.1.41) > > Best regards, Wolfgang > _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
