From bugzilla-noreply at freebsd.org  Mon Sep  1 13:00:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 01 Sep 2014 13:00:57 +0000
Subject: [Bug 177808] [pf] [patch] route-to rule forwarding traffic inspite
 of state limit
In-Reply-To: <bug-177808-17777@https.bugs.freebsd.org/bugzilla/>
References: <bug-177808-17777@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-177808-17777-jj0ip7IMJq@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=177808

--- Comment #3 from commit-hook at freebsd.org ---
A commit references this bug:

Author: glebius
Date: Mon Sep  1 13:00:46 UTC 2014
New revision: 270928
URL: http://svnweb.freebsd.org/changeset/base/270928

Log:
  Explicitly free packet on PF_DROP, otherwise a "quick" rule with
  "route-to" may still forward it.

  PR:        177808
  Submitted by:    Kajetan Staszkiewicz <kajetan.staszkiewicz innogames.de>
  Sponsored by:    InnoGames GmbH

Changes:
  head/sys/netpfil/pf/pf.c

-- 
You are receiving this mail because:
You are the assignee for the bug.

From bugzilla-noreply at freebsd.org  Mon Sep  1 13:01:24 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 01 Sep 2014 13:01:24 +0000
Subject: [Bug 177808] [pf] [patch] route-to rule forwarding traffic inspite
 of state limit
In-Reply-To: <bug-177808-17777@https.bugs.freebsd.org/bugzilla/>
References: <bug-177808-17777@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-177808-17777-X4CsGEN5uY@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=177808

Gleb Smirnoff <glebius at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|In Discussion               |Needs MFC
                 CC|                            |glebius at FreeBSD.org
           Assignee|freebsd-pf at FreeBSD.org      |glebius at FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

From vincejaca at gmail.com  Sat Sep  6 21:27:45 2014
From: vincejaca at gmail.com (Vince)
Date: Sat, 06 Sep 2014 23:27:33 +0200
Subject: Information about costs
Message-ID: <qr3arjnc9jj7b67dry7jnk70.1410038853264@email.android.com>

hiy I would like to know if the monthly installment will increase? And if so why and how please send me a complete broucher of price increase of all the car advertised if the are any.!

From bugzilla-noreply at freebsd.org  Mon Sep  8 15:40:41 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Mon, 08 Sep 2014 15:40:41 +0000
Subject: [Bug 163208] [pf] PF state key linking mismatch
In-Reply-To: <bug-163208-17777@https.bugs.freebsd.org/bugzilla/>
References: <bug-163208-17777@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-163208-17777-N5scsycjuK@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163208

Dan Langille <dvl at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dvl at FreeBSD.org
           Severity|Affects Only Me             |Affects Some People

--- Comment #17 from Dan Langille <dvl at FreeBSD.org> ---
This situation persists in FreeBSD 9.3-RELEASE

-- 
You are receiving this mail because:
You are the assignee for the bug.

From andrei693 at gmail.com  Sat Sep 13 19:52:42 2014
From: andrei693 at gmail.com (Andrei Brezan)
Date: Sat, 13 Sep 2014 21:52:38 +0200
Subject: pf firewall blocking packets with a pass rule in place
Message-ID: <5414A086.5020608@gmail.com>

Hi,

I have some odd behaviour on one network which has a pf gateway 
firewall. This is from a tcpdump on pflog on the firewall, 1.2.3.4 is my 
remote address, 5.6.7.8 is the pf firewall, 10.0.0.252 is an OpenVPN 
server (tap) behind the firewall, 10.0.0.250 is my mail server:

20:45:26.682551 rule 32..16777216/0(match): pass out on vlan333: 
1.2.3.4.61384 > 10.0.0.252.1194: UDP, length 14
20:46:36.230485 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.57412 > 10.0.0.250.80: Flags [S], seq 1335812154, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 687134035 ecr 0], length 0
20:46:36.244606 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.53156 > 10.0.0.250.443: Flags [S], seq 3626719163, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 3971340937 ecr 0], length 0
20:52:28.494174 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.51684 > 10.0.0.250.993: Flags [S], seq 3306743615, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 2707206732 ecr 0], length 0
20:52:30.650788 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.59297 > 10.0.0.250.993: Flags [S], seq 4090099168, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 2986073365 ecr 0], length 0
20:57:27.585665 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.50367 > 10.0.0.250.80: Flags [S], seq 920232625, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 809211507 ecr 0], length 0
20:57:27.599151 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.54013 > 10.0.0.250.443: Flags [S], seq 281501721, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 1810969707 ecr 0], length 0
21:01:13.826452 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.64792 > 10.0.0.250.25: Flags [S], seq 1871587187, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 1261752165 ecr 0], length 0
21:03:16.371844 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [P.], seq 3402837478:3402837515, 
ack 2361346111, win 1026, options [nop,nop,TS val 5284083 ecr 52159031], 
length 37
21:03:16.372008 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [F.], seq 37, ack 1, win 1026, 
options [nop,nop,TS val 5284083 ecr 52159031], length 0
21:03:16.373308 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.54156 > 10.0.0.250.993: Flags [S], seq 3275327108, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 2062181022 ecr 0], length 0
21:03:16.615875 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5284327 ecr 52159031], length 37
21:03:16.891824 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5284603 ecr 52159031], length 37
21:03:17.231604 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5284943 ecr 52159031], length 37
21:03:17.685793 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5285397 ecr 52159031], length 37
21:03:18.408137 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5286119 ecr 52159031], length 37
21:03:19.583723 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5287295 ecr 52159031], length 37
21:03:21.713816 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5289425 ecr 52159031], length 37
21:03:25.766916 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5293478 ecr 52159031], length 37
21:03:33.679722 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5301391 ecr 52159031], length 37
21:03:49.240190 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5316951 ecr 52159031], length 37
21:04:04.821702 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5332533 ecr 52159031], length 37
21:04:20.382912 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 1026, 
options [nop,nop,TS val 5348094 ecr 52159031], length 37
21:04:35.947297 rule 0..16777216/0(match): block out on vlan333: 
1.2.3.4.54922 > 10.0.0.250.993: Flags [R.], seq 38, ack 1, win 1026, 
options [nop,nop,TS val 5363658 ecr 52159031], length 0
21:38:41.708989 rule 32..16777216/0(match): pass out on igb0: 
5.6.7.8.54206 > 1.2.3.4.61384: UDP, length 101
21:40:11.470576 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.58407 > 10.0.0.250.993: Flags [S], seq 3179386733, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 3544878749 ecr 0], length 0
21:41:10.356274 rule 0..16777216/0(match): block out on igb0: 
5.6.7.8.63184 > 1.2.3.4.58407: Flags [R.], seq 542623300, ack 
3179387863, win 0, length 0
21:42:42.139787 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.58246 > 10.0.0.250.993: Flags [S], seq 2033854095, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 2222918259 ecr 0], length 0
21:42:58.173371 rule 0..16777216/0(match): block out on igb0: 
5.6.7.8.55938 > 1.2.3.4.58246: Flags [P.], seq 1671786524:1671786577, 
ack 2033855225, win 252, options [nop,nop,TS val 52409345 ecr 7663492], 
length 53
21:43:01.035543 rule 0..16777216/0(match): block out on igb0: 
5.6.7.8.62485 > 1.2.3.4.51684: Flags [R.], seq 1560010735, ack 
3306749941, win 0, length 0
21:43:43.457948 rule 32..16777216/0(match): pass out on vlan333: 
1.2.3.4.61028 > 192.168.0.252.1194: UDP, length 14
21:43:51.279156 rule 32..16777216/0(match): pass out on igb0: 
5.6.7.8.64507 > 1.2.3.4.61028: UDP, length 101
21:44:42.074698 rule 35..16777216/0(match): pass out on vlan333: 
1.2.3.4.57041 > 10.0.0.250.993: Flags [S], seq 3652350806, win 65535, 
options [mss 1440,nop,wscale 6,sackOK,TS val 2369373378 ecr 0], length 0
21:45:11.441957 rule 0..16777216/0(match): block in on vlan333: 
10.0.0.250.993 > 1.2.3.4.54156: Flags [.], seq 2259431444:2259431445, 
ack 3275340784, win 255, length 1

I really don't understand why are these packages blocked. I'm 
experiencing intermittent and random connection loss, what's really odd, 
happens mostly during the evening or night, plus I don't see the pass in 
pflog for the established state, after this round of blocked packets I 
am still able to connect to the IMAPs server:

% sudo pfctl -vvs state | grep -A 3 -E "1.2.3.4.*993"
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 1.2.3.4:59297 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
    [4090185320 + 65054] wscale 6  [521715590 + 65664] wscale 8
    age 00:43:22, expires in 23:58:49, 1341:1208 pkts, 155891:390868 
bytes, rule 35
    id: 0300000053fe8341 creatorid: d8aa2c51
--
all tcp 1.2.3.4:54106 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
    [2304345867 + 65536] wscale 6  [3058330740 + 65664] wscale 8
    age 01:39:27, expires in 23:58:45, 197:161 pkts, 22303:35201 bytes, 
rule 35
    id: 0000000053fe91c7 creatorid: d8aa2c51
--
all tcp 1.2.3.4:51684 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
    [3306749755 + 64806] wscale 6  [1560010681 + 65664] wscale 8
    age 00:43:24, expires in 23:37:21, 163:285 pkts, 14623:190269 bytes, 
rule 35
    id: 0000000053fe9440 creatorid: d8aa2c51
--
all tcp 1.2.3.4:54156 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
    [3275340128 + 64626] wscale 6  [2259430819 + 65664] wscale 8
    age 00:32:36, expires in 24:00:00, 374:490 pkts, 32475:273389 bytes, 
rule 35
    id: 0000000053fe944f creatorid: d8aa2c51

% sudo pfctl -vvs state | grep -A 3 -E "993.*1.2.3.4"
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:59297 
ESTABLISHED:ESTABLISHED
    [521721120 + 65664] wscale 8  [4090191500 + 64828] wscale 6
    age 00:44:12, expires in 23:59:55, 1429:1274 pkts, 166647:399830 bytes
    id: 0300000053fe8340 creatorid: d8aa2c51
--
all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:54106 
ESTABLISHED:ESTABLISHED
    [3058330915 + 1026]  [2304346089 + 255]
    age 00:51:21, expires in 23:59:51, 71:53 pkts, 7588:5901 bytes
    id: 0000000053fe9427 creatorid: d8aa2c51
all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:51684 
ESTABLISHED:ESTABLISHED
    [1560010681 + 65664] wscale 8  [3306749755 + 64806] wscale 6
    age 00:44:14, expires in 23:36:31, 163:285 pkts, 14623:190269 bytes
    id: 0000000053fe943f creatorid: d8aa2c51
--
all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:54156 
ESTABLISHED:ESTABLISHED
    [2259430819 + 65664] wscale 8  [3275340128 + 64626] wscale 6
    age 00:33:26, expires in 23:59:10, 374:490 pkts, 32475:273389 bytes
    id: 0000000053fe944e creatorid: d8aa2c51

Anyone has any idea what might be amiss here? What can I look into? I 
hope someone with more pf and TCP knowledge than me can shed some light.

Thank you,

-- 
Andrei


From andrei693 at gmail.com  Sat Sep 13 20:02:43 2014
From: andrei693 at gmail.com (Andrei Brezan)
Date: Sat, 13 Sep 2014 22:02:38 +0200
Subject: pf firewall blocking packets with a pass rule in place
In-Reply-To: <5414A086.5020608@gmail.com>
References: <5414A086.5020608@gmail.com>
Message-ID: <5414A2DE.9020307@gmail.com>

On 09/13/14 21:52, Andrei Brezan wrote:
> Hi,
>
Forgot to mention, this is on 10.0-RELEASE-p7.
> I have some odd behaviour on one network which has a pf gateway 
> firewall. This is from a tcpdump on pflog on the firewall, 1.2.3.4 is 
> my remote address, 5.6.7.8 is the pf firewall, 10.0.0.252 is an 
> OpenVPN server (tap) behind the firewall, 10.0.0.250 is my mail server:
>
> 20:45:26.682551 rule 32..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.61384 > 10.0.0.252.1194: UDP, length 14
> 20:46:36.230485 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.57412 > 10.0.0.250.80: Flags [S], seq 1335812154, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 687134035 ecr 0], length 0
> 20:46:36.244606 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.53156 > 10.0.0.250.443: Flags [S], seq 3626719163, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 3971340937 ecr 0], length 0
> 20:52:28.494174 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.51684 > 10.0.0.250.993: Flags [S], seq 3306743615, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 2707206732 ecr 0], length 0
> 20:52:30.650788 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.59297 > 10.0.0.250.993: Flags [S], seq 4090099168, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 2986073365 ecr 0], length 0
> 20:57:27.585665 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.50367 > 10.0.0.250.80: Flags [S], seq 920232625, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 809211507 ecr 0], length 0
> 20:57:27.599151 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.54013 > 10.0.0.250.443: Flags [S], seq 281501721, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 1810969707 ecr 0], length 0
> 21:01:13.826452 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.64792 > 10.0.0.250.25: Flags [S], seq 1871587187, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 1261752165 ecr 0], length 0
> 21:03:16.371844 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [P.], seq 3402837478:3402837515, 
> ack 2361346111, win 1026, options [nop,nop,TS val 5284083 ecr 
> 52159031], length 37
> 21:03:16.372008 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [F.], seq 37, ack 1, win 1026, 
> options [nop,nop,TS val 5284083 ecr 52159031], length 0
> 21:03:16.373308 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.54156 > 10.0.0.250.993: Flags [S], seq 3275327108, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 2062181022 ecr 0], length 0
> 21:03:16.615875 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5284327 ecr 52159031], length 37
> 21:03:16.891824 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5284603 ecr 52159031], length 37
> 21:03:17.231604 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5284943 ecr 52159031], length 37
> 21:03:17.685793 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5285397 ecr 52159031], length 37
> 21:03:18.408137 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5286119 ecr 52159031], length 37
> 21:03:19.583723 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5287295 ecr 52159031], length 37
> 21:03:21.713816 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5289425 ecr 52159031], length 37
> 21:03:25.766916 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5293478 ecr 52159031], length 37
> 21:03:33.679722 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5301391 ecr 52159031], length 37
> 21:03:49.240190 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5316951 ecr 52159031], length 37
> 21:04:04.821702 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5332533 ecr 52159031], length 37
> 21:04:20.382912 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [FP.], seq 0:37, ack 1, win 
> 1026, options [nop,nop,TS val 5348094 ecr 52159031], length 37
> 21:04:35.947297 rule 0..16777216/0(match): block out on vlan333: 
> 1.2.3.4.54922 > 10.0.0.250.993: Flags [R.], seq 38, ack 1, win 1026, 
> options [nop,nop,TS val 5363658 ecr 52159031], length 0
> 21:38:41.708989 rule 32..16777216/0(match): pass out on igb0: 
> 5.6.7.8.54206 > 1.2.3.4.61384: UDP, length 101
> 21:40:11.470576 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.58407 > 10.0.0.250.993: Flags [S], seq 3179386733, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 3544878749 ecr 0], length 0
> 21:41:10.356274 rule 0..16777216/0(match): block out on igb0: 
> 5.6.7.8.63184 > 1.2.3.4.58407: Flags [R.], seq 542623300, ack 
> 3179387863, win 0, length 0
> 21:42:42.139787 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.58246 > 10.0.0.250.993: Flags [S], seq 2033854095, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 2222918259 ecr 0], length 0
> 21:42:58.173371 rule 0..16777216/0(match): block out on igb0: 
> 5.6.7.8.55938 > 1.2.3.4.58246: Flags [P.], seq 1671786524:1671786577, 
> ack 2033855225, win 252, options [nop,nop,TS val 52409345 ecr 
> 7663492], length 53
> 21:43:01.035543 rule 0..16777216/0(match): block out on igb0: 
> 5.6.7.8.62485 > 1.2.3.4.51684: Flags [R.], seq 1560010735, ack 
> 3306749941, win 0, length 0
> 21:43:43.457948 rule 32..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.61028 > 192.168.0.252.1194: UDP, length 14
> 21:43:51.279156 rule 32..16777216/0(match): pass out on igb0: 
> 5.6.7.8.64507 > 1.2.3.4.61028: UDP, length 101
> 21:44:42.074698 rule 35..16777216/0(match): pass out on vlan333: 
> 1.2.3.4.57041 > 10.0.0.250.993: Flags [S], seq 3652350806, win 65535, 
> options [mss 1440,nop,wscale 6,sackOK,TS val 2369373378 ecr 0], length 0
> 21:45:11.441957 rule 0..16777216/0(match): block in on vlan333: 
> 10.0.0.250.993 > 1.2.3.4.54156: Flags [.], seq 2259431444:2259431445, 
> ack 3275340784, win 255, length 1
>
> I really don't understand why are these packages blocked. I'm 
> experiencing intermittent and random connection loss, what's really 
> odd, happens mostly during the evening or night, plus I don't see the 
> pass in pflog for the established state, after this round of blocked 
> packets I am still able to connect to the IMAPs server:
>
> % sudo pfctl -vvs state | grep -A 3 -E "1.2.3.4.*993"
> No ALTQ support in kernel
> ALTQ related functions disabled
> all tcp 1.2.3.4:59297 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
>    [4090185320 + 65054] wscale 6  [521715590 + 65664] wscale 8
>    age 00:43:22, expires in 23:58:49, 1341:1208 pkts, 155891:390868 
> bytes, rule 35
>    id: 0300000053fe8341 creatorid: d8aa2c51
> --
> all tcp 1.2.3.4:54106 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
>    [2304345867 + 65536] wscale 6  [3058330740 + 65664] wscale 8
>    age 01:39:27, expires in 23:58:45, 197:161 pkts, 22303:35201 bytes, 
> rule 35
>    id: 0000000053fe91c7 creatorid: d8aa2c51
> --
> all tcp 1.2.3.4:51684 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
>    [3306749755 + 64806] wscale 6  [1560010681 + 65664] wscale 8
>    age 00:43:24, expires in 23:37:21, 163:285 pkts, 14623:190269 
> bytes, rule 35
>    id: 0000000053fe9440 creatorid: d8aa2c51
> --
> all tcp 1.2.3.4:54156 -> 10.0.0.250:993 ESTABLISHED:ESTABLISHED
>    [3275340128 + 64626] wscale 6  [2259430819 + 65664] wscale 8
>    age 00:32:36, expires in 24:00:00, 374:490 pkts, 32475:273389 
> bytes, rule 35
>    id: 0000000053fe944f creatorid: d8aa2c51
>
> % sudo pfctl -vvs state | grep -A 3 -E "993.*1.2.3.4"
> No ALTQ support in kernel
> ALTQ related functions disabled
> all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:59297 
> ESTABLISHED:ESTABLISHED
>    [521721120 + 65664] wscale 8  [4090191500 + 64828] wscale 6
>    age 00:44:12, expires in 23:59:55, 1429:1274 pkts, 166647:399830 bytes
>    id: 0300000053fe8340 creatorid: d8aa2c51
> --
> all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:54106 
> ESTABLISHED:ESTABLISHED
>    [3058330915 + 1026]  [2304346089 + 255]
>    age 00:51:21, expires in 23:59:51, 71:53 pkts, 7588:5901 bytes
>    id: 0000000053fe9427 creatorid: d8aa2c51
> all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:51684 
> ESTABLISHED:ESTABLISHED
>    [1560010681 + 65664] wscale 8  [3306749755 + 64806] wscale 6
>    age 00:44:14, expires in 23:36:31, 163:285 pkts, 14623:190269 bytes
>    id: 0000000053fe943f creatorid: d8aa2c51
> --
> all tcp 10.0.0.250:993 (5.6.7.8:993) <- 1.2.3.4:54156 
> ESTABLISHED:ESTABLISHED
>    [2259430819 + 65664] wscale 8  [3275340128 + 64626] wscale 6
>    age 00:33:26, expires in 23:59:10, 374:490 pkts, 32475:273389 bytes
>    id: 0000000053fe944e creatorid: d8aa2c51
>
> Anyone has any idea what might be amiss here? What can I look into? I 
> hope someone with more pf and TCP knowledge than me can shed some light.
>
> Thank you,
> -- 
> Andrei

-- 
Andrei


From bugzilla-noreply at freebsd.org  Thu Sep 18 11:29:57 2014
From: bugzilla-noreply at freebsd.org (bugzilla-noreply at freebsd.org)
Date: Thu, 18 Sep 2014 11:29:57 +0000
Subject: [Bug 168190] [pf] panic when using pf and route-to (maybe: bad
 fragment handling?)
In-Reply-To: <bug-168190-17777@https.bugs.freebsd.org/bugzilla/>
References: <bug-168190-17777@https.bugs.freebsd.org/bugzilla/>
Message-ID: <bug-168190-17777-xitmgyRRYF@https.bugs.freebsd.org/bugzilla/>

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168190

Tomasz <wwt at op.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wwt at op.pl

--- Comment #24 from Tomasz <wwt at op.pl> ---
Hello 
I have the same or similar problem with Dell R210 II kern/193452

I add patch 
http://www.benzedrine.cx/fbsd-byteorder.diff
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=124691&action=diff

Index: sys/contrib/ipfilter/netinet/ip_fil_freebsd.c
===================================================================
RCS file: /home/ncvs/src/sys/contrib/ipfilter/netinet/ip_fil_freebsd.c,v
retrieving revision 1.20.4.1
diff -u -r1.20.4.1 ip_fil_freebsd.c
--- sys/contrib/ipfilter/netinet/ip_fil_freebsd.c       23 Sep 2011 00:51:37
-0000      1.20.4.1
+++ sys/contrib/ipfilter/netinet/ip_fil_freebsd.c       4 Jun 2012 10:19:04
-0000
@@ -182,8 +182,18 @@
 static int
 fr_check_wrapper(void *arg, struct mbuf **mp, struct ifnet *ifp, int dir)
 {
+       int r;
+
        struct ip *ip = mtod(*mp, struct ip *);
-       return fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp);
+       ASSERT_HOST_BYTE_ORDER(*mp);
+       r = fr_check(ip, ip->ip_hl << 2, ifp, (dir == PFIL_OUT), mp);
+       if (*mp != NULL && (*mp)->m_pkthdr.len >= sizeof(struct ip) &&
+           (*mp)->m_len < sizeof(struct ip)) {
+               printf("fr_check_wrapper: m_len %d fixed\n",
+                   (int)(*mp)->m_len);
+               *mp = m_pullup(*mp, sizeof(struct ip));
+       }
+       return r;
 }

 # ifdef USE_INET6



For now system work correctly for 3 days without panic and its lot off
log message
Sep 18 12:50:47 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 12:52:09 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 12:55:50 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:03:26 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:07:53 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:07:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:11:13 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:11:36 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:11:36 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:12:01 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:13:07 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:14:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:15:45 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:15:49 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:17:16 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:17:55 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:18:35 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:18:57 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:23 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:30 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:34 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:43 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:19:56 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:20:02 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:20:08 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:20:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:20:24 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:20:33 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed
Sep 18 13:25:27 <0.2> ns2 kernel: fr_check_wrapper: m_len 0 fixed

9.2-RELEASE-p10 FreeBSD 9.2-RELEASE-p10
Kernel is Generic with
options DEVICE_POLLING
options DUMMYNET
options IPFILTER_LOG
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE
options IPFIREWALL
options IPFILTER


network card is bce 
in sysctl I found something strange

dev.bce.0.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0)
dev.bce.1.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0)
dev.brgphy.0.%desc: BCM5709 10/100/1000baseT PHY
dev.brgphy.1.%desc: BCM5709 10/100/1000baseT PHY


Best Regards
Tomek

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

From curtis at ipv6.occnc.com  Fri Sep 19 00:26:38 2014
From: curtis at ipv6.occnc.com (Curtis Villamizar)
Date: Thu, 18 Sep 2014 20:26:33 -0400
Subject: is it possible (practical) to add af-to
Message-ID: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com>

Hi,

NAT46 and NAT64 require af-to or equivalent.

This may be naive on my part but it doesn't seem like it would be a
lot of trouble to add af-to to the existing pf.

That said, I am aware of the discussion of further diverging from the
openbsd pf as discussed in the thread in the archives at
http://lists.freebsd.org/pipermail/freebsd-pf/2014-July/007391.html

I'm willing to contribute code if there is a chance anyone would be
willing to take it as an interim until freebsd pf catches up to
openbsd pf.

Thoughts on this below.

Curtis



Currently the syntax of rdr and nat accept the following:

  nat-rule   = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
               [ "on" ifspec ] [ af ]
               [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
               [ "->" ( redirhost | "{" redirhost-list "}" )
               [ portspec ] [ pooltype ] [ "static-port" ] ]

  rdr-rule   = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
               [ "on" ifspec ] [ af ]
               [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
               [ "->" ( redirhost | "{" redirhost-list "}" )
               [ portspec ] [ pooltype ] ]

Both of these end in:

               [ "->" ( redirhost | "{" redirhost-list "}" )
               [ portspec ] [ pooltype ] ]

(with nat-rule having the optional [ "static-port" ]).

Changing the syntax is no big deal and that would be the easy part.

In sbin/pf/parse.y some change would be needed to the redirpool rule
where the two forms are (yacc actions omitted):

redirpool	:
		| ARROW redirspec
		| ARROW redirspec PORT portstar

to this (or to redirspec) we'd have to add an af_to which would be
similar to the af rule but with the keywork af-to:

af_to	; /* empty */   { $$ = 0; }
	| AF_TO INET	{ $$ = AF_INET; }
	| AF_TO INET6	{ $$ = AF_INET6; }

If this is added to the redirpool then af_to would appear after ARROW
and $2 and $4 are bumped.  It means adding sa_family_t af to the
struct redirection.  

In the natrule rule if ((! $9->af) || (r.af == $9->af)), then nothing
needs to be done, else an address family translation is needed.  The
following lines have to be changed, replacing r.af with $9->af adding
a line before this to replace 0 with r.af if af_to was empty.

	remove_invalid_hosts(&$9->host, &r.af);
	if (invalid_redirect($9->host, r.af))
		YYERROR;
	if (check_netmask($9->host, r.af))
		YYERROR;

At this point the rule can be one address family and all of the
redirect addresses consistent with each other but not necissarily the
same af as the rule.  The next problem is that there is no way to pass
this af to expand_rule.  That's OK since $9->host ends up as the
protos argument to expand_rule and the af is in each entry.  On this
case the af in proto won't match the af in src_hosts and the
consistency checks (nat_consistent, rdr_consistent) don't check and
its off to pfctl_add_rule.

This gets us to a laer ioctl call of type DIOCADDRULE which puts us in
the kernel code in pf_ioctl.c.

In the case DIOCADDRULE code the checks of pr->rule.af are no longer
enough.  Similar checks are needed on the rule actions.  Something
along the lines of:

#ifndef INET
	if (pr->rule.af == AF_INET) {
		error = EAFNOSUPPORT;
		break;
	}
	if ((pr->rule.action == PF_NAT)
	    || (pr->rule.action == PF_RDR)) {
		if (rule_dst_has_af(pr->rule.dst.addr), AF_INET) {
			error = EAFNOSUPPORT;
			break:
		}
	}
#endif /* INET */

Where rule_dst_has_af loops through the table and checks for
instances of the af in the argument list.

Where the real work would have to be done is in pf_test, pf_test_rule,
pf_get_translation, pf_match_translation, and pf_create_state, and
some functions they use, such as pf_map_addr where mixed af is not
anticipated.  This would definitely be the messy part of any attempt
to make af-to work.

There is no INET/INET6 specific code in pf_test_rule except for ICMP
there is no INET/INET6 specific code and getting the packet length
when dropping TCP and sending a RST.  As a first cut, if ICMP from/to
ICMP6 in NAT and RDR didn't work that would be OK.  A FAIL would send
back TCP RST using the source af, so that code should be OK.

My understanding of this code is still very fuzzy after about a half
day of looking at it.  Perhaps looking at the openbsd pf would help
(hopefully they still resemble each other).

Any help would be appreciated, but for now I'd just like to know
whether if I took the trouble to add af-to support the code would be
picked up (after code review, testing, etc).  I haven't yet decided
whether this is something I want to take on in the first place.

From eri at freebsd.org  Fri Sep 19 08:22:03 2014
From: eri at freebsd.org (=?UTF-8?Q?Ermal_Lu=C3=A7i?=)
Date: Fri, 19 Sep 2014 10:22:02 +0200
Subject: is it possible (practical) to add af-to
In-Reply-To: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com>
References: <201409190026.s8J0QYf8086871@maildrop31.somerville.occnc.com>
Message-ID: <CAPBZQG3=KcJtMzwhYkOoc8v=9+6nC8-VJ7MOU3PLbK09qhfCUg@mail.gmail.com>

Hello Curtis,

On Fri, Sep 19, 2014 at 2:26 AM, Curtis Villamizar <curtis at ipv6.occnc.com>
wrote:

> Hi,
>
> NAT46 and NAT64 require af-to or equivalent.
>
> This may be naive on my part but it doesn't seem like it would be a
> lot of trouble to add af-to to the existing pf.
>
> That said, I am aware of the discussion of further diverging from the
> openbsd pf as discussed in the thread in the archives at
> http://lists.freebsd.org/pipermail/freebsd-pf/2014-July/007391.html
>
> I'm willing to contribute code if there is a chance anyone would be
> willing to take it as an interim until freebsd pf catches up to
> openbsd pf.
>
> Thoughts on this below.
>

I have interest on this.
Though it would be necessary to pickup the IPv6 header parsing code
together with this.
It is related to both to be able to achive this at the end.

My recommendation is to pickup that first and then proceed with this.

If you have any code to share i can take care of reviewing it and probably
glebius@ will be in the loop as well.


>
> Curtis
>
>
>
> Currently the syntax of rdr and nat accept the following:
>
>   nat-rule   = [ "no" ] "nat" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
>                [ "on" ifspec ] [ af ]
>                [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
>                [ "->" ( redirhost | "{" redirhost-list "}" )
>                [ portspec ] [ pooltype ] [ "static-port" ] ]
>
>   rdr-rule   = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ]
>                [ "on" ifspec ] [ af ]
>                [ protospec ] hosts [ "tag" string ] [ "tagged" string ]
>                [ "->" ( redirhost | "{" redirhost-list "}" )
>                [ portspec ] [ pooltype ] ]
>
> Both of these end in:
>
>                [ "->" ( redirhost | "{" redirhost-list "}" )
>                [ portspec ] [ pooltype ] ]
>
> (with nat-rule having the optional [ "static-port" ]).
>
> Changing the syntax is no big deal and that would be the easy part.
>
> In sbin/pf/parse.y some change would be needed to the redirpool rule
> where the two forms are (yacc actions omitted):
>
> redirpool       :
>                 | ARROW redirspec
>                 | ARROW redirspec PORT portstar
>
> to this (or to redirspec) we'd have to add an af_to which would be
> similar to the af rule but with the keywork af-to:
>
> af_to   ; /* empty */   { $$ = 0; }
>         | AF_TO INET    { $$ = AF_INET; }
>         | AF_TO INET6   { $$ = AF_INET6; }
>
> If this is added to the redirpool then af_to would appear after ARROW
> and $2 and $4 are bumped.  It means adding sa_family_t af to the
> struct redirection.
>
> In the natrule rule if ((! $9->af) || (r.af == $9->af)), then nothing
> needs to be done, else an address family translation is needed.  The
> following lines have to be changed, replacing r.af with $9->af adding
> a line before this to replace 0 with r.af if af_to was empty.
>
>         remove_invalid_hosts(&$9->host, &r.af);
>         if (invalid_redirect($9->host, r.af))
>                 YYERROR;
>         if (check_netmask($9->host, r.af))
>                 YYERROR;
>
> At this point the rule can be one address family and all of the
> redirect addresses consistent with each other but not necissarily the
> same af as the rule.  The next problem is that there is no way to pass
> this af to expand_rule.  That's OK since $9->host ends up as the
> protos argument to expand_rule and the af is in each entry.  On this
> case the af in proto won't match the af in src_hosts and the
> consistency checks (nat_consistent, rdr_consistent) don't check and
> its off to pfctl_add_rule.
>
> This gets us to a laer ioctl call of type DIOCADDRULE which puts us in
> the kernel code in pf_ioctl.c.
>
> In the case DIOCADDRULE code the checks of pr->rule.af are no longer
> enough.  Similar checks are needed on the rule actions.  Something
> along the lines of:
>
> #ifndef INET
>         if (pr->rule.af == AF_INET) {
>                 error = EAFNOSUPPORT;
>                 break;
>         }
>         if ((pr->rule.action == PF_NAT)
>             || (pr->rule.action == PF_RDR)) {
>                 if (rule_dst_has_af(pr->rule.dst.addr), AF_INET) {
>                         error = EAFNOSUPPORT;
>                         break:
>                 }
>         }
> #endif /* INET */
>
> Where rule_dst_has_af loops through the table and checks for
> instances of the af in the argument list.
>
> Where the real work would have to be done is in pf_test, pf_test_rule,
> pf_get_translation, pf_match_translation, and pf_create_state, and
> some functions they use, such as pf_map_addr where mixed af is not
> anticipated.  This would definitely be the messy part of any attempt
> to make af-to work.
>
> There is no INET/INET6 specific code in pf_test_rule except for ICMP
> there is no INET/INET6 specific code and getting the packet length
> when dropping TCP and sending a RST.  As a first cut, if ICMP from/to
> ICMP6 in NAT and RDR didn't work that would be OK.  A FAIL would send
> back TCP RST using the source af, so that code should be OK.
>
> My understanding of this code is still very fuzzy after about a half
> day of looking at it.  Perhaps looking at the openbsd pf would help
> (hopefully they still resemble each other).
>
> Any help would be appreciated, but for now I'd just like to know
> whether if I took the trouble to add af-to support the code would be
> picked up (after code review, testing, etc).  I haven't yet decided
> whether this is something I want to take on in the first place.
> _______________________________________________
> 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"
>



-- 
Ermal

From Edwin.Nagle at austinenergy.com  Wed Sep 24 13:37:01 2014
From: Edwin.Nagle at austinenergy.com (Nagle, Edwin (James))
Date: Wed, 24 Sep 2014 13:35:53 +0000
Subject: Source based routing
Message-ID: <27DBC528FBF8094FA7247CC9A0A5C85F02A6A1FE@AE-PEXCH02.aenetad.net>

Hi all,

I'm trying to accomplish something that I think should be pretty simple, but cannot figure out how to do...  Here is my scenario:

I am building a remote access server which will accept ssh connections on three private IP addresses in the same subnet.  The users coming in will need to have their IP sourced from the same IP as they arrived on because current infrastructure is in place to firewall and segment those connections to prevent unauthorized access to assets.  Incoming access will be controlled by radius based on IP address.  Outbound traffic will be controlled via an external firewall based on IP address (thus the need to lock users to the IP address they arrive on).

The server has four interfaces configured, the physical interface (bce0) and three virtual (tap0, tap1, tap2).

I have rebuilt my kernel to allow NAT in PF as well as multiple routing tables.  I found a good article which describes source based routing with multiple routing tables but I think my problem stems from having all the IP addresses on the same network subnet.  I have successfully been able to have the outbound NAT to a single IP but I'm still unclear on how PF works so I'm basically mucking around trying to find something that works (please forgive my ignorance):

My current pf.conf:

nat on ! tap0 from any to any port ssh -> 10.1.9.59
nat on ! tap1 from any to any port ssh -> 10.1.9.60
nat on ! tap2 from any to any port ssh -> 10.1.9.61

All outbound traffic now translates to 10.1.9.59 regardless of which IP I arrived on.  I need to basically match the incoming IP and nat outbound TCP 22 traffic across the same IP.

Anyone have any ideas or suggestions as to how to accomplish this?

Many thanks in advance for any guidance.

James

From Edwin.Nagle at austinenergy.com  Wed Sep 24 14:09:38 2014
From: Edwin.Nagle at austinenergy.com (Nagle, Edwin (James))
Date: Wed, 24 Sep 2014 14:09:37 +0000
Subject: Source based routing
References: <27DBC528FBF8094FA7247CC9A0A5C85F02A6A1FE@AE-PEXCH02.aenetad.net>
 <CAM-i3ighjHvWaep1JiHqFAiC=MjMzjozghRhjgHp1gBScCB=Lg@mail.gmail.com> 
Message-ID: <27DBC528FBF8094FA7247CC9A0A5C85F02A6B3B9@AE-PEXCH02.aenetad.net>

Hello,

Thanks for the information.  I have built multiple routing tables and am running separate sshd instances:

#
# /etc/rc.local
#

# Build my alternate routing tables
/usr/sbin/setfib 0 /sbin/route add default 10.1.9.58
/usr/sbin/setfib 1 /sbin/route add default 10.1.9.59
/usr/sbin/setfib 2 /sbin/route add default 10.1.9.60
/usr/sbin/setfib 3 /sbin/route add default 10.1.9.61

# Start SSH daemons for each interface
/usr/sbin/setfib 0 /usr/sbin/sshd -f /etc/ssh/sshd_config
/usr/sbin/setfib 1 /usr/sbin/sshd -f /etc/ssh/sshd_config.tap0
/usr/sbin/setfib 2 /usr/sbin/sshd -f /etc/ssh/sshd_config.tap1
/usr/sbin/setfib 3 /usr/sbin/sshd -f /etc/ssh/sshd_config.tap2

And have tried the following in my pf.conf:

pass in log on bce0 inet proto tcp from any to (bce0) port ssh rtable 0
pass in log on tap0 inet proto tcp from any to (tap0) port ssh rtable 1
pass in log on tap1 inet proto tcp from any to (tap1) port ssh rtable 2
pass in log on tap2 inet proto tcp from any to (tap2) port ssh rtable 3

But this still doesn?t work.  Any ideas what I?m doing wrong?

Thanks!

James

From: claudiu vasadi [mailto:claudiu.vasadi at gmail.com]
Sent: Wednesday, September 24, 2014 8:59 AM
To: Nagle, Edwin (James)
Subject: Re: Source based routing

Hi,

Have a look at the route-to (ex: pass in log (all) on $int_if route-to { ($ext_if0 $ext_gw0), ($ext_if1 $ext_gw1) } ... etc ... ) and/or rtable (ex: pass in on $ext_if1 proto tcp from any to <ip> port 22 rtable 1)

By default, all outbound traffic is using the defaultrouter.

On Wed, Sep 24, 2014 at 3:35 PM, Nagle, Edwin (James) <Edwin.Nagle at austinenergy.com<mailto:Edwin.Nagle at austinenergy.com>> wrote:
Hi all,

I'm trying to accomplish something that I think should be pretty simple, but cannot figure out how to do...  Here is my scenario:

I am building a remote access server which will accept ssh connections on three private IP addresses in the same subnet.  The users coming in will need to have their IP sourced from the same IP as they arrived on because current infrastructure is in place to firewall and segment those connections to prevent unauthorized access to assets.  Incoming access will be controlled by radius based on IP address.  Outbound traffic will be controlled via an external firewall based on IP address (thus the need to lock users to the IP address they arrive on).

The server has four interfaces configured, the physical interface (bce0) and three virtual (tap0, tap1, tap2).

I have rebuilt my kernel to allow NAT in PF as well as multiple routing tables.  I found a good article which describes source based routing with multiple routing tables but I think my problem stems from having all the IP addresses on the same network subnet.  I have successfully been able to have the outbound NAT to a single IP but I'm still unclear on how PF works so I'm basically mucking around trying to find something that works (please forgive my ignorance):

My current pf.conf:

nat on ! tap0 from any to any port ssh -> 10.1.9.59
nat on ! tap1 from any to any port ssh -> 10.1.9.60
nat on ! tap2 from any to any port ssh -> 10.1.9.61

All outbound traffic now translates to 10.1.9.59 regardless of which IP I arrived on.  I need to basically match the incoming IP and nat outbound TCP 22 traffic across the same IP.

Anyone have any ideas or suggestions as to how to accomplish this?

Many thanks in advance for any guidance.

James
_______________________________________________
freebsd-pf at freebsd.org<mailto: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<mailto:freebsd-pf-unsubscribe at freebsd.org>"



--
Best regards,
Claudiu Vasadi

From lists at peter.de.com  Wed Sep 24 14:18:28 2014
From: lists at peter.de.com (Oliver Peter)
Date: Wed, 24 Sep 2014 16:18:13 +0200
Subject: Source based routing
In-Reply-To: <27DBC528FBF8094FA7247CC9A0A5C85F02A6A1FE@AE-PEXCH02.aenetad.net>
References: <27DBC528FBF8094FA7247CC9A0A5C85F02A6A1FE@AE-PEXCH02.aenetad.net>
Message-ID: <20140924141813.GA14170@mail.opdns.de>

On Wed, Sep 24, 2014 at 01:35:53PM +0000, Nagle, Edwin (James) wrote:
> Hi all,
> 
> I'm trying to accomplish something that I think should be pretty simple, but cannot figure out how to do...  Here is my scenario:
> 
> I am building a remote access server which will accept ssh connections on three private IP addresses in the same subnet.  The users coming in will need to have their IP sourced from the same IP as they arrived on because current infrastructure is in place to firewall and segment those connections to prevent unauthorized access to assets.  Incoming access will be controlled by radius based on IP address.  Outbound traffic will be controlled via an external firewall based on IP address (thus the need to lock users to the IP address they arrive on).
> 
> The server has four interfaces configured, the physical interface (bce0) and three virtual (tap0, tap1, tap2).
> 
> I have rebuilt my kernel to allow NAT in PF as well as multiple routing tables.  I found a good article which describes source based routing with multiple routing tables but I think my problem stems from having all the IP addresses on the same network subnet.  I have successfully been able to have the outbound NAT to a single IP but I'm still unclear on how PF works so I'm basically mucking around trying to find something that works (please forgive my ignorance):
> 
> My current pf.conf:
> 
> nat on ! tap0 from any to any port ssh -> 10.1.9.59
> nat on ! tap1 from any to any port ssh -> 10.1.9.60
> nat on ! tap2 from any to any port ssh -> 10.1.9.61
> 
> All outbound traffic now translates to 10.1.9.59 regardless of which IP I arrived on.  I need to basically match the incoming IP and nat outbound TCP 22 traffic across the same IP.
> 
> Anyone have any ideas or suggestions as to how to accomplish this?

Checkout the Routing section in pf.conf and give 'route-to' a try,
example for outgoing traffic could be:

        pass out log quick on $ext_if route-to tap0 from (tap0:network) to any port ssh


-- 
Oliver PETER       oliver at gfuzz.de       0x456D688F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20140924/fe4f0f3b/attachment.sig>

From mikemacleod at gmail.com  Wed Sep 24 14:35:54 2014
From: mikemacleod at gmail.com (Michael MacLeod)
Date: Wed, 24 Sep 2014 10:35:32 -0400
Subject: FW: Source based routing
In-Reply-To: <27DBC528FBF8094FA7247CC9A0A5C85F02A6B3CA@AE-PEXCH02.aenetad.net>
References: <27DBC528FBF8094FA7247CC9A0A5C85F02A6B3CA@AE-PEXCH02.aenetad.net>
Message-ID: <CAM-FeoHjV6BqWQ_eME8x2o4CL7fxUs+X7Zenn5y7NbJhPJmnwA@mail.gmail.com>

Hello James,

It's still a little unclear to me how you want traffic to flow in this
environment (in particular how the user traffic is arriving on the box),
but it'll probably be easier if you can have each class of user using a
different subnet. Regardless, it appears that you've set the default route
of each FIB to be the address of the interface you want each FIB to use,
which isn't going to work - your default gateway generally isn't yourself.

It appears that all of your traffic should be using the same default
gateway, and you're only interested in ensuring the egress interface/IP of
the traffic. You *may* not even need multiple FIBs, but instead just
multiple instances of SSHD set to listen to specific addresses (emphasis on
may - you might instead need separate FIB, though each one would still have
the same default gateway set).

Regards,
Mike

From laszlo.danielisz at yahoo.com  Thu Sep 25 18:30:51 2014
From: laszlo.danielisz at yahoo.com (Laszlo Danielisz)
Date: Thu, 25 Sep 2014 11:24:01 -0700
Subject: referer filtering
Message-ID: <1411669441.95769.YahooMailNeo@web160705.mail.bf1.yahoo.com>

Hi,

I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer.
Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A.

Any ideas?

Thx!
Laszlo

From javad at smarty.az  Thu Sep 25 19:45:35 2014
From: javad at smarty.az (Javad Mustafayev)
Date: Fri, 26 Sep 2014 00:37:31 +0500
Subject: referer filtering
Message-ID: <mailman.1.1411674338.27493.freebsd-pf@freebsd.org>

Hi, i can suggest config below

lets say this config will be on server B's pf.conf. and your network interface of B ip address 2.2.2.2 is bge0

then you can use the following config

#pf.conf
#macros

ext_if="bge0"
A="1.1.1.1"
B="2.2.2.2"

#global options
set block-policy return #or you can use drop
set skip on lo0
set loginterface $ext_if #optional

#all other configurations

#here you block all

block return in all #or you can use drop :)

#and here allow TCP connections on port 80 only from A(1.1.1.1) to B(2.2.2.2)

pass in log on $ext_if inet proto tcp from $A to $B port 80 keep state

that's all. its so simple configuration file. you can find more advanced and fancy configuration models on the web. but i suggest pf manual ;) 
good luck.
--

???/
name:?????????????????????? Javad Mustafayev
title:??????????????????? System Administrator
company:??????????????????????????? Smarty LLC
mobile:???????????????? 00994.51.927.11.99
mail:?????????????????????????? javad at smarty.az
web.mail:??? j.mustafayev at gmail.com
????/
?

On Sep 25, 2014 11:24 PM, Laszlo Danielisz via freebsd-pf <freebsd-pf at freebsd.org> wrote:
>
> Hi, 
>
> I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer. 
> Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A. 
>
> Any ideas? 
>
> Thx! 
> Laszlo 
> _______________________________________________ 
> 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" 

From laszlo.danielisz at yahoo.com  Fri Sep 26 03:44:46 2014
From: laszlo.danielisz at yahoo.com (Laszlo Danielisz)
Date: Thu, 25 Sep 2014 20:41:23 -0700
Subject: referer filtering
In-Reply-To: <20140925194539.18FCDFEE@hub.freebsd.org>
References: <20140925194539.18FCDFEE@hub.freebsd.org>
Message-ID: <1411702883.12303.YahooMailNeo@web160702.mail.bf1.yahoo.com>

Thank you!

Isn't this just going to accept traffic on port 80 from A t0 B?
pass in log on $ext_if inet proto tcp from $A to $B port 80 keep state


I mean customers who would like to connect to $B won't be able.



On Thursday, September 25, 2014 9:45 PM, Javad Mustafayev <javad at smarty.az> wrote:
 


Hi, i can suggest config below

lets say this config will be on server B's pf.conf. and your network interface of B ip address 2.2.2.2 is bge0

then you can use the following config

#pf.conf
#macros

ext_if="bge0"
A="1.1.1.1"
B="2.2.2.2"

#global options
set block-policy return #or you can use drop
set skip on lo0
set loginterface $ext_if #optional

#all other configurations

#here you block all

block return in all #or you can use drop :)

#and here allow TCP connections on port 80 only from A(1.1.1.1) to B(2.2.2.2)

pass in log on $ext_if inet proto tcp from $A to $B port 80 keep state

that's all. its so simple configuration file. you can find more advanced and fancy configuration models on the web. but i suggest pf manual ;) 
good luck.
--

???/
name:                       Javad Mustafayev
title:                    System Administrator
company:                            Smarty LLC
mobile:                 00994.51.927.11.99
mail:                           javad at smarty.az
web.mail:    j.mustafayev at gmail.com
 ???/
 

On Sep 25, 2014 11:24 PM, Laszlo Danielisz via freebsd-pf <freebsd-pf at freebsd.org> wrote:
>
> Hi, 
>
> I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer. 
> Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A. 
>
> Any ideas? 
>
> Thx! 
> Laszlo 
> _______________________________________________ 
> 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" 
_______________________________________________
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"

From daniel at benzedrine.cx  Fri Sep 26 11:50:55 2014
From: daniel at benzedrine.cx (Daniel Hartmeier)
Date: Fri, 26 Sep 2014 13:22:13 +0200
Subject: referer filtering
In-Reply-To: <1411669441.95769.YahooMailNeo@web160705.mail.bf1.yahoo.com>
References: <1411669441.95769.YahooMailNeo@web160705.mail.bf1.yahoo.com>
Message-ID: <20140926112213.GA18108@insomnia.benzedrine.cx>

On Thu, Sep 25, 2014 at 11:24:01AM -0700, Laszlo Danielisz via freebsd-pf wrote:

> I was wondering how is possible to accept a connection, lets say on port 80 only if it comes from a specified referer.
> Let's say there is a link on server A (IP 1.1.1.1) pointing to server B (IP 2.2.2.2). And server B will only accept the connection if it was sent by A.

You mean filtering based on a HTTP Referer: header?

pf doesn't work on that layer at all.

Technically, B has to accept the client's connection and read the HTTP
request (for the Referer: header) to make its decision. It can produce
an error (or redirect) or close the connection, but "not accepting the
connection" is impossible.

You'd have to do this at the application layer, e.g. Apache has modules
that allow access control based on HTTP headers[1], or use a HTTP proxy
like squid (pf can assist redirecting to it).

Also note that the referer header isn't always reliable, as it can be
faked easily[2].

HTH,
Daniel

[1] http://www.uiowa.edu/server/manual/mod/mod_access_referer.html#motivation
[2] http://www.stardrifter.org/refcontrol/

From mar_jmes20 at outlook.com  Fri Sep 26 17:32:19 2014
From: mar_jmes20 at outlook.com (Sahar alGhrarri)
Date: Fri, 26 Sep 2014 18:32:08 +0100
Subject: I await your response
Message-ID: <694004.1501.bm@smtp215.mail.gq1.yahoo.com>

?Greetings,
I am Mrs. Sahar alGhrarri, the only surviving member of a family that was crushed in a bomb-blast during the war in Libya. Currently, I am battling with a (partial stroke) which resulted from the shock gotten from the incident. Please view the below link for  details: http://www.wsws.org/articles/2011/jun2011/liby-j20.shtml
When my husband whom was a crude oil merchant was alive, we had plans to use the last days of our lives to disburse part of our resources to charity organization and several unknown individuals because when we were much younger in life as a couple, we received financial help from an unknown individual whom we have not met till this day. The impact we got from such gesture made us want to do same.
Unfortunately, my husband is not alive today to do this with me and my health is deteriorating so fast; hence I have decided it on our behalf. Having donated to several individuals and charity organization from our savings, I have decided to anonymously donate the last of our family savings to you.
Irrespective of your previous financial status, please do accept this kind and peaceful offer on behalf of my beloved family. Please acknowledge Mrs. Sahar   Email: sahar-alghram102 at gmx.com
May war and pains never come close to your dwelling place.
Regards
Mrs. Sahar alGhrarri


From russell.yount at gmail.com  Sun Sep 28 04:17:19 2014
From: russell.yount at gmail.com (Russell Yount)
Date: Sun, 28 Sep 2014 00:17:18 -0400
Subject: pf IPv6 NAT using link local addresses
Message-ID: <CA+strHHaGpkGVeu8Nn-pTL5r32VzvN76SODH3KxgGyYUkF1_nQ@mail.gmail.com>

Specify IPv6 NAT with FreeBSD 9.3 in pf.conf as

     nat on $external inet6 from $local6 to any -> ($external)

results in pf attempting to load balance between the routable IPv6
addresses and the link-local IPv6 address as the translation addresses.

Specify IPv6 NAT with FreeBSD 9.3 in pf.conf as

     nat on $external inet6 from $local6 to any -> ($external:0)

results in pf using the link-local IPv6 address as address as the
translation address.

Both of these behaviors are wrong; pf does not understand scope of IPv6
link-local addresses as different from routable ipV6 addresses.

The following patch permits the use of ($external::0) syntax to select the
first routable IPv6 address rather than the link-local address so it can be
used with IPv6 NAT correctly. It only handles the case of one routable IPV6
address and ($external) syntax still attempts to round-robin between
routable IPv6 addresses and the link-local IPv6 address. Not sure if
changing ($external) syntax to omit link-local addresses would cause other
problems?

-Russ <russell.yount at gmail.com>

--- usr/src/sys/contrib//pf/net/pf_if.c-orig    2014-07-10
17:59:41.000000000 -0400
+++ usr/src/sys/contrib//pf/net/pf_if.c 2014-08-24 18:13:57.000000000 -0400
@@ -690,6 +690,10 @@
                    IN6_IS_ADDR_LINKLOCAL(
                    &((struct sockaddr_in6 *)ia->ifa_addr)->sin6_addr))
                        continue;
+               if ((flags & PFI_AFLAG_NOALIAS) && af == AF_INET6 &&
+                   IN6_IS_ADDR_LINKLOCAL(
+                   &((struct sockaddr_in6 *)ia->ifa_addr)->sin6_addr))
+                       continue;
                if (flags & PFI_AFLAG_NOALIAS) {
                        if (af == AF_INET && got4)
                                continue;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd-9.3-pf-ipv6-nat.patch
Type: application/octet-stream
Size: 522 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20140928/973a18de/attachment.obj>

From eri at freebsd.org  Mon Sep 29 18:21:24 2014
From: eri at freebsd.org (=?UTF-8?Q?Ermal_Lu=C3=A7i?=)
Date: Mon, 29 Sep 2014 20:21:21 +0200
Subject: pf stuck
In-Reply-To: <542997C3.5090004@netfence.it>
References: <542997C3.5090004@netfence.it>
Message-ID: <CAPBZQG0CxpSU5zk3C0evQE_y3P=yHfBEOHp+-F4O5ogwfpWPhA@mail.gmail.com>

Probably is better you ask this on freebsd-pf at .

Though this sounds like state limit reached.

On Mon, Sep 29, 2014 at 7:32 PM, Andrea Venturoli <ml at netfence.it> wrote:

> Hello.
>
> Today a box of mine (8.4p16/amd64) stopped working as a router; I don't
> have a clear picture, but the internal nets were working perfectly, while
> the external interfaces lagged, dropped connections or stopped packets from
> passing.
>
> The box is running pf (for handling multiple Internet lines) + ipfw (for
> firewalling).
> I tried a simple telnet xxx:80 and this is what I observed:
> _ tcpdump would see packets going out and replies coming in;
> _ an early ipfw allow rule with setup keep-state would see no packet going
> out and would not create any dinamic rule.
>
> This lead me to look into pf...
> "/etc/rc.d/pf restart" did not solve.
> "/etc/rc.d/pf stop ; /etc/rc.d/pf start" did!
>
>
>
> These are my pf rules:
>
>> pass out quick inet from 192.168.x.0/24 to 192.168.y.0/24 no state
>> pass out quick inet from 192.168.x.0/24 to 192.168.z.0/24 no state
>> pass out log quick route-to (vlan3 192.168.x.x) inet from 192.168.x.0/24
>> to ! 192.168.x.0/24 no state
>> pass out quick inet from a.b.c.d/29 to 192.168.y.0/24 no state
>> pass out quick inet from a.b.c.d/29 to 192.168.z.0/24 no state
>> pass out log quick route-to (vlan1 a.b.c.e) inet from a.b.c.d/29 to !
>> a.b.c.d/29 no state
>> pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state
>> pass out quick inet from i.j.k.l/29 to 192.168.z.0/24 no state
>> pass out log quick route-to (vlan2 i.j.k.m) inet from i.j.k.l/29 to !
>> i.j.k.l/29 no state
>>
>
> These rules are working fine, but have hanged already twice in two weeks
> (once on this box, once on an almost identical one).
>
>
>
> Is there any known problem wrt running pf? pf+ipfw? pf on 8.4?
> Any hint on how to search for what's wrong?
>
>
>
>  bye & Thanks
>         av.
>
> P.S. Please, forgive me, but I'm quite noob with pf.
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>



-- 
Ermal

From ml at netfence.it  Mon Sep 29 20:42:20 2014
From: ml at netfence.it (Andrea Venturoli)
Date: Mon, 29 Sep 2014 22:42:12 +0200
Subject: pf stuck
In-Reply-To: <CAPBZQG0CxpSU5zk3C0evQE_y3P=yHfBEOHp+-F4O5ogwfpWPhA@mail.gmail.com>
References: <542997C3.5090004@netfence.it>
 <CAPBZQG0CxpSU5zk3C0evQE_y3P=yHfBEOHp+-F4O5ogwfpWPhA@mail.gmail.com>
Message-ID: <5429C424.9060400@netfence.it>

On 09/29/14 20:21, Ermal Lu?i wrote:
> Probably is better you ask this on freebsd-pf at .

Thanks, I see you have already cc:ed it.



> Though this sounds like state limit reached.

Can this happen even if all my pf rules have "no state"?



  bye & Thanks
	av.

From hoomanfazaeli at gmail.com  Tue Sep 30 10:21:07 2014
From: hoomanfazaeli at gmail.com (Hooman Fazaeli)
Date: Tue, 30 Sep 2014 13:51:05 +0330
Subject: pf stuck
In-Reply-To: <5429C424.9060400@netfence.it>
References: <542997C3.5090004@netfence.it>
 <CAPBZQG0CxpSU5zk3C0evQE_y3P=yHfBEOHp+-F4O5ogwfpWPhA@mail.gmail.com>
 <5429C424.9060400@netfence.it>
Message-ID: <542A8411.1060608@gmail.com>

On 9/30/2014 12:12 AM, Andrea Venturoli wrote:
> On 09/29/14 20:21, Ermal Lu?i wrote:
>> Probably is better you ask this on freebsd-pf at .
>
> Thanks, I see you have already cc:ed it.
>
>
>
>> Though this sounds like state limit reached.
>
> Can this happen even if all my pf rules have "no state"?
No. Anyway, you can check state statistics  with: pfctl -s i ; pfctl -s m

-- 

Best regards.
Hooman Fazaeli