pf synproxy

[Daniel Hartmeier]

On Tue, Jul 27, 2010 at 07:24:56PM -0700, Justin wrote:

>   - tcpdumps showing the initial connect attempt (logs below were 
> furhter along the process);
> 
> external:
> 02:21:25.595977 IP (tos 0x0, ttl 118, id 10020, offset 0, flags [DF], 
> proto TCP
> (6), length 52)
>     REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [S], 
> cksum 0x537b (correct), se
> q 2569879850, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], 
> length 0
> 02:21:25.596000 IP (tos 0x10, ttl 64, id 27957, offset 0, flags [DF], 
> proto TCP
> (6), length 44)
>     CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53782: Flags [S.], 
> cksum 0x7920 (correct), s
> eq 3819585455, ack 2569879851, win 0, options [mss 1460], length 0
> 02:21:25.605825 IP (tos 0x0, ttl 118, id 10021, offset 0, flags [DF], 
> proto TCP
> (6), length 40)
>     REMOTE_VIEWING_HOST.53782 > CLIENT_DESTINATION_IP.80: Flags [.], 
> cksum 0x95ec (correct), ac
> k 3819585456, win 64240, length 0
> 02:21:25.615953 IP (tos 0x0, ttl 118, id 10022, offset 0, flags [DF], 
> proto TCP
> (6), length 40)

The TCP handshake with the client makes sense.

The client's SYN offers wscale and sack, pf's SYN+ACK has IP tos 0x10
and neither wscale nor sack, and win 0.

> internal:
> 02:22:34.717332 IP (tos 0x0, ttl 118, id 22015, offset 0, flags [DF], 
> proto TCP
> (6), length 52)
>     REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [S], 
> cksum 0x84ee (correct), se
> q 1816476827, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], 
> length 0

This doesn't seem to be captured on the internal interface, at least
it is not the server handshake replayed by pf's synproxy.
Note the (random) client source port 53786 doesn't match 53782 of the
external capture above.

Instead, it looks like ANOTHER connection captured on the external
interface. The SYN has IP tos 0x0 and offers wscale and sack, so
this CANNOT be a packet generated by pf's synproxy...

What we want to see is the two TCP handshakes related to the same
client connection, once on the interface towards the client, once
on the interface towards the server. The client source port is the
same.

Ideally, tcpdump on both interface, writing to two files with 
tcpdump -w. Reproduce the issue. Find out what client source port
was used for that connection. Then tcpdump -r and extract all packets
of that port (src or dst) in both files...

And the pfctl -vvss output should contain the state with that port
as well.

There is precisely one external and one internal interface, and
pf is the only connection between these two networks, right?
If the client's SYN can somehow reach the server bypassing pf,
the synproxy will not work, there'd be two handshakes to the server
using different sequence numbers, the server would accept the first,
ignore the other, confusion would ensue ;)

Daniel