NAT routing and GRE

Hi,

I have a linux box running as a nat router. Policy accept on all queues. NAT is activated with

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Clients from inside occasionally start a windows PPTP connection to outside servers. All is well so far.

There is one server outside they can not connect to. I traced the problem down to the following: the TCP+PPP
connection from inside is working fine. But the first IP+GRE packet comes from outside. This packet triggers a
ICMP destination unreachable (protocol unreachable) message.

A search for this protocols turns up a lot of outdated information. Could you give me a pointer? The router is
a opensuse 11.0 (because of hardware support).

Max

Am Wed, 22 Oct 2008 06:53:07 +0200 schrieb M. Strobel:

> Hi,
>
> I have a linux box running as a nat router. Policy accept on all queues. NAT is activated with
>
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
>
> Clients from inside occasionally start a windows PPTP connection to outside servers. All is well so far.
>
> There is one server outside they can not connect to. I traced the problem down to the following: the TCP+PPP
> connection from inside is working fine. But the first IP+GRE packet comes from outside. This packet triggers a
> ICMP destination unreachable (protocol unreachable) message.
>
> A search for this protocols turns up a lot of outdated information. Could you give me a pointer? The router is
> a opensuse 11.0 (because of hardware support).
>
> Max

You've no gre running?
Do you need gre, its a protocol to transmit routing information (Generic
routing encapsulation protocol)

cheers

On 22 Okt., 08:38, Burkhard Ott <n...@derith.de> wrote:
> Am Wed, 22 Oct 2008 06:53:07 +0200 schrieb M. Strobel:
>
>
>
> > Hi,
>
> > I have a linux box running as a nat router. Policy accept on all queues. NAT is activated with
>
> > iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
>
> > Clients from inside occasionally start a windows PPTP connection to outside servers. All is well so far.
>
> > There is one server outside they can not connect to. I traced the problem down to the following: the TCP+PPP
> > connection from inside is working fine. But the first IP+GRE packet comes from outside. This packet triggers a
> > ICMP destination unreachable (protocol unreachable) message.
>
> > A search for this protocols turns up a lot of outdated information. Could you give me a pointer? The router is
> > a opensuse 11.0 (because of hardware support).
>
> > Max
>
> You've no gre running?
> Do you need gre, its a protocol to transmit routing information (Generic
> routing encapsulation protocol)
>
> cheers

Okay, I found a link to ip_gre.o module

Do I need it? I only want to route the traffic through.

Max

Am Wed, 22 Oct 2008 01:31:50 -0700 schrieb kontakt:


> Okay, I found a link to ip_gre.o module
>
> Do I need it? I only want to route the traffic through.
>
> Max

http://en.wikipedia.org/wiki/Point-t...eling_Protocol
afaik you do.
Why aren't you using ipsec?
http://www.worldnet-long-distance.co...ages-PPTP.html
cheers

Burkhard Ott schrieb:
> Am Wed, 22 Oct 2008 01:31:50 -0700 schrieb kontakt:
>
>
>> Okay, I found a link to ip_gre.o module
>>
>> Do I need it? I only want to route the traffic through.
>>
>> Max
>
> http://en.wikipedia.org/wiki/Point-t...eling_Protocol
> afaik you do.
> Why aren't you using ipsec?

I am using what the outside servers require.

> http://www.worldnet-long-distance.co...ages-PPTP.html
> cheers

M. Strobel schrieb:
> Hi,
>
> I have a linux box running as a nat router. Policy accept on all queues. NAT is activated with
>
> iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
>
> Clients from inside occasionally start a windows PPTP connection to outside servers. All is well so far.
>
> There is one server outside they can not connect to. I traced the problem down to the following: the TCP+PPP
> connection from inside is working fine. But the first IP+GRE packet comes from outside. This packet triggers a
> ICMP destination unreachable (protocol unreachable) message.
>
> A search for this protocols turns up a lot of outdated information. Could you give me a pointer? The router is
> a opensuse 11.0 (because of hardware support).
>
> Max

Okay, solved.

I do a 'modprobe ip_nat_pptp' and it works. This is the newest module and the one loading others
(ip_nat,ip_conntrack_pptp,ip_conntrack).

Max

Hello,

M. Strobel a écrit :
>>
>> There is one server outside they can not connect to. I traced the
>> problem down to the following: the TCP+PPP
>> connection from inside is working fine.

AFAIK there is no such TCP+PPP connection in PPTP ; the PPP session is
in the GRE tunnel, not in the TCP connection.

>> But the first IP+GRE packet comes from outside.

This may happen because in PPTP the GRE tunnel transports a PPP session
and PPP is a peer-to-peer protocol, not a client-server protocol, so
either end may send the first PPP-in-GRE packet.

>> This packet triggers a
>> ICMP destination unreachable (protocol unreachable) message.

Because the router does not know what to do with the packet.

> I do a 'modprobe ip_nat_pptp' and it works.

This is the best and easiest solution when the kernel supports it. PPTP
conntrack/NAT support is in mainline since Linux 2.6.14. In recent
kernels (2.6.20 and 2.6.21 with nf_conntrack enabled, 2.6.22 and above),
the module name has changed to "nf_nat_pptp", but defines "ip_nat_pptp"
as an alias, so "modprobe ip_nat_pptp" should still work.

Otherwise I think a workaround would have be to add an iptables rule in
the INPUT chain to DROP GRE packets in the state NEW instead of
rejecting them with an ICMP error. The first GRE packets from the server
may be dropped, but the first GRE packet from the client would create a
NAT mapping and subsequent GRE packets from the server would use that
mapping. Note however that two clients would not be able to connect to
the same server, unlike in the preferred solution.

Pascal Hambourg schrieb:
> Hello,
>
> M. Strobel a écrit :
>>>
>>> There is one server outside they can not connect to. I traced the
>>> problem down to the following: the TCP+PPP
>>> connection from inside is working fine.
>
> AFAIK there is no such TCP+PPP connection in PPTP ; the PPP session is
> in the GRE tunnel, not in the TCP connection.

I see it like that: session in the tunnel, but session control in TCP+PPP.

Wireshark:
No. Time Source Destination Protocol Info
4 0.017860 85.182.170.140 62.109.79.85 PPTP Start-Control-Connection-Request

Frame 4 (210 bytes on wire, 210 bytes captured)
Ethernet II, Src: 00:1f:c6:7e:90:5f (00:1f:c6:7e:90:5f), Dst: ThomsonT_f1:e9:6d (00:14:7f:f1:e9:6d)
Internet Protocol, Src: 85.182.170.140 (85.182.170.140), Dst: 62.79.109.85 (62.79.109.85)
Transmission Control Protocol, Src Port: mtport-regist (2791), Dst Port: pptp (1723), Seq: 1, Ack: 1, Len: 156
Point-to-Point Tunnelling Protocol


>
>>> But the first IP+GRE packet comes from outside.
>
> This may happen because in PPTP the GRE tunnel transports a PPP session
> and PPP is a peer-to-peer protocol, not a client-server protocol, so
> either end may send the first PPP-in-GRE packet.
>
>>> This packet triggers a
>>> ICMP destination unreachable (protocol unreachable) message.
>
> Because the router does not know what to do with the packet.
>
>> I do a 'modprobe ip_nat_pptp' and it works.
>
> This is the best and easiest solution when the kernel supports it. PPTP
> conntrack/NAT support is in mainline since Linux 2.6.14. In recent
> kernels (2.6.20 and 2.6.21 with nf_conntrack enabled, 2.6.22 and above),
> the module name has changed to "nf_nat_pptp", but defines "ip_nat_pptp"
> as an alias, so "modprobe ip_nat_pptp" should still work.
>
> Otherwise I think a workaround would have be to add an iptables rule in
> the INPUT chain to DROP GRE packets in the state NEW instead of
> rejecting them with an ICMP error. The first GRE packets from the server
> may be dropped, but the first GRE packet from the client would create a
> NAT mapping and subsequent GRE packets from the server would use that
> mapping. Note however that two clients would not be able to connect to
> the same server, unlike in the preferred solution.

M. Strobel a écrit :
> Pascal Hambourg schrieb:
>>
>> AFAIK there is no such TCP+PPP connection in PPTP ; the PPP session is
>> in the GRE tunnel, not in the TCP connection.
>
> I see it like that: session in the tunnel, but session control in TCP+PPP.

The PPTP session control is in the TCP connection, but the PPP session
control (LCP, PAP/CHAP authentication, IPCP...) is in the GRE tunnel,
with the rest of the PPP session.