tinc connection only usable after ping from other side
Moritz Maisel
I implemented a little client server scenario with tinc to give a
notebook (connected to the "Server" via WLAN) access to the local lan
(both Linux OS). I'll try to explain the problem I got:
The configuration seems to be ok: The tinc-connection is set up correctly
and after it is set up, the server can ping the client.
The problem is, that after the connection is startet the client isn't
able to ping the server (the server doesn't answer the ping requests).
I first have to ping FROM the server TO the client. After that the client
can also ping the server and has access to the LAN.
Ok, I can tell the server to ping the client after connect via
"hosts/<host>-up" to "open" the connection, but that is a pretty
dirty workaround, I think.
I also tried different routing/address scenarios but I always get this
problem. So i suppose it's a tinc-problem.
Does anyone of you have an idea that could help me?
Thanks,
Moritz
Tinc: Discussion list about the tinc VPN daemon
Archive: http://mail.nl.linux.org/lists/
Tinc site: http://tinc.nl.linux.org/
Guus Sliepen
> The configuration seems to be ok: The tinc-connection is set up correctly
> and after it is set up, the server can ping the client.
> The problem is, that after the connection is startet the client isn't
> able to ping the server (the server doesn't answer the ping requests).
> I first have to ping FROM the server TO the client. After that the client
> can also ping the server and has access to the LAN.
It's caused by a masquerading firewall on your server's side.
Fix your masquerading firewall (look at the examples on tinc's website)
or use TCPOnly = yes (see the documentation).
> I also tried different routing/address scenarios but I always get this
> problem. So i suppose it's a tinc-problem.
No it's not :)
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <gu...@sliepen.eu.org>
uws
> On Fri, Jan 16, 2004 at 12:03:31PM +0000, Moritz Maisel wrote:
> > The configuration seems to be ok: The tinc-connection is set up correctly
> > and after it is set up, the server can ping the client.
> > The problem is, that after the connection is startet the client isn't
> > able to ping the server (the server doesn't answer the ping requests).
> > I first have to ping FROM the server TO the client. After that the client
> > can also ping the server and has access to the LAN.
> It's caused by a masquerading firewall on your server's side.
> Fix your masquerading firewall (look at the examples on tinc's website)
> or use TCPOnly = yes (see the documentation).
I'm experiencing exactly the same problem as Moritz Maisel does. I run a
masquerading firewall on my server host. Even when using TCPOnly = yes
(which is what I use for all my connections) the problem persists. Any clue?
mvrgr, Wouter
--
:wq mail u...@xs4all.nl
tell myself that i'm not ready yet :: i want to live -- heather nova
Guus Sliepen
> > It's caused by a masquerading firewall on your server's side.
> > Fix your masquerading firewall (look at the examples on tinc's website)
> > or use TCPOnly = yes (see the documentation).
>
> I'm experiencing exactly the same problem as Moritz Maisel does. I run a
> masquerading firewall on my server host. Even when using TCPOnly = yes
> (which is what I use for all my connections) the problem persists. Any clue?
Stateful firewall rules?
The only other thing I can imagine is if you use the ethertap device
instead of the tun/tap device and have set a different MAC address than
fe:fd:0:0:0:0 and haven't disabled ARP.
uws
> On Fri, Jan 16, 2004 at 02:33:18PM +0100, uws wrote:
> > > It's caused by a masquerading firewall on your server's side.
> > > Fix your masquerading firewall (look at the examples on tinc's website)
> > > or use TCPOnly = yes (see the documentation).
> > I'm experiencing exactly the same problem as Moritz Maisel does. I run a
> > masquerading firewall on my server host. Even when using TCPOnly = yes
> > (which is what I use for all my connections) the problem persists. Any clue?
> Stateful firewall rules?
> The only other thing I can imagine is if you use the ethertap device
> instead of the tun/tap device and have set a different MAC address than
> fe:fd:0:0:0:0 and haven't disabled ARP.
You can view my firewall script at [1]. The tinc daemon runs on the same
machine as the firewall script, so I don't need portforwarding. This box has
(1) a pptp internet connection to the internet over a (2) dedicated cross
cable LAN to my ADSL modem and a (3) local area network connection to other
hosts. Everything works just fine, except for tinc.
Also, my 2.4 kernel's .config file contains
| # CONFIG_ETHERTAP is not set
| CONFIG_TUN=y
...so I suppose I'm using the correct device.
mvrgr, Wouter
[1] http://www.xs4all.nl/~uws/firewall/
--
:wq mail u...@xs4all.nl
we'd drink and get high until late :: and now we're all alone -- placebo
Guus Sliepen
> > Stateful firewall rules?
>
> You can view my firewall script at [1]. The tinc daemon runs on the same
> machine as the firewall script, so I don't need portforwarding. This box has
> (1) a pptp internet connection to the internet over a (2) dedicated cross
> cable LAN to my ADSL modem and a (3) local area network connection to other
> hosts. Everything works just fine, except for tinc.
The relevant lines from your firewall script are:
$IPTABLES --policy INPUT DROP
$IPTABLES --append INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
And remember that tinc's UDP packets are sent and received to and from
$EXTERNALIF.
Moritz Maisel
> It's caused by a masquerading firewall on your server's side.
> Fix your masquerading firewall (look at the examples on tinc's website)
> or use TCPOnly = yes (see the documentation).
You were right. With "TCPOnly = yes" it works. :-)
--
PGP key: http://www.nachtaktiv.org/maisel.asc
uws
> On Fri, Jan 16, 2004 at 07:25:24PM +0100, uws wrote:
> > > Stateful firewall rules?
> > You can view my firewall script at [1]. The tinc daemon runs on the same
> > machine as the firewall script, so I don't need portforwarding. This box has
> > (1) a pptp internet connection to the internet over a (2) dedicated cross
> > cable LAN to my ADSL modem and a (3) local area network connection to other
> > hosts. Everything works just fine, except for tinc.
> The relevant lines from your firewall script are:
> $IPTABLES --policy INPUT DROP
> $IPTABLES --append INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
> And remember that tinc's UDP packets are sent and received to and from
> $EXTERNALIF.
However, I use "TCPonly = yes" for all my connections, because the other
side is always behind a NAT router.
The only oddness I just discovered, is that I used "TCPonly" (without
capital O) instead of "TCPOnly" in my hosts config files. I can't test right
now, but does this make a difference?
mvrgr, Wouter
--
:wq mail u...@xs4all.nl
and it's you i see :: but you don't see me -- coldplay
Guus Sliepen
> > $IPTABLES --policy INPUT DROP
> > $IPTABLES --append INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
>
> > And remember that tinc's UDP packets are sent and received to and from
> > $EXTERNALIF.
>
> However, I use "TCPonly = yes" for all my connections, because the other
> side is always behind a NAT router.
>
> The only oddness I just discovered, is that I used "TCPonly" (without
> capital O) instead of "TCPOnly" in my hosts config files. I can't test right
> now, but does this make a difference?
As you can read in the manpages:
This file consists of comments (lines started with a #) or assignments
in the form of:
Variable = Value.
The variable names are case insensitive, and any spaces, tabs, newlines
and carriage returns are ignored. Note: it is not required that you put
in the = sign, but doing so improves readability.
Anyway, check whether a firewall rule blocks packets by using this
command:
watch -d -n 1 iptables -L -v -x -n
If that doesn't show anything unusual, use tcpdump on $EXTERNALIF and
$TINCIF to see what kind of packets are sent/received on which
interface.