Hi,
I am currently running OpenBSD 4.9 as a router/firewall for my work and so far I have nearly a fully working config but there is something I cannot manage to do

Here is my configuration:
The server has 1 physical interface, I added a gif interface to connect it to a remote machine which is used to route most of the traffic, on this gif interface I have incoming requests I want to pass through squid.

Here is my pf.conf fie:

Code:

phys_if = "re0"
c1_tunnel = "gif1001"
c1_tunnel_dst = "xx.xx.xx.xx"
c1_tunnel_src = "xx.xx.xx.xx"
c1_escape = "xx.xx.xx.xx"
set skip on lo0
set block-policy drop
# block any packet with no match
block log all
# allow our own services to work
pass in on $phys_if proto tcp from any to $phys_if port { ssh } synproxy state
pass in on $phys_if inet proto icmp from any to $phys_if
pass out on $phys_if label "system"
# 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"
# tag incoming packets from the tunnel and from
# the outside to the public ip address
match in log(matches) on $c1_tunnel tag "c1"
match in log(matches) on $phys_if from any to $c1_escape tag "c1"
# Allow incoming packet to port 80 and redirect them to squid
pass in log(matches, all) on $c1_tunnel proto tcp to port 80 \
rdr-to 127.0.0.1 port 1001 \
reply-to ($c1_tunnel 10.0.0.5) \
tagged "c1" label "c1_proxied_traffic"

The result is that I cannot establish a tcp connection to port 80 for a machine behing the gif tunnel, here is what tcpdump says on this machine ( tcpdump -s 0 -vlni <interface> port 80 ):

There is only one packet from the web server (which is in fact my server since the request was redirected to squid ) which finds its way to the client and after that all the checksums are wrong, I suppose the packets are dropped by the kernel due to the bad checksum since they never reach my client application (which is curl).
I tried to figure out why the checksum could be wrong but I am now out of ideas...

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:

As I suspected a state was created for the tunnel without me requiring it which is fine by me, the others are my attempts to connect from the client network.
The last one is a connection that was open when I typed the command showing that as far as pf is concerned everything is fine

When i disconnect the client the right part transition to "CLOSING:FIN_WAIT_2" and some seconds later to "FIN_WAIT_2:FIN_WAIT_2" (I suppose the checksum problem prevent both parts to properly close the connection)