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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
