similar to: Can't Route LAN Traffic Behind Tinc Network

Keith, Thanks for the reply and the pointers. > Did you remember to activate kernel ip forwarding? > i.e. echo 1 > /proc/sys/net/ipv4/ip_forward ? I actually forgot to do this, but I have enabled it now in /etc/systctl.conf and can confirm now after a reboot that it's enabled. Unfortunately, still can't ping the node on the LAN. > and when I saw that I was about to cancel

Thanks again Keith. I disabled UFW and flushed iptables completely, but same result. Pings from the external node are reaching the internal node on the tinc0 interface but nothing happens after that. Now that I'm thinking of it, I did some masquerading in order to get OpenVPN to work on another box, I wonder if that would be applicable here? Very Respectfully, Kismet Agbasi

Turns out I needed to masquerade the traffic coming into that INSIDE node. Since I use UFW to manage IPtables, adding this to my /etc/ufw/before.rules and restarting UFW fixed it for me: " -A POSTROUTING -s 10.9.0.0/24 -o eth1 -j MASQUERADE" Very Respectfully, Kismet-Gerald Agbasi IT/Systems Administrator Central Truck Center, Inc. Office: 240-487-3315 Toll Free: 1-800-492-0709

Thank you guys for a great product. I have successfully setup a VPN between a cloud server and an internal one (details below). However, I am unable to pass traffic from the cloud to the internal machines behind the tunnel. Internal subnet: 172.23.6.0/24 Host Public IP: 50.242.184.132 Host LAN IP: 172.23.6.148 Host VPN IP: 10.9.0.2 Cloud Server IP: 107.170.55.181 Cloud Server

Thanks Keith. Here's the output: root at ubuntu2:~# iptables -vnL FORWARD Chain FORWARD (policy ACCEPT 745 packets, 47680 bytes) pkts bytes target prot opt in out source destination 6299 416K ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0 6299 416K ufw-before-forward all -- * * 0.0.0.0/0

Lars, Thanks for that tcpdump command, very helpful. I was able to confirm that the packets are indeed reaching the INSIDE node - so I'm suspecting that my routing table might be wrong. Very Respectfully, Kismet Agbasi -----Original Message----- From: tinc [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of Lars Kruse Sent: Wednesday, October 5, 2016 4:18 PM To: tinc at tinc-vpn.org

On 06/10/2016 17:16, Kismet Agbasi wrote: > Thanks again Keith. I disabled UFW and flushed iptables completely, but same result. Pings from the external node are reaching the internal node on the tinc0 interface but nothing happens after that. Now that I'm thinking of it, I did some masquerading in order to get OpenVPN to work on another box, I wonder if that would be applicable here?

Hi Kismet, Am Wed, 5 Oct 2016 10:13:13 -0400 schrieb "Kismet Agbasi" <kagbasi at centraltruck.net>: > At this point I'm unsure of which information to provide in order to elicit > some assistance, however, below is the routing table of one INTERNAL and > EXTERNAL node. I basically want to be able to reach the 172.23.6.0 network > from any of the EXTERNAL nodes -

On 05/10/2016 16:13, Kismet Agbasi wrote: > I have a 4 Node Tinc VPN setup with 2 nodes on my LAN and the other 2 > outside the LAN in the cloud. Everything has been working great for about 5 > years now, until today when I decided to move one of the nodes to another > box. Hi Kismet, Just thought I'd jump in here as I do a lot of this kind of thing, and in case you haven't

Hi All, I am trying to setup the site-to-site VPN with TINC for connect my home network to company network. Here is the IP allocation and configuration for your reference. Home PC (192.168.1.2) ?-----? Home (OPENWRT Router, 192.168.1.1, 10.0.0.1) ?----------------? INTERNET ?-------------? COMPANY (Windows 7 PC,192.168.2.1, 10.0.0.2) ?------------? COMPANY (SERVER ZONE) ?----? SERVER A

El 12 de febrero de 2016 16:51:59 CET, Eric Yau <ericyaukhy at hotmail.com> escribi?: >Hi All, > > > >I am trying to setup the site-to-site VPN with TINC for connect my home >network to company network. Here is the IP allocation and configuration >for >your reference. > > > >Home PC (192.168.1.2) ?-----? Home (OPENWRT Router, 192.168.1.1, >10.0.0.1)

So, with the updated HAL, I'm now able to negotiate an IP address via DHCP over the WLAN. Huzzah! But I've got two questions (now that I can use the card): ath(4) doesn't contain a list of media nor mediaopt settings that can be used. Some are detailed down in EXAMPLES, but there's no comprehensive list. (As well, and this is minor, the speeds are explicitly listed for 802.11a

Hi, Not sure if this is useful but I have had no problems with the belkin 54G PCMCIA cards and ndiswrapper. Arun -----Original Message----- From: centos-bounces at centos.org [mailto:centos-bounces at centos.org]On Behalf Of Brian Watters Sent: Thursday, October 27, 2005 6:29 AM To: CentOS mailing list Subject: Re: [CentOS] CentOS 4.x friendly WiFi Cards?? Thanks for the fast reply .. I

On 06/10/2016 15:48, Kismet Agbasi wrote: >> Did you remember to activate kernel ip forwarding? >> i.e. echo 1 > /proc/sys/net/ipv4/ip_forward ? > I actually forgot to do this, but I have enabled it now in /etc/systctl.conf and can confirm now after a reboot that it's enabled. Unfortunately, still can't ping the node on the LAN. OK , let's just do one other simple

On 06/10/2016 16:33, Kismet Agbasi wrote: > Thanks Keith. Here's the output: OK. I'd like to say that I recognize this is now off topic for the tinc list, as it really is about basic routing and firewalls and has little if anything to do with tinc at this point. However, it's a low volume list, so unless anyone complains, lets thrash it out here. > wrong interface......hmmm.

Dear Lance, It is not work. Any idea? Regards, Eric -----Original Message----- From: Lance Fredrickson [mailto:lancethepants at gmail.com] Sent: Wednesday, February 17, 2016 12:53 AM To: tinc at tinc-vpn.org Subject: Re: Tinc Router Mode - PING RESULT is destination host unreachable On 2/16/2016 9:04 AM, Eric Yau wrote: > Hi Lars, > > Once I modify the firewall FORWARD rule to

Hi, I'm sometimes getting a failure of connecting 2 nodes when Tinc is started and configured in a LAN. In the logs, there are some unexpected dropped packets with very high or negative seq. I can reproduce this issue ~2% of the time. When this happens, the 2 nodes can no longer ping or ssh each other through the tunnel interface but using eth0 works fine. The connection can recover after at

Hello, I almost always get a panic when running kismet on my ipw-Interface under 6.1-PRERELEASE. This has been the case ever since ipw hit the tree. Sometimes kismet works, sometimes it doesn't. A sure way to trigger the panic is to switch between bss/ibss/monitor mode prior to running kismet. Perhaps there is a bug in the re-initialization when loading a different firmware? Is this panic

Hallo, after change net-infrastructure on a multinetwork-server can on segment not find the logon-server. Source problem is, that nmbd sending UDP/138 answers from a false IP. 12:08:08.909997 IP 123.4.5.6.138 > 123.4.7.7.138: NBT UDP PACKET(138) 12:08:08.910083 IP 10.9.0.1.138 > 123.4.5.5.138: NBT UDP PACKET(138) UDP/137 and all TCP-traffic are O.K. My server has two active netcards for

Hallo, after change net-infrastructure on a multinetwork-server can on segment not find the logon-server. Source problem is, that nmbd sending UDP/138 answers from a false IP. 12:08:08.909997 IP 123.4.5.6.138 > 123.4.7.7.138: NBT UDP PACKET(138) 12:08:08.910083 IP 10.9.0.1.138 > 123.4.5.5.138: NBT UDP PACKET(138) UDP/137 and all TCP-traffic are O.K. My server has two active netcards for