search for: tun10

On Wed, Apr 27, 2016 at 05:15:57PM +0800, hshh wrote: > >Updated support for BSD tun/tap devices. > It is broken on FreeBSD tun. > > tcpdump on tun, > 09:05:07.458988 IP0 bad-hlen 0 Can you show me your tinc.conf and tinc-up script? Also, which version of FreeBSD are you using? -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org>

tinc.conf Name = server Device = /dev/tun10 TunnelServer = yes Forwarding = kernel KeyExpire = 86400 tinc-up #!/bin/sh /sbin/ifconfig tun10 up /sbin/ifconfig tun10 inet 10.255.1.1/24 On Wed, Apr 27, 2016 at 5:20 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Wed, Apr 27, 2016 at 05:15:57PM +0800, hshh wrote: > >> &gt...

Hi, I got an existing solution with shorewall where I can differentiate tun10 from tun+ as different zone. For example: /etc/shorewall/zones A ipv4 B:A ipv4 /etc/shorewall/interfaces A tun+ B tun10 Now, I have a requirement to add tun11 to zone B. When I do this in interfaces config: A tun+ B tun10,tun11 It doesn''t like it (although it''s ok w...

...odes,for example 10.0.0.1-10.0.0.8 I've already set Every node's subnet to 10.0.0.0/24 and set forwarding option to kernel. After I deleted the default route table(ip route 10.0.0.0/24 dev tun) and added the following route options: ip route add 10.0.0.1 dev tun ip route add 10.0.0.2 dev tun10 via 10.0.0.1 and then I tried trace route 10.0.0.2 still showing me it directly sent to 10.0.0.2 without relaying from 10.0.0.1. What's wrong with that?

...ve at ipwar.ch Since sshd version 6.8, point-to-point tunnels doesn't work as soon as traffic through this tunnel ocures. Steps to reproduce: 1. Use sshd > 6.7 on target server 2. open a point-to-point tunnel e.g. "ssh -w 10:10 targetserver.domain.org" 3. configure ip and link on tun10 on both sides 4. make some traffic, for example wget some file over the tunnel. 5. see the broken pipe The debug log from client side is big, so i will upload it to the message. The relevant log file on the server side: Sep 14 14:44:56 serverhost sshd[23455]: channel 0: adjust 99528 overflows rem...

...hutdown crashed very nastily when closing openvpn. We could see this even when manually stopping the domUs. We surmised that the problem was we had tun0 and tun1 defined in both domains and killing them in one must be killing them in another. We renamed those tun adapters in the second domain to tun10 and tun11 and that problem went away. We still noticed very long reboot times. The hang seemed to be at killall but the "logjam" seemed to break after xendomains errored out. We assumed this was because killall killed something that xendomains needed to shutdown gracefully so we added e...