GRE and PF problem

8 views
Skip to first unread message

Alex Povolotsky

unread,
Jul 13, 2005, 11:51:32 AM7/13/05
to
Hello!

I'm using FreeBSD (5.3-RELEASE-p5) as internet access server, and I have
to NAT GRE packets. I'm using pf.

The problem is that SOMETIMES PF fails to create proper rule using nat,
while binat works fine.

Not only I do not want to expose Windows boxes (even if those addresses
are firewalled), but it's also a terrible waste of real IPs.

Can anyone point me if I have incorrect PF config, or PF just work
poorly with gre?

Alex.


_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"

compunction

unread,
Jul 14, 2005, 1:32:18 AM7/14/05
to
GRE needs to pass bidirectional. You will need a binat to make it
work. I have not found a firewall that will allow GRE to work with a
many to one nat.

-Mark

On 7/13/05, Alex Povolotsky <tar...@webmail.sub.ru> wrote:
> Hello!
>=20


> I'm using FreeBSD (5.3-RELEASE-p5) as internet access server, and I have
> to NAT GRE packets. I'm using pf.

>=20


> The problem is that SOMETIMES PF fails to create proper rule using nat,
> while binat works fine.

>=20


> Not only I do not want to expose Windows boxes (even if those addresses
> are firewalled), but it's also a terrible waste of real IPs.

>=20


> Can anyone point me if I have incorrect PF config, or PF just work
> poorly with gre?

>=20
> Alex.
>=20
>=20

Alex Povolotsky

unread,
Jul 14, 2005, 2:43:53 AM7/14/05
to
compunction wrote:

>GRE needs to pass bidirectional. You will need a binat to make it
>work. I have not found a firewall that will allow GRE to work with a
>many to one nat.
>
>

The most painful thing is that pf's nat works for GRE - SOMETIMES :-(

The only thing firewall needs to implement for natting GRE is creation
of two rules (forward and back) for GRE packet, just like it does for ICMP.

I'm not a firewall writer, but as far as I understand general procedural
programming, it cannot be THAT complicated.

Alex.

Alex Povolotsky

unread,
Jul 14, 2005, 2:44:11 AM7/14/05
to

Alex Povolotsky

unread,
Jul 14, 2005, 2:26:01 PM7/14/05
to
Giovanni P. Tirloni wrote:

> Alex Povolotsky wrote:
>
>> compunction wrote:
>>
>>> GRE needs to pass bidirectional. You will need a binat to make it
>>> work. I have not found a firewall that will allow GRE to work with a
>>> many to one nat.
>>>
>>>
>>
>> The most painful thing is that pf's nat works for GRE - SOMETIMES :-(
>>
>> The only thing firewall needs to implement for natting GRE is
>> creation of two rules (forward and back) for GRE packet, just like it
>> does for ICMP.
>>
>> I'm not a firewall writer, but as far as I understand general
>> procedural programming, it cannot be THAT complicated.
>
>

> When a packet comes from 1.2.3.4 to your external interface you can't
> determine if it's destined to 192.168.0.1 or 192.168.0.2 if both
> initiated a GRE tunnel to 1.2.3.4. That's because GRE doesn't have
> ports like UDP or TCP to make (de)multiplexing possible, AFAIK.
>
> http://www.networksorcery.com/enp/protocol/gre.htm
>
Cool. I did not know that ICMP doesn't work through nat. It always
worked for me. Moreover, as far as I remember, GRE worked with
IPFW/NATD, and SOMETIMES it works with pf.

Giovanni P. Tirloni

unread,
Jul 14, 2005, 4:56:28 PM7/14/05
to
Alex Povolotsky wrote:
>> When a packet comes from 1.2.3.4 to your external interface you can't
>> determine if it's destined to 192.168.0.1 or 192.168.0.2 if both
>> initiated a GRE tunnel to 1.2.3.4. That's because GRE doesn't have
>> ports like UDP or TCP to make (de)multiplexing possible, AFAIK.
>>
>> http://www.networksorcery.com/enp/protocol/gre.htm
>>
> Cool. I did not know that ICMP doesn't work through nat. It always
> worked for me. Moreover, as far as I remember, GRE worked with
> IPFW/NATD, and SOMETIMES it works with pf.

I don't know how PF keeps tracks of ICMP packets but there must be a
way for it to distinguish between a packet destined to 192.168.0.1 or 0.2.

We all know ICMP works behind NAT. You don't need to play like that here.

Looking at the GRE header I simply can't find a way to keep track of
it and my experiences with some xDSL/cable routers permit me to say
that I haven't found anyone that would let me establish more than one
PPTP connection behind NAT.

But then I'm no networking/pf/kernel guru to keep talking about this.

--
Giovanni P. Tirloni / g...@tirloni.org / PGP: 0xD0315C26

Stephen J. Bevan

unread,
Jul 15, 2005, 2:02:30 AM7/15/05
to
Giovanni P. Tirloni writes:
> I don't know how PF keeps tracks of ICMP packets but there must be a
> way for it to distinguish between a packet destined to 192.168.0.1 or 0.2.

An ICMP ECHO REQUEST message has a 16-bit id field which can be
altered by NAT to identify the originating machine.

There isn't really an equivalent when using a minimal GRE header. If
GRE checksums are turned on then the 16-bit Reserved1 field could be
abused for NAT purposes.

Sten Daniel Sørsdal

unread,
Jul 15, 2005, 5:30:52 AM7/15/05
to
Stephen J. Bevan wrote:
> Giovanni P. Tirloni writes:
> > I don't know how PF keeps tracks of ICMP packets but there must be a
> > way for it to distinguish between a packet destined to 192.168.0.1 or 0.2.
>
> An ICMP ECHO REQUEST message has a 16-bit id field which can be
> altered by NAT to identify the originating machine.
>
> There isn't really an equivalent when using a minimal GRE header. If
> GRE checksums are turned on then the 16-bit Reserved1 field could be
> abused for NAT purposes.

Not for GRE but for PPTP (which uses GRE but with a slight addition).
CALL ID, a unique number assigned by the PPTP server per session.
AFAIK. There are some firewalls out there that uses this ID.

--
Sten Daniel Sørsdal

Reply all
Reply to author
Forward
0 new messages