Unable to stop tunnel from being "connection-tracked"

Unable to stop tunnel from being "connection-tracked"

[Wouter Vanwalleghem]

hi all,

I have setup a 6-in-4 tunnel which is giving me head-aches.
FYI, I use kernel 2.4.21 and iptables 1.2.8.

As soon as I start using the tunnel the output of "cat
/proc/net/ip_conntrack" shows a protocol 41 connection between my
firewall and the IPv4 PoP of the tunnelbroker. 
OK so far. 

But if I then stop using the tunnel, above-mentioned connection
disappears from the connection tracking table after 600 seconds.
Normal behaviour.

Thing is that the tunnel "dies" as soon as the connection has
disappeared from the connection tracking table.

After some research I followed a suggestion to keep the tunnel from
being connection tracked.
However, the following iptables rules do not prevent the tunnel from
popping up in the connection tracking table:


#####------------ IPv6 tunnel to SixXS-----
iptables -A INPUT -p 41 -s tunnelserver.concepts-ict.net -j ACCEPT
iptables -A OUTPUT -p 41 -d tunnelserver.concepts-ict.net -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -s
tunnelserver.concepts-ict.net -j ACCEPT
iptables -t nat -A POSTROUTING --protocol ! 41 -s 192.168.100.0/24 -o
ppp0 -j MASQUERADE

The ip6tables tables are all empty and all policies are set to ACCEPT.
I cannot do without the MASQUERADE'ing rule because I still want my LAN
to have connectivity.

Anybody have a clue?

TIA

kind regards,

Wouter

Re: Unable to stop tunnel from being "connection-tracked"

[Ramin Dousti]

On Thu, Oct 02, 2003 at 01:10:09PM +0200, Wouter Vanwalleghem wrote:

> hi all,
> 
> I have setup a 6-in-4 tunnel which is giving me head-aches.
> FYI, I use kernel 2.4.21 and iptables 1.2.8.
> 
> As soon as I start using the tunnel the output of "cat
> /proc/net/ip_conntrack" shows a protocol 41 connection between my
> firewall and the IPv4 PoP of the tunnelbroker. 
> OK so far. 
> 
> But if I then stop using the tunnel, above-mentioned connection
> disappears from the connection tracking table after 600 seconds.
> Normal behaviour.
> 
> Thing is that the tunnel "dies" as soon as the connection has
> disappeared from the connection tracking table.

What do you mean by "the tunnel dies"? That you cannot send anything
through it anymore after the conntrack entry has been cleared? How
does the routing look like, how do you direct the traffic through
the tunnel?

I take that the tunnel endpoint on your side is the external interface (ppp0)
if so, the MASQUERADE rule below can be simplified...

Ramin

> After some research I followed a suggestion to keep the tunnel from
> being connection tracked.
> However, the following iptables rules do not prevent the tunnel from
> popping up in the connection tracking table:
> 
> 
> #####------------ IPv6 tunnel to SixXS-----
> iptables -A INPUT -p 41 -s tunnelserver.concepts-ict.net -j ACCEPT
> iptables -A OUTPUT -p 41 -d tunnelserver.concepts-ict.net -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type echo-request -s
> tunnelserver.concepts-ict.net -j ACCEPT
> iptables -t nat -A POSTROUTING --protocol ! 41 -s 192.168.100.0/24 -o
> ppp0 -j MASQUERADE
> 
> The ip6tables tables are all empty and all policies are set to ACCEPT.
> I cannot do without the MASQUERADE'ing rule because I still want my LAN
> to have connectivity.
> 
> Anybody have a clue?
> 
> TIA
> 
> kind regards,
> 
> Wouter

Re: Unable to stop tunnel from being "connection-tracked"

[Wouter Vanwalleghem]

On Thu, 2003-10-02 at 15:52, Ramin Dousti wrote:
(snip)
>> Thing is that the tunnel "dies" as soon as the connection has
> > disappeared from the connection tracking table.
> 
> What do you mean by "the tunnel dies"? That you cannot send anything
> through it anymore after the conntrack entry has been cleared? How
> does the routing look like, how do you direct the traffic through
> the tunnel?
> 

What I mean is, that if I let the connection disappear from the
connection tracking table, immediately afterwards, I no longer get any
replies on my ping6's to the tunnelbroker PoP IPv6 address. A tcpdump on
my external interface (ppp0) only shows my echo-requests and no packets
whatsoever coming from the tunnelbroker PoP. I would at least expect to
see some or other packet, e.g. an icmp error message, coming from the
tunnelbroker PoP.

> I take that the tunnel endpoint on your side is the external interface (ppp0)
> if so, the MASQUERADE rule below can be simplified...

I suppose you mean by leaving out the source address specification? I
know, I just put it in in an attempt to stop the connection tracking
from happening, but alas...

> Ramin
> 
> > After some research I followed a suggestion to keep the tunnel from
> > being connection tracked.
> > However, the following iptables rules do not prevent the tunnel from
> > popping up in the connection tracking table:
> > 
> > 
> > #####------------ IPv6 tunnel to SixXS-----
> > iptables -A INPUT -p 41 -s tunnelserver.concepts-ict.net -j ACCEPT
> > iptables -A OUTPUT -p 41 -d tunnelserver.concepts-ict.net -j ACCEPT
> > iptables -A INPUT -p icmp --icmp-type echo-request -s
> > tunnelserver.concepts-ict.net -j ACCEPT
> > iptables -t nat -A POSTROUTING --protocol ! 41 -s 192.168.100.0/24 -o
> > ppp0 -j MASQUERADE
> > 
> > The ip6tables tables are all empty and all policies are set to ACCEPT.
> > I cannot do without the MASQUERADE'ing rule because I still want my LAN
> > to have connectivity.
> > 
> > Anybody have a clue?
> > 
> > TIA
> > 
> > kind regards,
> > 
> > Wouter

Re: Unable to stop tunnel from being "connection-tracked"

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

> A tcpdump on my external interface (ppp0) only shows my echo-requests
> and no packets whatsoever coming from the tunnelbroker PoP. I would at
> least expect to see some or other packet, e.g. an icmp error message,
> coming from the tunnelbroker PoP.

iptables doesn't prevent packets from showing up in tcpdump.  So you
will always see everything you receive on the wire in tcpdump,
independent of any iptables configuration.

this is because tcpdump hooks into PF_PACKET, which is at layer2, before
the ipstack (and thus iptables) is consulted at all.

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unable to stop tunnel from being "connection-tracked"

[Ramin Dousti]

On Thu, Oct 02, 2003 at 09:35:18PM +0200, Wouter Vanwalleghem wrote:

> What I mean is, that if I let the connection disappear from the
> connection tracking table, immediately afterwards, I no longer get any
> replies on my ping6's to the tunnelbroker PoP IPv6 address. A tcpdump on
> my external interface (ppp0) only shows my echo-requests and no packets
> whatsoever coming from the tunnelbroker PoP. I would at least expect to
> see some or other packet, e.g. an icmp error message, coming from the
> tunnelbroker PoP.

As Harald mentioned earlier, you tcpdump should see everything. If it
doesn't it might mean that the response is not being sent back or is not
being delivered correctly, or, the requests didn't make it to the
other end of the tunnel. Is there any possibility for you to validate
the receipt of the ping packets at the other end?

Ramin

Re: Unable to stop tunnel from being "connection-tracked"

[Wouter Vanwalleghem]

On Fri, 2003-10-03 at 21:43, Ramin Dousti wrote:
> On Thu, Oct 02, 2003 at 09:35:18PM +0200, Wouter Vanwalleghem wrote:
> 
> > What I mean is, that if I let the connection disappear from the
> > connection tracking table, immediately afterwards, I no longer get any
> > replies on my ping6's to the tunnelbroker PoP IPv6 address. A tcpdump on
> > my external interface (ppp0) only shows my echo-requests and no packets
> > whatsoever coming from the tunnelbroker PoP. I would at least expect to
> > see some or other packet, e.g. an icmp error message, coming from the
> > tunnelbroker PoP.
> 
> As Harald mentioned earlier, you tcpdump should see everything. If it
> doesn't it might mean that the response is not being sent back or is not
> being delivered correctly, or, the requests didn't make it to the
> other end of the tunnel. Is there any possibility for you to validate
> the receipt of the ping packets at the other end?
> 
> Ramin

I had been suspecting that the problem is not so much with my firewall
(rules) but something fishy happening on the tunnelbroker machine. The
things you and Harald have been telling me seem to confirm my
suspicions.

I am currently in contact with the tunnelbroker maintainer and checking
wether my pings reach the end of the tunnel is one of the things on the
check-list. I will get back to you with the result.

Thanks for your trouble so far.
And that goes for Harald too, of course.

Wouter

Re: Unable to stop tunnel from being "connection-tracked"

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

On Thu, Oct 02, 2003 at 01:10:09PM +0200, Wouter Vanwalleghem wrote:
> hi all,
> 
> I have setup a 6-in-4 tunnel which is giving me head-aches.
> FYI, I use kernel 2.4.21 and iptables 1.2.8.
> 
> As soon as I start using the tunnel the output of "cat
> /proc/net/ip_conntrack" shows a protocol 41 connection between my
> firewall and the IPv4 PoP of the tunnelbroker. 
> OK so far. 

yup.  That's how it is on my 6to4 tunnel gateway, too.

> Thing is that the tunnel "dies" as soon as the connection has
> disappeared from the connection tracking table.
> 
> After some research I followed a suggestion to keep the tunnel from
> being connection tracked.

impossible with stock iptables. 

> However, the following iptables rules do not prevent the tunnel from
> popping up in the connection tracking table:
> 
> 
> #####------------ IPv6 tunnel to SixXS-----
> iptables -A INPUT -p 41 -s tunnelserver.concepts-ict.net -j ACCEPT
> iptables -A OUTPUT -p 41 -d tunnelserver.concepts-ict.net -j ACCEPT
> iptables -A INPUT -p icmp --icmp-type echo-request -s
> tunnelserver.concepts-ict.net -j ACCEPT
> iptables -t nat -A POSTROUTING --protocol ! 41 -s 192.168.100.0/24 -o
> ppp0 -j MASQUERADE

Why should this prevent connection tracking from tracking the tunnel?
Connection tracking always tracks all packets, as described in the docs.

It's just a quesion on whether you want to use the information provided
by conntrack or not.  And this totally depends on your ruleset.

> Anybody have a clue?

This has to be somehow related to your local setup/configuration.  I am
running 6to4 tunnels on a lot of firewalls without any problems.

> kind regards,
> Wouter

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]