Date: Tue, 27 Jul 2010 18:51:21 -0700 From: Justin <justin@sk1llz.net> To: Daniel Hartmeier <daniel@benzedrine.cx>, freebsd-pf@freebsd.org Subject: Re: pf synproxy Message-ID: <4C4F8D19.2020609@sk1llz.net> In-Reply-To: <20100727074850.GB1114@insomnia.benzedrine.cx> References: <4C4D7EED.4060704@sk1llz.net> <20100727074850.GB1114@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C4F8D19.2020609>