GRE and PF problem
Alex Povolotsky
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
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
>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
Alex Povolotsky
> 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
>> 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
> 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
> 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