View Single Post
  #5   (View Single Post)  
Old 16th August 2011
schmurfy schmurfy is offline
Port Guard
 
Join Date: Aug 2011
Posts: 12
Default

After some testing it still does not work but I gathered more evidences.

I first changed these two lines as you suggested but it changed nothing:
Code:
    # allow ipip traffic (gif interface)
    pass in on $phys_if from $c1_tunnel_dst to $c1_tunnel_src label "c1_tunnel"
    pass out on $phys_if from $c1_tunnel_src to $c1_tunnel_dst label "c1_tunnel"
I then checked "pfctl -vs rules" and noticed that these rules matched no packets so I tried removing them and everything still works the same without them Oo
That's weird for me but it looks like packets from a gif tunnels are automatically accepted by default on the physical interface, if it is not that then I am even more lost

While trying stupid things I tried adding a route to the client network (where the machine issuing the http request is) telling the server which interface to use and... it worked !!

I want to do all the routing with pf (in part because clients can use any private network they want so they overlap with another client) so this solution is not usable but it still worked which is a big "what the fuck ??" for me

So my problem is brought down to two simple facts for now:
- when I tell pf where to route the reply to it takes the right path but the checksums are wrong for all exiting packets
- when I add a route in the default routing table telling the system where to route the packets to the same client it works...

What is really disturbing is that the packet still reach the other end of the tunnel in both cases but the checksums are either good or bad dependeing on whether a route is present or not.


It brings some questions:
- Why the routing is used at all if the pf rules is set to do the routing ? (it does not work if I add a route pointing to the wrong exit)
- Why adding a route "helps" pf somehow to get the right checksum

God I hate these kind of weird problems
I still hope I did something wrong and smeone can bring me some kind of enlightenment but it looks awfully like a bug with reply-to and gif interfaces.

PS: I also tried to change the proxy rule to more closely match yours but no improvements.

Edit: Silly me, I forgot the fact that even if I removed the rule for the ipip tunnel the state was still there, I removed the state and replaced the two rules with:
Code:
pass in log(matches, all) quick on $phys_if inet proto 4 from $env_preprod_1_tunnel_dst to $env_preprod_1_tunnel_src label "env_preprod_1_tunnel"
# pass out log(matches, all) quick on $phys_if inet proto 4 from $env_preprod_1_tunnel_src to $env_preprod_1_tunnel_dst label "env_preprod_1_tunnel"
but the behavior is still the same as described in this post

Last edited by schmurfy; 16th August 2011 at 12:45 PM.
Reply With Quote