View Single Post
  #1   (View Single Post)  
Old 10th August 2011
schmurfy schmurfy is offline
Port Guard
 
Join Date: Aug 2011
Posts: 12
Default PF problem with reply-to

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 ):

Code:
IP (tos 0x0, ttl  62, id 8175, offset 0, flags [DF], length: 60) <client_address>.21746 > <web_address>.80: S [tcp sum ok] 3993732249:3993732249(0) win 65535 <mss 1380,nop,wscale 3,sackOK,timestamp 442132554 0>
IP (tos 0x0, ttl  64, id 59219, offset 0, flags [DF], length: 64) <web_address>.80 > <client_address>.21746: S [tcp sum ok] 3332347257:3332347257(0) ack 3993732250 win 16384 <mss 1440,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2569862135 442132554>

IP (tos 0x0, ttl  62, id 8176, offset 0, flags [DF], length: 52) <client_address>.21746 > <web_address>.80: . [tcp sum ok] ack 1 win 8208 <nop,nop,timestamp 442132595 2569862135>
IP (tos 0x0, ttl  62, id 8189, offset 0, flags [DF], length: 54) <client_address>.21746 > <web_address>.80: P [tcp sum ok] 1:3(2) ack 1 win 8208 <nop,nop,timestamp 442134444 2569862135>
IP (tos 0x0, ttl  64, id 65354, offset 0, flags [DF], length: 58) <web_address>.80 > <client_address>.21746: P [bad tcp cksum a676 (->a9cf)!] 1:7(6) ack 3 win 2052 <nop,nop,timestamp 2569862139 442134444>

IP (tos 0x0, ttl  62, id 8190, offset 0, flags [DF], length: 54) <client_address>.21746 > <web_address>.80: P [tcp sum ok] 1:3(2) ack 1 win 8208 <nop,nop,timestamp 442134770 2569862135>
IP (tos 0x0, ttl  64, id 23274, offset 0, flags [DF], length: 52) <web_address>.80 > <client_address>.21746: . [bad tcp cksum b6c8 (->ba21)!] ack 3 win 2052 <nop,nop,timestamp 2569862139 442134770>

IP (tos 0x0, ttl  62, id 8194, offset 0, flags [DF], length: 54) <client_address>.21746 > <web_address>.80: P [tcp sum ok] 1:3(2) ack 1 win 8208 <nop,nop,timestamp 442135222 2569862135>
IP (tos 0x0, ttl  64, id 4613, offset 0, flags [DF], length: 52) <web_address>.80 > <client_address>.21746: . [bad tcp cksum b503 (->b85c)!] ack 3 win 2052 <nop,nop,timestamp 2569862140 442135222>
IP (tos 0x0, ttl  62, id 8199, offset 0, flags [DF], length: 54) <client_address>.21746 > <web_address>.80: P [tcp sum ok] 1:3(2) ack 1 win 8208 <nop,nop,timestamp 442135926 2569862135>
IP (tos 0x0, ttl  64, id 41419, offset 0, flags [DF], length: 52) <web_address>.80 > <client_address>.21746: . [bad tcp cksum b241 (->b59a)!] ack 3 win 2052 <nop,nop,timestamp 2569862142 442135926>

IP (tos 0x0, ttl  62, id 8205, offset 0, flags [DF], length: 52) <client_address>.21746 > <web_address>.80: F [tcp sum ok] 3:3(0) ack 1 win 8208 <nop,nop,timestamp 442136662 2569862135>
IP (tos 0x0, ttl  62, id 8209, offset 0, flags [DF], length: 54) <client_address>.21746 > <web_address>.80: FP [tcp sum ok] 1:3(2) ack 1 win 8208 <nop,nop,timestamp 442137134 2569862135>
IP (tos 0x0, ttl  64, id 43519, offset 0, flags [DF], length: 58) <web_address>.80 > <client_address>.21746: P [bad tcp cksum 9bee (->9f47)!] 1:7(6) ack 3 win 2052 <nop,nop,timestamp 2569862145 442137134>

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...

I hope someone can help me on this.

Last edited by schmurfy; 15th August 2011 at 11:12 AM.
Reply With Quote