pf synproxy
Justin
justin at sk1llz.net
Wed Jul 28 02:25:00 UTC 2010
- 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)
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
02:22:34.717354 IP (tos 0x10, ttl 64, id 39898, offset 0, flags [DF],
proto TCP
(6), length 44)
CLIENT_DESTINATION_IP.80 > REMOTE_VIEWING_HOST.53786: Flags [S.],
cksum 0x1d5d (correct), s
eq 76721150, ack 1816476828, win 0, options [mss 1460], length 0
02:22:34.728880 IP (tos 0x0, ttl 118, id 22016, offset 0, flags [DF],
proto TCP
(6), length 40)
REMOTE_VIEWING_HOST.53786 > CLIENT_DESTINATION_IP.80: Flags [.],
cksum 0x3a29 (correct), ac
k 76721151, win 64240, length 0
02:22:34.742691 IP (tos 0x0, ttl 118, id 22017, offset 0, flags [DF],
proto TCP
(6), length 40)
On 7/27/2010 6:51 PM, Justin wrote:
> Hello Daniel,
>
> Didn't get any sort of information from pfctl -x misc. Here's the
> output from the commands you suggested;
>
> (3 SSH connections to run/log the tcpdump and pfctl outputs, 1
> attempted proxy)
>
> Pre HTTP end host attempt;
>
> # pfctl -vvsi
> No ALTQ support in kernel
> ALTQ related functions disabled
> Status: Enabled for 0 days 00:01:21 Debug: Urgent
>
> Hostid: 0x144de36b
> Checksum: 0xda84c38c7e2412bb81511fe0620a1012
>
> State Table Total Rate
> current entries 9
> searches 407 5.0/s
> inserts 22 0.3/s
> removals 13 0.2/s
> Source Tracking Table
> current entries 0
> searches 0 0.0/s
> inserts 0 0.0/s
> removals 0 0.0/s
> Counters
> match 26 0.3/s
> bad-offset 0 0.0/s
> fragment 0 0.0/s
> short 0 0.0/s
> normalize 0 0.0/s
> memory 0 0.0/s
> bad-timestamp 0 0.0/s
> congestion 0 0.0/s
> ip-option 0 0.0/s
> proto-cksum 0 0.0/s
> state-mismatch 0 0.0/s
> state-insert 0 0.0/s
> state-limit 0 0.0/s
> src-limit 0 0.0/s
> synproxy 14 0.2/s
> Limit Counters
> max states per rule 0 0.0/s
> max-src-states 0 0.0/s
> max-src-nodes 0 0.0/s
> max-src-conn 0 0.0/s
> max-src-conn-rate 0 0.0/s
> overload table insertion 0 0.0/s
> overload flush states 0 0.0/s
>
>
> after attempt and failure;
>
> # pfctl -vvsi
> No ALTQ support in kernel
> ALTQ related functions disabled
> Status: Enabled for 0 days 00:02:53 Debug: Urgent
>
> Hostid: 0x144de36b
> Checksum: 0xda84c38c7e2412bb81511fe0620a1012
>
> State Table Total Rate
> current entries 5
> searches 9552 55.2/s
> inserts 25 0.1/s
> removals 20 0.1/s
> Source Tracking Table
> current entries 0
> searches 0 0.0/s
> inserts 0 0.0/s
> removals 0 0.0/s
> Counters
> match 35 0.2/s
> bad-offset 0 0.0/s
> fragment 0 0.0/s
> short 0 0.0/s
> normalize 0 0.0/s
> memory 0 0.0/s
> bad-timestamp 0 0.0/s
> congestion 0 0.0/s
> ip-option 0 0.0/s
> proto-cksum 0 0.0/s
> state-mismatch 0 0.0/s
> state-insert 0 0.0/s
> state-limit 0 0.0/s
> src-limit 0 0.0/s
> synproxy 3274 18.9/s
> Limit Counters
> max states per rule 0 0.0/s
> max-src-states 0 0.0/s
> max-src-nodes 0 0.0/s
> max-src-conn 0 0.0/s
> max-src-conn-rate 0 0.0/s
> overload table insertion 0 0.0/s
> overload flush states 0 0.0/s
>
>
>
> # pfctl -vvss
> No ALTQ support in kernel
> ALTQ related functions disabled
> all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53065
> ESTABLISHED:ESTABLISHED
> [51278071 + 64060](+3232864399) [4177391361 + 65535](+803461391)
> age 00:02:49, expires in 04:59:45, 515:920 pkts, 28140:866768
> bytes, rule 3
> id: 4c4f86b600000031 creatorid: 144de36b
> all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53067
> ESTABLISHED:ESTABLISHED
> [3663860670 + 63784](+2459193596) [1446109858 + 65535](+1445587765)
> age 00:02:19, expires in 04:59:45, 490:862 pkts, 27452:809608
> bytes, rule 3
> id: 4c4f86b60000003b creatorid: 144de36b
> all tcp FIREWALL_EXTERNAL_IP:22 <- REMOTE_VIEWING_HOST:53070
> ESTABLISHED:ESTABLISHED
> [1850293048 + 63336](+3364896299) [442076181 + 65535](+2933418221)
> age 00:02:00, expires in 05:00:00, 84:108 pkts, 7728:17192 bytes,
> rule 3
> id: 4c4f86b600000042 creatorid: 144de36b
> all tcp CLIENT_DESTINATION_IP:80 <- REMOTE_VIEWING_HOST:53075
> PROXY:DST
> [0 + 3477913824] [3572604858 + 3688639377]
> age 00:00:26, expires in 00:00:04, 0:0 pkts, 0:0 bytes, rule 3
> id: 4c4f86b600000048 creatorid: 144de36b
>
>
> tcpdump -nvSi [interface] tcp port 80
>
> external interface:
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.],
> cksum 0xa59b (correct), ack 2966276940, win 64240, length 0
> 01:39:14.466318 IP (tos 0x0, ttl 118, id 27612, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.],
> cksum 0xa59b (correct), ack 2966276940, win 64240, length 0
> 01:39:14.467753 IP (tos 0x0, ttl 118, id 27613, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.],
> cksum 0xa59b (correct), ack 2966276940, win 64240, length 0
> 01:39:14.468718 IP (tos 0x0, ttl 118, id 27614, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.],
> cksum 0xa59b (correct), ack 2966276940, win 64240, length 0
> 01:39:14.469965 IP (tos 0x0, ttl 118, id 27615, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [.],
> cksum 0xa59b (correct), ack 2966276940, win 64240, length 0
> 01:39:14.470957 IP (tos 0x0, ttl 118, id 27616, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.],
> cksum 0xa088 (correct), seq 3572604859, ack 2966276940, win 0, length 0
>
> internal interface:
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S],
> cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460],
> length 0
> 01:39:14.467760 IP (tos 0x10, ttl 64, id 8944, offset 0, flags [DF],
> proto TCP (6), length 44)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S],
> cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460],
> length 0
> 01:39:14.468725 IP (tos 0x10, ttl 64, id 8945, offset 0, flags [DF],
> proto TCP (6), length 44)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S],
> cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460],
> length 0
> 01:39:14.469969 IP (tos 0x10, ttl 64, id 8946, offset 0, flags [DF],
> proto TCP (6), length 44)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S],
> cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460],
> length 0
> 01:39:14.470964 IP (tos 0x10, ttl 64, id 8947, offset 0, flags [DF],
> proto TCP (6), length 44)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [S],
> cksum 0xe978 (correct), seq 3477913824, win 0, options [mss 1460],
> length 0
> 01:39:34.524975 IP (tos 0x10, ttl 64, id 9091, offset 0, flags [DF],
> proto TCP (6), length 40)
> REMOTE_VIEWING_HOST.53075 > CLIENT_DESTINATION_IP.80: Flags [R.],
> cksum 0xa089 (correct), seq 2966276939, ack 3572604859, win 0, length 0
>
>
>
> On 7/27/2010 12:48 AM, Daniel Hartmeier wrote:
>> On Mon, Jul 26, 2010 at 05:26:21AM -0700, Justin wrote:
>>
>>> When using synproxy state - the connection never completes. If we
>>> change
>>> synproxy to keep, everything works fine. Alternately, if the service in
>>> question is running locally on the actual firewall itself, I'll see
>>> state entries show up in pfctl -s doing a proxy and then passing the
>>> connection on to its self - so why doesn't it work in the same manner
>>> when passing on to a host behind the machine? I've tried all sorts of
>>> variations and skipping processing on internal interface, but I just
>>> can't seem to get it to work. All my searching has turned up nothing.
>>> I've also tried state-policy if-bound and there appears to be no
>>> change.
>>> Is this a bug? Have I missed something totally obvious?
>> Concurrently run
>>
>> # tcpdump -nvSi em0 tcp port 80
>>
>> and
>>
>> # tcpdump -nvSi em1 tcp port 80
>>
>> and reproduce one connection failure. What do you see?
>> Does the TCP handshake (SYN, SYN+ACK, ACK) complete between
>> client and pf? And the one between pf and the server?
>>
>> Right after the failure, does pfctl -vvss show a state entry
>> for the failed connection? What does it look like?
>>
>> Run pfctl -vvsi before and after the failure. Which counters
>> are increasing?
>>
>> Enable verbose logging (pfctl -x misc), does /var/log/messages
>> show any message possibly related to the failure?
>>
>> Kind regards,
>> Daniel
>
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
More information about the freebsd-pf
mailing list