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>