SOLVED: Unable to Pass Traffic to Internal Subnet
Kismet Agbasi
kagbasi at centraltruck.net
Wed Nov 5 19:02:24 CET 2014
I just wanted to let everyone know that I managed to solve my own problem.
Thanks though, Guus, for the suggestions.
To solve the problem I had to start all my nodes in switch mode. Followed
by adding a firewall rule to masquerade the Tinc traffic to my
/etc/ufw/before.rules file:
-A POSTROUTING -s 10.9.0.0/24 -o tinc0 -j MASQUERADE
Then on the cloud server, I had to add a route statement for my internal
network to my tinc-up file as so:
ip route add 172.23.6.0/24 via 10.9.0.1
In case anybody is wondering, 172.23.6.0/24 is my internal LAN subnet, and
10.9.0.1 is the IP of the Tinc daemon on the host serving as the main server
for my Tinc VPN network.
With this setup, I can do LDAP authentication from my Wordpress site against
my Active Directory server (at 172.23.6.127).
The only issue outstanding is that by adding a route statement to my Tinc
VPN subnet to a workstation on my LAN, I can ping all notes except for the
server's VPN ip (i.e., 10.9.0.1). There must be some internal routing I
need to do between the interfaces on that server.
Anyway, my main issue is resolved. So now I'm gonna run MTR and let it run
for a few days to check the packet loss. Once I'm satisfied with that, I'll
add additional nodes to my VPN. Thanks again for a great product.
Very Respectfully,
Kismet-Gerald Agbasi
IT/Systems Administrator
Central Truck Center, Inc.
Office: 240-487-3315
Toll Free: 1-800-492-0709
Fax: 240-487-3399
3839 Ironwood Place
Landover, MD 20785
This message may contain confidential and/or proprietary information, and is
intended for the person or entity to which it is addressed.
Any use by others for all other purposes is strictly prohibited.
____________________________________________________________________________
_____________________________
3839 Ironwood Place | Landover, MD | 20785
-----Original Message-----
From: Kismet Agbasi [mailto:kagbasi at centraltruck.net]
Sent: Thursday, October 30, 2014 7:03 PM
To: 'tinc at tinc-vpn.org'
Subject: RE: Unable to Pass Traffic to Internal Subnet
Thanks for your response. You're right in your assumptions. I followed
your suggestion and added a static route to my Tinc VPN subnet (10.9.0.0).
It worked partially. Here's the explanation: it appears that I can ping
the daemon who's host IP I specify in the route statement (hope that's
clear?).
Below are the command line results from what I tested on my Windows 7
workstation. Also, as requested, I've attached all the config files for the
three machines I've got setup right now. Currently they can all talk to
each other via the 10.9.0.0/32 IP block.
*************
Scenario #1:
*************
C:\Windows\System32>route add -p 10.9.0.0 mask 255.255.255.0 172.23.6.149
OK!
C:\Windows\System32>ping 10.9.0.1
Pinging 10.9.0.1 with 32 bytes of data:
Reply from 10.9.0.1: bytes=32 time=1ms TTL=64 Reply from 10.9.0.1: bytes=32
time=1ms TTL=64 Reply from 10.9.0.1: bytes=32 time<1ms TTL=64 Reply from
10.9.0.1: bytes=32 time<1ms TTL=64
Ping statistics for 10.9.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round
trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
C:\Windows\System32>tracert -d 10.9.0.1
Tracing route to 10.9.0.1 over a maximum of 30 hops
1 <1 ms 1 ms <1 ms 10.9.0.1
Trace complete.
C:\Windows\System32>ping 10.9.0.2
Pinging 10.9.0.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.9.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\System32>ping 10.9.0.3
Pinging 10.9.0.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.9.0.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
............................................................................
..........
************
SCENARIO #2
************
C:\Windows\System32>route delete -p 10.9.0.0 mask 255.255.255.0 172.23.6.149
OK!
C:\Windows\System32>ping 10.9.0.1
Pinging 10.9.0.1 with 32 bytes of data:
Control-C
^C
C:\Windows\System32>route add -p 10.9.0.0 mask 255.255.255.0 172.23.6.148
OK!
C:\Windows\System32>ping 10.9.0.1
Pinging 10.9.0.1 with 32 bytes of data:
Request timed out.
Ping statistics for 10.9.0.1:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), Control-C ^C
C:\Windows\System32>ping 10.9.0.2
Pinging 10.9.0.2 with 32 bytes of data:
Reply from 10.9.0.2: bytes=32 time<1ms TTL=64 Reply from 10.9.0.2: bytes=32
time<1ms TTL=64 Reply from 10.9.0.2: bytes=32 time<1ms TTL=64 Reply from
10.9.0.2: bytes=32 time<1ms TTL=64
Ping statistics for 10.9.0.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round
trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\System32>ping 10.9.0.3
Pinging 10.9.0.3 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.9.0.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\System32>
Very Respectfully,
Kismet-Gerald Agbasi
IT/Systems Administrator
Central Truck Center, Inc.
Office: 240-487-3315
Toll Free: 1-800-492-0709
Fax: 240-487-3399
3839 Ironwood Place
Landover, MD 20785
This message may contain confidential and/or proprietary information, and is
intended for the person or entity to which it is addressed. Any use by
others for all other purposes is strictly prohibited.
____________________________________________________________________________
_____________________________
3839 Ironwood Place | Landover, MD | 20785
-----Original Message-----
From: tinc [mailto:tinc-bounces at tinc-vpn.org] On Behalf Of Guus Sliepen
Sent: Monday, October 27, 2014 5:57 PM
To: tinc at tinc-vpn.org
Subject: Re: Unable to Pass Traffic to Internal Subnet
On Mon, Oct 27, 2014 at 04:50:13PM -0400, Kismet Agbasi wrote:
> 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 VPN IP: 10.9.0.3
>
> I have control of the firewall - it's a Cisco PIX 506E. What else do
> you need me to provide in order for you to be able to assist me?
Looking at the host LAN IP, I assume it's not the router of the LAN.
Therefore, even if tinc would succesfully route packets from the cloud
server to the LAN, the LAN hosts would send return packets to the gateway of
the LAN, your Cisco I assume. You should add an entry to the routing table
of the Cisco that sends packets for 10.9.0.3 to 172.23.6.148.
An alternative solution is to forget about the 10.9.0.0/24 subnet, and to
give the cloud server an IP address from the 172.23.6.0/24 range.
Either by bridging[1] or using proxy ARP[2]. This can be configured from the
LAN host running tinc without requiring any configuration of the router.
If it still doesn't work, please send a copy of the tinc.conf, tinc-up and
host config files from both the VPN host on the LAN and the cloud server.
[1] http://www.tinc-vpn.org/examples/bridging/
[2] http://www.tinc-vpn.org/examples/proxy-arp/
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus at tinc-vpn.org>
More information about the tinc
mailing list