On Tue, 29 Aug 2006, Raja Subramanian wrote: > > A (more complicated) alternative would be to teach pf to pull out > > either the GRE "key" (rfc2980) and/or eGRE "call id" (rfc2637) fields > > and stuff them into the space used by the port numbers. IIRC both are > > uint32, so they should fit. This will give the added benefit of > > making pf able to properly NAT multiple GRE sessions through the same > > gateway. > > Now, I'm facing an unusual problem that did not surface itself > in my testing until recently. I wonder if it's in anyway related > to what you mention above. > > pf is not redirecting gre packets headed to new destinations when > a state entry from a previous rdr already exists. Here is a bit > more detail: > > 1. client.c sends gre packet to a.b.c.d. > 2. pf redirects it to server.c 127.0.0.1. > 3. a state entry is created and server.c calls > ioctl(DIOCNATLOOK) successfully. > 4. client.c sends gre packet to a different host (e.f.g.h), > but pf is *not* redirecting this to server.c until the > previous state created above expires. > 5. Calling "pfctl -F state" gets a new IP addr through, but > locks rdr to the new IP and I'm stuck with the same problem.
The problem here is that pf cannot handle multiple GRE sessions from/to the same host simultaneously. Teaching pf how to intepret the GRE key extension / eGRE call-id as I described in the previous email will resolve this. -d
