GRE protocol .

GRE protocol .

[ratheesh k]

Router wan interface is eth1 and lan interface is eth0 .

iptables  -A INPUT  -m state --state ESTABLISHED , RELATED  -j ACCEPT .
iptables  -A INPUT  -i eth1 -j DROP .
iptables  -A INPUT  -i eth0 -j ACCEPT

iptables  -A FORWAR -m state  --state ESTABLISHED , RELATED  -j ACCEPT
iptables  -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables  -A FORWARD -i eth1 -o eth0 -j DROP .

I dont have pptp connection  tracking module installed .  But i can
see GRE protocol packet comed from wan gets routed and reaches my
client machine   connected  to eth0 ?.

I can see message id is 0 in GRE packet .
I have only pptp connection .

Any hint is really appreciated ?

Thanks,
Ratheesh

Re: GRE protocol .

[ratheesh k]

On Sat, May 1, 2010 at 2:11 AM,  <valerio.balbi@gmail.com> wrote:
> It's not clea r (sorry).

iptable rules configured in my gateway machine ( which act as a router
)  has no rule to allow GRE packet coming from wan side to pass thru .
There is no ALGs loaded . Still i am able to establish a pptp
connection . I can see GRE packet reached client machine using a
wireshark .

Thanks,
Ratheesh

On Sat, May 1, 2010 at 2:11 AM,  <valerio.balbi@gmail.com> wrote:
> It's not clear (sorry). Anyway you can log or reject the gre protocol without any protocol inner inspection module.
> Gre protocol is paritetical to tcp. I'm not in my deskbox, but I remember that gre protocol has protocol number 49 perhaps. So you can trace gre connection tracing searching packet with protocol number equal to 49.
>
> My 2 cents.
> ------Messaggio originale------
> Da: ratheesh k
> Mittente:netfilter-owner@vger.kernel.org
> A:netfilter@vger.kernel.org
> Oggetto: GRE protocol .
> Inviato: 30 Apr 2010 09:19
>
> Router wan interface is eth1 and lan interface is eth0 .
>
> iptables  -A INPUT  -m state --state ESTABLISHED , RELATED  -j ACCEPT .
> iptables  -A INPUT  -i eth1 -j DROP .
> iptables  -A INPUT  -i eth0 -j ACCEPT
>
> iptables  -A FORWAR -m state  --state ESTABLISHED , RELATED  -j ACCEPT
> iptables  -A FORWARD -i eth0 -o eth1 -j ACCEPT
> iptables  -A FORWARD -i eth1 -o eth0 -j DROP .
>
> I dont have pptp connection  tracking module installed .  But i can
> see GRE protocol packet comed from wan gets routed and reaches my
> client machine   connected  to eth0 ?.
>
> I can see message id is 0 in GRE packet .
> I have only pptp connection .
>
> Any hint is really appreciated ?
>
> Thanks,
> Ratheesh
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> Le mail ti raggiungono ovunque con BlackBerry® from Vodafone!

Re: GRE protocol .

[valerio balbi]

On Sat, May 1, 2010 at 6:54 AM, ratheesh k <ratheesh.ksz@gmail.com> wrote:
> On Sat, May 1, 2010 at 2:11 AM,  <valerio.balbi@gmail.com> wrote:
>> It's not clea r (sorry).
>
> iptable rules configured in my gateway machine ( which act as a router
> )  has no rule to allow GRE packet coming from wan side to pass thru .
> There is no ALGs loaded . Still i am able to establish a pptp
> connection . I can see GRE packet reached client machine using a
> wireshark .
>


if the problem where in my lan I will probably proceed in this way
trying to isolate the fenomena:

check the global policy of my FORWARD chain implementing DROP default

creation of a new chain:
/sbin/iptables -N pptp
/sbin/iptables -A pptp -p tcp --destination-port 1723 --dst
$SERVERPPTP -j ACCEPT
/sbin/iptables -A pptp -p 47 --dst $SERVERPPTP -j ACCEPT

plug of the new chain into FORWARD one like first:
/sbin/iptables -I FORWARD 0  -j pptp

repeat the same for nat PREROUTING
/sbin/iptables -t nat -N pptp
/sbin/iptables -t nat -A pptp -p tcp --dport 1723 -j DNAT --to $SERVERPPTP:1723
/sbin/iptables -t nat -A pptp -p 47 -j DNAT --to $SERVERPPTP
/sbin/iptables -t nat -A PREROUTING -j pptp


this way you can control if the new rules were matched or not
if where matched you can stop the connection
if not I will gather more information from my network topology looking
for an alternate router machine.

I hope this will help you
bye

Re: GRE protocol .

[ratheesh k]

On Sat, May 1, 2010 at 2:39 PM, valerio balbi <valerio.balbi@gmail.com> wrote:
> On Sat, May 1, 2010 at 6:54 AM, ratheesh k <ratheesh.ksz@gmail.com> wrote:
>> On Sat, May 1, 2010 at 2:11 AM,  <valerio.balbi@gmail.com> wrote:
>>> It's not clea r (sorry).
>>
>> iptable rules configured in my gateway machine ( which act as a router
>> )  has no rule to allow GRE packet coming from wan side to pass thru .
>> There is no ALGs loaded . Still i am able to establish a pptp
>> connection . I can see GRE packet reached client machine using a
>> wireshark .
>>
>
>
> if the problem where in my lan I will probably proceed in this way
> trying to isolate the fenomena:
>
> check the global policy of my FORWARD chain implementing DROP default
>
> creation of a new chain:
> /sbin/iptables -N pptp
> /sbin/iptables -A pptp -p tcp --destination-port 1723 --dst
> $SERVERPPTP -j ACCEPT
> /sbin/iptables -A pptp -p 47 --dst $SERVERPPTP -j ACCEPT
>
> plug of the new chain into FORWARD one like first:
> /sbin/iptables -I FORWARD 0  -j pptp
>
> repeat the same for nat PREROUTING
> /sbin/iptables -t nat -N pptp
> /sbin/iptables -t na t -A pptp -p tcp --dport 1723 -j DNAT --to $SERVERPPTP:1723
> /sbin/iptables -t nat -A pptp -p 47 -j DNAT --to $SERVERPPTP
> /sbin/iptables -t nat -A PREROUTING -j pptp
>
>
> this way you can control if the new rules were matched or not
> if where matched you can stop the connection
> if not I will gather more information from my network topology looking
> for an alternate router machine.
>
> I hope this will help you
> bye
>

pptp pass thru works because gre connection tracking  module was built
as part of kernel in my linux machine . I thought pptp_connection
tracking module is the ALG for pptp connection . But without
pptp_connection tracking also , pptp pass thru works fine .

Then  , why we need pptp_connection_tracking  module ?

Thanks,
Ratheesh

Re: GRE protocol .

[Pascal Hambourg]

Hello,

ratheesh k a écrit :
>>> iptable rules configured in my gateway machine (which act as a router)
>>> has no rule to allow GRE packet coming from wan side to pass thru.
>>> There is no ALGs loaded. Still i am able to establish a pptp
>>> connection. I can see GRE packet reached client machine using a
>>> wireshark .

This is probably because the GRE connection is created from inside by
the client machine. In PPTP, GRE encapsulation is used to transport PPP
packets ; PPP is a peer-to-peer protocol, not a client-server protocol,
so both ends may send packets at the same time. If the first GRE packet
is sent by the PPTP client it is allowed in by your ruleset and creates
the connection, so the subsequent GRE packets from the server are in the
ESTABLISHED state and accepted. If the first GRE packet is sent by the
PPTP server, it is dropped by your ruleset but it does not matter,
because the connection will be created anyway when the client sends its
first GRE packet (see above case), and the server will eventuellaly
retransmit the dropped packets.

Note that if your router does masquerading, this works for only one PPTP
connection to the same server. For simultaneous connections from several
internal clients to the same server, you must use the PPTP helper, so
the router knows which client the return GRE packets are to be forwarded to.

> pptp pass thru works because gre connection tracking  module was built
> as part of kernel in my linux machine. I thought pptp_connection
> tracking module is the ALG for pptp connection.

Yes it is (actually the module is named nf_conntrack_pptp, which uses
nf_conntrack_proto_gre).

> But without
> pptp_connection tracking also , pptp pass thru works fine .

Not in all situations, as I wrote above.

> Then, why we need pptp_connection_tracking  module ?

For instance you need it when several clients behind the same
masquerading router connect simulaneously to the same server, or when
the iptables ruleset does not allow any NEW packet out, so you must know
that a GRE packet is RELATED to an existing PPTP connection.

Re: GRE protocol .

[ratheesh k]

On Thu, May 6, 2010 at 8:35 PM, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> Hello,
>
> ratheesh k a écrit :
>>>> iptable rules configured in my gateway machine (which act as a router)
>>>> has no rule to allow GRE packet coming from wan side to pass thru.
>>>> There is no ALGs loaded. Still i am able to establish a pptp
>>>> connection. I can see GRE packet reached client machine using a
>>>> wireshark .
>
> This is probably because the GRE connection is created from inside by
> the client machine. In PPTP, GRE encapsulation is used to transport PPP
> packets ; PPP is a peer-to-peer protocol, not a client-server protocol,
> so both ends may send packets at the same time. If the first GRE packet
> is sent by the PPTP client it is allowed in by your ruleset and creates
> the connection, so the subsequent GRE packets from the server are in the
> ESTABLISHED state and accepted. If the first GRE packet is sent by the
> PPTP server, it is dropped by your ruleset but it does not matter,
> because the connection will be created anyway when the client sends its
> first GRE packet (see above case), and the server will eventuellaly
> retransmit the dropped packets.
>
> Note that if your router does masquerading, this works for only one PPTP
> connection to the same server. For simultaneous connections from several
> internal clients to the same server, you must use the PPTP helper, so
> the router knows which client the return GRE packets are to be forwarded to.
>
>> pptp pass thru works because gre connection tracking  module was built
>> as part of kernel in my linux machine. I thought pptp_connection
>> tracking module is the ALG for pptp connection.
>
> Yes it is (actually the module is named nf_conntrack_pptp, which uses
> nf_conntrack_proto_gre).
>
>> But without
>> pptp_connection tracking also , pptp pass thru works fine .
>
> Not in all situations, as I wrote above.
>
>> Then, why we need pptp_connection_tracking  module ?
>
> For instance you need it when several clients behind the same
> masquerading router connect simulaneously to the same server, or when
> the iptables ruleset does not allow any NEW packet out, so you must know
> that a GRE packet is RELATED to an existing PPTP connection.
>


Thanks a lot . This cleared all my doubts . Thanks again .

-Ratheesh

Re: GRE protocol .

[ratheesh k]

> On Thu, May 6, 2010 at 8:35 PM, Pascal Hambourg
> <pascal.mail@plouf.fr.eu.org> wrote:
>so you must know
>that a GRE packet is RELATED to an existing PPTP connection.

In my case , if first  GRE packet comes from PPTP server and get
routed to my client machine , indicate that pptp_connection_tracking
module is loaded ? { get ACCEPTed by    iptables  -A FORWARD -m state
--state RELATED -j ACCEPT } .
[ pptp helper  will install expectation tuple ? ]

Thanks,
Ratheesh




On Thu, May 6, 2010 at 10:27 PM, ratheesh k <ratheesh.ksz@gmail.com> wrote:
> On Thu, May 6, 2010 at 8:35 PM, Pascal Hambourg
> <pascal.mail@plouf.fr.eu.org> wrote:
>> Hello,
>>
>> ratheesh k a écrit :
>>>>> iptable rules configured in my gateway machine (which act as a router)
>>>>> has no rule to allow GRE packet coming from wan side to pass thru.
>>>>> There is no ALGs loaded. Still i am able to establish a pptp
>>>>> connection. I can see GRE packet reached client machine using a
>>>>> wireshark .
>>
>> This is probably because the GRE connection is created from inside by
>> the client machine. In PPTP, GRE encapsulation is used to transport PPP
>> packets ; PPP is a peer-to-peer protocol, not a client-server protocol,
>> so both ends may send packets at the same time. If the first GRE packet
>> is sent by the PPTP client it is allowed in by your ruleset and creates
>> the connection, so the subsequent GRE packets from the server are in the
>> ESTABLISHED state and accepted. If the first GRE packet is sent by the
>> PPTP server, it is dropped by your ruleset but it does not matter,
>> because the connection will be created anyway when the client sends its
>> first GRE packet (see above case), and the server will eventuellaly
>> retransmit the dropped packets.
>>
>> Note that if your router does masquerading, this works for only one PPTP
>> connection to the same server. For simultaneous connections from several
>> internal clients to the same server, you must use the PPTP helper, so
>> the router knows which client the return GRE packets are to be forwarded to.
>>
>>> pptp pass thru works because gre connection tracking  module was built
>>> as part of kernel in my linux machine. I thought pptp_connection
>>> tracking module is the ALG for pptp connection.
>>
>> Yes it is (actually the module is named nf_conntrack_pptp, which uses
>> nf_conntrack_proto_gre).
>>
>>> But without
>>> pptp_connection tracking also , pptp pass thru works fine .
>>
>> Not in all situations, as I wrote above.
>>
>>> Then, why we need pptp_connection_tracking  module ?
>>
>> For instance you need it when several clients behind the same
>> masquerading router connect simulaneously to the same server, or when
>> the iptables ruleset does not allow any NEW packet out, so you must know
>> that a GRE packet is RELATED to an existing PPTP connection.
>>
>
>
> Thanks a lot . This cleared all my doubts . Thanks again .
>
> -Ratheesh
>

Re: GRE protocol .

[Pascal Hambourg]

ratheesh k a écrit :
>> On Thu, May 6, 2010 at 8:35 PM, Pascal Hambourg
>> <pascal.mail@plouf.fr.eu.org> wrote:
>> so you must know
>> that a GRE packet is RELATED to an existing PPTP connection.
> 
> In my case , if first  GRE packet comes from PPTP server and get
> routed to my client machine , indicate that pptp_connection_tracking
> module is loaded ? { get ACCEPTed by    iptables  -A FORWARD -m state
> --state RELATED -j ACCEPT } .
> [ pptp helper  will install expectation tuple ? ]

This is what I would expect, though I have not tested.