From sebster at sebster.com Wed Apr 1 02:45:46 2009 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Apr 1 02:45:53 2009 Subject: state mismatch/connection issues In-Reply-To: <49C9F27F.3010505@sebster.com> References: <49C9F27F.3010505@sebster.com> Message-ID: <49D337C7.9020707@sebster.com> Hi, I upgrade to the latest FreeBSD-7.0 release using freebsd-update, with kernel 7.0-RELEASE-p11. I still get massive amounts of state mismatches and intermittent connection problems (connection refused, operation not permitted) with outging connections.... My firewall rules are unchanged (see below), the stats are now: Status: Enabled for 3 days 21:29:15 Debug: Urgent State Table Total Rate current entries 1994 searches 33567431 99.7/s inserts 4611322 13.7/s removals 4609328 13.7/s Counters match 6170429 18.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 1 0.0/s memory 1516667 4.5/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 247 0.0/s state-mismatch 1438892 4.3/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s Does anybody have *any* clue what's going on, and how I can go about fixing it? Thanks in advance, Sebastiaan Sebastiaan van Erk wrote: > Hi, > > I'm running FreeBSD-7.0 RELEASE with the following patch to the kernel > (I know it's integrated in the latest patchlevels which you get when you > do freebsd-update, but since I'm still getting state-mismatches WITH the > patch I'm holding off on the upgrade until I have more information as to > the nature of the problem): > > *** net/pf.c 2007/09/07 21:34:10 1.558 > --- net/pf.c 2007/09/18 19:45:59 1.559 > *************** pf_test_state_tcp(struct pf_state **state, int directi > *** 3730,3735 **** > --- 3730,3751 ---- > REASON_SET(reason, PFRES_SYNPROXY); > return (PF_SYNPROXY_DROP); > } > + } > + > + if (((th->th_flags & (TH_SYN|TH_ACK)) == TH_SYN) && > + dst->state >= TCPS_FIN_WAIT_2 && > + src->state >= TCPS_FIN_WAIT_2) { > + if (pf_status.debug >= PF_DEBUG_MISC) { > + printf("pf: state reuse "); > + pf_print_state(*state); > + pf_print_flags(th->th_flags); > + printf("\n"); > + } > + /* XXX make sure it's the same direction ?? */ > + (*state)->src.state = (*state)->dst.state = TCPS_CLOSED; > + pf_unlink_state(*state); > + *state = NULL; > + return (PF_DROP); > } > > if (src->wscale && dst->wscale && !(th->th_flags & TH_SYN)) { > > > The problem I'm having is that I get intermittent connection > refused/operation not permitted to another machine on the local network. > When I do pfctl -s info I see *huge* numbers of state mismatches: > > Status: Enabled for 94 days 01:27:40 Debug: Urgent > > State Table Total Rate > current entries 398 > searches 986228319 121.4/s > inserts 104049508 12.8/s > removals 104049110 12.8/s > Counters > match 107482262 13.2/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 42 0.0/s > memory 3125235 0.4/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 13919 0.0/s > state-mismatch 3039814 0.4/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 0 0.0/s > > This is causing serious problems at them moment. It seems that the state > problems occur in certain small time windows (my nagios starts reporting > that every service is connection refused/operation not permitted, which > is about 20 services). Then I get 20 recovery messages. > > The firewall rules are trivially simple, $ext_if has 2 ips and $int_if > has one: > > interfaces = "{" $ext_if "," $int_if "}" > > scrub in all > set skip on lo0 > antispoof for $interfaces inet > block out log quick on $ext_if from !$ext_ip1 to any > block in quick on $ext_if from any to 255.255.255.255 > block log all > > pass in quick inet proto icmp all icmp-type $icmp_types > > pass in quick on $int_if from $int_net to any > pass out quick on $int_if from any to $int_net > > pass out on $ext_if proto tcp all > pass out on $ext_if proto { udp, icmp } all > pass in on $ext_if proto tcp from any to $ext_ip1 port $tcp_services1 > pass in on $ext_if proto tcp from any to $ext_ip2 port $tcp_services2 > > Does anybody have any idea what's going on and where I can look? This is > a production server so it's seriously influencing the quality of the > hosted services. :-( > > > Regards, > Sebastiaan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090401/05e4c1b4/smime.bin From sebastian.tymkow at gmail.com Wed Apr 1 06:18:40 2009 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Wed Apr 1 06:18:47 2009 Subject: Authpf and shell access Message-ID: <692660060904010558g6ea63972q5b23b2c63617b425@mail.gmail.com> Hi, I wonder if there is any solution to use authpf with normal shell. I need to grant access to server for normal user but I don't want to set another account to do this. In example userA has shell /bin/csh userA_authpf has shell /usr/bin/authpf I need only one account (userA) which allow me use both capabilities : ssh with shell and grant access to other services after right authentication (when I do this using authpf). Is it possible ? Best regards, Sebastian Tymkow From artis.caune at gmail.com Thu Apr 2 13:28:34 2009 From: artis.caune at gmail.com (Artis Caune) Date: Thu Apr 2 13:28:41 2009 Subject: state mismatch/connection issues In-Reply-To: <49C9F27F.3010505@sebster.com> References: <49C9F27F.3010505@sebster.com> Message-ID: <9e20d71e0904021328u5e871322k1523c2ce0bf9fdd1@mail.gmail.com> 2009/3/25 Sebastiaan van Erk : > The problem I'm having is that I get intermittent connection > refused/operation not permitted to another machine on the local network. > When I do pfctl -s info I see *huge* numbers of state mismatches: > > The firewall rules are trivially simple, $ext_if has 2 ips and $int_if has > one: > > interfaces = "{" $ext_if "," $int_if "}" > > scrub in all > set skip on lo0 > antispoof for $interfaces inet > block out log quick on $ext_if from !$ext_ip1 to any > block in quick on $ext_if from any to 255.255.255.255 > block log all > > pass in quick inet proto icmp all icmp-type $icmp_types > > pass in quick on $int_if from $int_net to any > pass out quick on $int_if from any to $int_net > > pass out on $ext_if proto tcp all > pass out on $ext_if proto { udp, icmp } all > pass in on $ext_if proto tcp from any to $ext_ip1 port $tcp_services1 > pass in on $ext_if proto tcp from any to $ext_ip2 port $tcp_services2 try without "block out log quick on $ext_if from !$ext_ip1 to any" rule. btw, is your firewall forwarding traffic or doing nat? Can you show pfctl -sr and ifconfig output? -- regards, Artis Caune <----. CCNA | BSDA <----|==================== <----' didii FreeBSD From sebster at sebster.com Sat Apr 4 02:44:35 2009 From: sebster at sebster.com (Sebastiaan van Erk) Date: Sat Apr 4 02:44:42 2009 Subject: state mismatch/connection issues In-Reply-To: <9e20d71e0904021328u5e871322k1523c2ce0bf9fdd1@mail.gmail.com> References: <49C9F27F.3010505@sebster.com> <9e20d71e0904021328u5e871322k1523c2ce0bf9fdd1@mail.gmail.com> Message-ID: <49D72BFF.40109@sebster.com> Hi, Thanks for the reply. > try without "block out log quick on $ext_if from !$ext_ip1 to any" rule. I have other firewalls with the same rule which don't show the problem. > btw, is your firewall forwarding traffic or doing nat? Actually it does neither, there is no need for the backend servers to access the internet directly. > Can you show pfctl -sr and ifconfig output? Looking again at the pfctl -s info output, I saw something which I missed the first time around: State Table Total Rate current entries 668 searches 70482052 118.5/s inserts 8153087 13.7/s removals 8152419 13.7/s Counters match 10637818 17.9/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 1 0.0/s memory 2405587 4.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 510 0.0/s state-mismatch 2276240 3.8/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s The memory limit is hit almost the same amount of time as the state mismatches. It seems that my limits were simply too low. I have increased the limits (states/frags) and will see if the problem is resolved now. Regards, Sebastiaan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090404/70b56a65/smime.bin From claudiu.vasadi at gmail.com Sun Apr 5 06:38:02 2009 From: claudiu.vasadi at gmail.com (Vasadi I. Claudiu Florin) Date: Sun Apr 5 06:38:10 2009 Subject: samba and pf (full access rule) Message-ID: Hello guys, I have a strange situation here. I'm aware of the issues samba has with firewalling and decided to grant full access to the samba server from 1 IP. Added a line like: pass in on $ext_if from to port {0:65535} and it worked. Yesterday I decided to play around with NAT, so I added an extra network card (rl1) ans started reading. Managed to get NAT up and running but when returning to my box (the box) I've noticed that I could not access ther samba server any more. So I backtraced my steps and commented out just about everything that could interfere with samba. Nothing worked. Maybe I have some syntax error (none pointed by pfctl -(n)f ) that I didn't figure out yet. Ow, and one more thing. I changed the rule to macros. Read the pf.conf file and ypu will understand ##################### ## Macros I ###### ### Global ### ##################### me = "192.168.0.2" ext_if = "rl0" int_if = "rl1" lo_if = "lo0" int_net = "192.168.1.0/24" router = "192.168.0.1" allowed_ports = "{ ftp, ssh, smtp, 80, 443, pop3, 65530:65535 }" allowed_protocols = "{ tcp, udp }" ks = "keep state" ss = "synproxy state" ms = "modulate state" #################### ### Macros II ##### # !! Exceptions !! # #################### # Allow all ports from 192.168.0.6 to 192.168.0.2 (for SAMBA) exception_if_1_src = "rl0" # Interface exception_ip_1_src = "192.168.0.6" # !!! ATTENTION !!! These IP's get access to ALL ports exception_ip_1_dst = "192.168.0.2" # exception_proto_1 = "{ tcp, udp }" # Protocols exception_port_1 = "{ 0:65535 }" # Ports # Edit use # Remeber to uncoment @ Automated rules #exception_if_2_src = # Interface #exception_ip_2_src = "" # !!! ATTENTION !!! These IP's get access to ALL ports #exception_ip_2_dst = "" # #exception_proto_2 = "" # Protocols #exception_port_2 = "" # Ports # Edit use # Remeber to uncoment @ Automated rules #exception_if_3_src = # Interface #exception_ip_3_src = "" # !!! ATTENTION !!! These IP's get access to ALL ports #exception_ip_3_dst = "" # #exception_proto_3 = "" # Protocols #exception_port_3 = "" # Ports ## Tables ## Options set skip on $lo_if set debug urgent set loginterface $ext_if set ruleset-optimization basic set state-policy if-bound ## Scrub #scrub in on $ext_if all no-df random-id max-mss 1500 fragment reassemble #scrub on $ext_if reassemble tcp ## Queueing ## Translation (NAT/RDR) #nat on $ext_if from 192.168.1.0/24 to any -> ($ext_if) ############################# ##### Filter Rules ###### ############################# block in log all pass out all # Samba from/to 192.168.1.30 #pass in on $int_if proto udp from 192.168.1.30/32 to $int_if port {137, 138} #pass out on $int_if proto udp from 192.168.1.30/32 to $int_if port {137, 138} #pass in on $int_if proto tcp from 192.168.1.30/32 to $int_if port {139, 445} #pass out on $int_if proto tcp from 192.168.1.30/32 to $int_if port {139, 445} ############################### ##### Automated Rules ##### # No editing past this point # ############################### # Globals pass in on $ext_if proto $allowed_protocols from any to $ext_if port $allowed_ports # Exceptions (1,2,3 ... ) pass in on $exception_if_1_src proto $exception_proto_1 from $exception_ip_1_src \ to $exception_ip_1_dst port $exception_port_1 #pass in on $exception_if_2_src proto $exception_proto_2 from $exception_ip_2_src \ to $exception_ip_2_dst port $exception_port_2 #pass in on $exception_if_3_src proto $exception_proto_3 from $exception_ip_3_src \ to $exception_ip_3_dst port $exception_port_3 Also tryed with scrub on/pff. Didn't work. the box is 192.168.0.6 and the samba server is 192.168.0.2 pfctl -sr shows the rulles being loaded: pass in on rl0 inet proto tcp from 192.168.0.6 to 192.168.0.2 port 0:65535 flags S/SA keep state (if-bound) pass in on rl0 inet proto udp from 192.168.0.6 to 192.168.0.2 port 0:65535 keep state (if-bound) Also I have block in all and pass out all: block drop in log all pass out all flags S/SA keep state (if-bound) Thought that maybe I've mispelled something so I commented out "exception1" and added: pass in on rl0 from to port {0:65535} it was the same.... So I thought that maybe it's samba's fault... well, it's not. Not with pf disable it's not..... so.... ideas ? From claudiu.vasadi at gmail.com Sun Apr 5 08:25:20 2009 From: claudiu.vasadi at gmail.com (Vasadi I. Claudiu Florin) Date: Sun Apr 5 08:25:27 2009 Subject: samba and pf (full access rule) In-Reply-To: <7731938b0904050718g25673a75s9b0f16a045f891b3@mail.gmail.com> References: <7731938b0904050718g25673a75s9b0f16a045f891b3@mail.gmail.com> Message-ID: omg, and I thought I was the only one writing novells here .. haha > Don't worry about syntax errors per se, pfctl won't load a new ruleset > if its syntax isn't good. I know. > You've already said it works without pf loaded, so I'll avoid my usual > "have you checked your inteface IPs and routing table" blurb ;-) You forgot to ask me if my network rj45 cable is connected lol. > Your rule set is small, and its obviously not a production box so you > can afford to set every rule to log just now. Do that, then run > tcpdump on the pflog interface [....] Already done that. Just that, I've done so much it's hard on a one try basis to remeber everything. Now that you mention it, I recall doing tcpdump and nothing out of the ordinary was logged. > you don't need to open all ports > for samba. I know, but first we test, then we narrow down the ports ... etc. I previously opened each port individual and had no success with samba. > The last thing I'd say is you may be using macros a tad too much. Will work on the syntax latter. > The documentation at http://www.openbsd.org/faq/pf/ has good > explanations on most of pretty much everything pf, and you could do > worse than copy the style from the sample file, at least to start > with. Yup, I know, I have a tab with it opened. am reading it (again) ok, some info: i'm working on a xp64 box with no firewall (deactivated), no anty-spy, no anty-nothing.... when (in my computer) I write \\ I'm able to log into the shares BUT when I try to access the samba share through my network places -> M$ Win Net. -> "domain" -> "samba server" I get "permision denied" and/or "cannot find hostname" *BUT - 2* If prior to that, I deactivate pf (if pf is down I'm able to browse through my network places) and establish a conection (click on "samba server" in my "domain") and afterwards re-activate pf, I am able to browse the network (through my net. places) hmm.... keep in mind that windows firewall is down, and have no restrictions what-so-ever. //-->> I replaced ports 0:65535 with {135, 137:139, 445} and reloaded the rules // Knowing that IF a prior conection is establied with samba (even with pf up) I first rebooted my xp64 box. So: pf is up, samba is up, xp64 is rebooted and here we go. try 1: My computer - > my network places -> entire network -> microsoft windows network -> "workgroup name" -> *and no samba server in sight* try2: my computer -> *write* \\ : windows cannot find hostname try3: my computer -> *write* \\ : works (as always) I again do "try1" my comp -> my net. places -> entire network -> M$ win. network (*stalls for ~10-15 sec) -> "my workgroup" (stalles again : same time period) -> *and I can see my samba box but cannot access it* Proof of concept: I deactivate pf, go -> my net. places ..... -> am able to see/browse the samba box ( !!! NO STALLS !!!) I re-activate pf Again my computer -> my network places (no stalls up until I want to access the samba box itself *stall ~ 10 sec*) -> works It's not that I'm an idiot and really really whant to access samba through my network places (am perfectly capable of mapping drives or adding network shares to xp (wich are already done btw)) but am really curious why this behaviour. I know samba was written prior to first firewall book but ...... c'mon, somethings wrong and it's slipping by me, and i'm furious Ideas ? From claudiu.vasadi at gmail.com Sun Apr 5 08:57:11 2009 From: claudiu.vasadi at gmail.com (Vasadi I. Claudiu Florin) Date: Sun Apr 5 08:57:18 2009 Subject: samba and pf (full access rule) - [SOLVED] In-Reply-To: References: <7731938b0904050718g25673a75s9b0f16a045f891b3@mail.gmail.com> Message-ID: ok, found the problem, and is NOT pf related. in rc.conf, somehow, winbind_enable was set to "NO". Changed it to "YES" and with pf enabled all is ok now from a pf point of view. on the other hand, samba is yelling in agony, error agony that is. ow well, we can't all be perfect :P Thx for all the help. From bugmaster at FreeBSD.org Mon Apr 6 04:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:08:43 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200904061106.n36B6wPi061954@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o kern/130977 pf [netgraph][pf] kernel panic trap 12 on user connect to o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From MondoBancoPosta at bancopostaonline.net Mon Apr 6 12:38:47 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 12:39:09 2009 Subject: Premio vi aspetta! Message-ID: <1239045563.43860.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From to.my.trociny at gmail.com Fri Apr 10 04:50:03 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Fri Apr 10 04:50:09 2009 Subject: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Message-ID: <200904101150.n3ABo30b066303@freefall.freebsd.org> The following reply was made to PR kern/130977; it has been noted by GNATS. From: Mikolaj Golub To: bug-followup@FreeBSD.org,darkibot@gmail.com Cc: Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Date: Fri, 10 Apr 2009 14:42:59 +0300 The problem here (as in kern/131310 and may be in some other reports) is that net/if.c:if_attach() when attaching interface adds it to default group ALL calling if_addgroup(ifp, IFG_ALL). But when interface is removed (in this case ng, but the same thing occurs for other interfaces too, e.g. I checked it for tap) the reference to it does not removed from ifgl_group.ifg_members list. The simple test can be used to confirm this: 1) add interface (e.g. starting mpd); 2) run kgdb and find reference to ng interface in the list ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members E.g. in my case it is: (kgdb) p *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $1 = {if_softc = 0xc4e180c0, if_l2com = 0x0, if_link = {tqe_next = 0x0, tqe_prev = 0xc4264808}, if_xname = "ng0", '\0' , if_dname = 0xc4bd60d9 "ng", if_dunit = 0, if_addrhead = { tqh_first = 0xc4ba4e00, tqh_last = 0xc4ba4e60}, if_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc07abb00 , kl_unlock = 0xc07abb30 , ... 3) remove ng interface (e.g. stopping mpd). Check that in the list ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members we still have the reference to already removed interface: (kgdb) p *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $2 = {if_softc = 0xdeadc0de, if_l2com = 0xdeadc0de, if_link = {tqe_next = 0xdeadc0de, tqe_prev = 0xdeadc0de}, if_xname = "ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ", if_dname = 0xdeadc0de , if_dunit = -559038242, if_addrhead = {tqh_first = 0xdeadc0de, tqh_last = 0xdeadc0de}, if_klist = {kl_list = { slh_first = 0xdeadc0de}, kl_lock = 0xdeadc0de, kl_unlock = 0xdeadc0de, kl_locked = 0xdeadc0de, If you repeat this process many times you will have the long least of invalid ifgm_ifp references. pf traverses the list ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members in pfi_table_update and calls pfi_instance_add() with nonvalid ifgm_ifp argument and the system panics trying to access invalid memory. I don't know if this correct solution but adding if_delgroup(ifp, IFG_ALL) to sys/net/if.c:if_detach() fixes the problem for me. --- sys/net/if.c.orig 2009-04-01 10:53:55.000000000 +0300 +++ sys/net/if.c 2009-04-10 12:38:14.000000000 +0300 @@ -846,6 +846,7 @@ if_detach(struct ifnet *ifp) mtx_destroy(&ifp->if_snd.ifq_mtx); IF_AFDATA_DESTROY(ifp); splx(s); + if_delgroup(ifp, IFG_ALL); } /* -- Mikolaj Golub From max at love2party.net Fri Apr 10 07:04:25 2009 From: max at love2party.net (Max Laier) Date: Fri Apr 10 07:04:32 2009 Subject: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server In-Reply-To: <200904101150.n3ABo30b066303@freefall.freebsd.org> References: <200904101150.n3ABo30b066303@freefall.freebsd.org> Message-ID: <200904101604.20987.max@love2party.net> On Friday 10 April 2009 13:50:03 Mikolaj Golub wrote: > The following reply was made to PR kern/130977; it has been noted by GNATS. > > From: Mikolaj Golub > To: bug-followup@FreeBSD.org,darkibot@gmail.com > Cc: > Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user > connect to VPN server Date: Fri, 10 Apr 2009 14:42:59 +0300 > > The problem here (as in kern/131310 and may be in some other reports) is > that net/if.c:if_attach() when attaching interface adds it to default group > ALL calling if_addgroup(ifp, IFG_ALL). But when interface is removed (in > this case ng, but the same thing occurs for other interfaces too, e.g. I > checked it for tap) the reference to it does not removed from > ifgl_group.ifg_members list. > > The simple test can be used to confirm this: > > 1) add interface (e.g. starting mpd); > > 2) run kgdb and find reference to ng interface in the list > ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members > > E.g. in my case it is: > > (kgdb) p > *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.ifgm >_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $1 = {if_softc > = 0xc4e180c0, if_l2com = 0x0, if_link = {tqe_next = 0x0, tqe_prev = > 0xc4264808}, if_xname = "ng0", '\0' , if_dname = > 0xc4bd60d9 "ng", if_dunit = 0, if_addrhead = { tqh_first = 0xc4ba4e00, > tqh_last = 0xc4ba4e60}, if_klist = {kl_list = {slh_first = 0x0}, kl_lock = > 0xc07abb00 , kl_unlock = 0xc07abb30 , > ... > > 3) remove ng interface (e.g. stopping mpd). Check that in the list > ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members we still have > the reference to already removed interface: > > (kgdb) p > *ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members.tqh_first.ifgm >_next.tqe_next.ifgm_next.tqe_next.ifgm_next.tqe_next.ifgm_ifp $2 = {if_softc > = 0xdeadc0de, if_l2com = 0xdeadc0de, if_link = {tqe_next = 0xdeadc0de, > tqe_prev = 0xdeadc0de}, if_xname = "????????????????", if_dname = > 0xdeadc0de , if_dunit = > -559038242, if_addrhead = {tqh_first = 0xdeadc0de, tqh_last = 0xdeadc0de}, > if_klist = {kl_list = { slh_first = 0xdeadc0de}, kl_lock = 0xdeadc0de, > kl_unlock = 0xdeadc0de, kl_locked = 0xdeadc0de, > > If you repeat this process many times you will have the long least of > invalid ifgm_ifp references. > > pf traverses the list > ifnet.tqh_first.if_groups->tqh_first.ifgl_group.ifg_members in > pfi_table_update and calls pfi_instance_add() with nonvalid ifgm_ifp > argument and the system panics trying to access invalid memory. > > I don't know if this correct solution but adding if_delgroup(ifp, IFG_ALL) > to sys/net/if.c:if_detach() fixes the problem for me. > > --- sys/net/if.c.orig 2009-04-01 10:53:55.000000000 +0300 > +++ sys/net/if.c 2009-04-10 12:38:14.000000000 +0300 > @@ -846,6 +846,7 @@ if_detach(struct ifnet *ifp) > mtx_destroy(&ifp->if_snd.ifq_mtx); > IF_AFDATA_DESTROY(ifp); > splx(s); > + if_delgroup(ifp, IFG_ALL); > } > > /* Good catch! Thank you very much. I'll commit your fix shortly after some testing and will see that we can get it into 7.2 -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From dfilter at FreeBSD.ORG Fri Apr 10 07:50:03 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Apr 10 07:50:09 2009 Subject: kern/130977: commit references a PR Message-ID: <200904101450.n3AEo2l6008023@freefall.freebsd.org> The following reply was made to PR kern/130977; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130977: commit references a PR Date: Fri, 10 Apr 2009 14:42:01 +0000 (UTC) Author: mlaier Date: Fri Apr 10 14:41:51 2009 New Revision: 190895 URL: http://svn.freebsd.org/changeset/base/190895 Log: Remove interfaces from IFG_ALL on detach. This cures a couple of pf panics when using the "self" keyword in tables or as ()-style host address and fixes "ifconfig -g all" output. PR: kern/130977, kern/131310 Submitted by: Mikolaj Golub MFC after: 3 days Modified: head/sys/net/if.c Modified: head/sys/net/if.c ============================================================================== --- head/sys/net/if.c Fri Apr 10 14:24:12 2009 (r190894) +++ head/sys/net/if.c Fri Apr 10 14:41:51 2009 (r190895) @@ -887,6 +887,7 @@ if_detach(struct ifnet *ifp) rt_ifannouncemsg(ifp, IFAN_DEPARTURE); EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL); + if_delgroup(ifp, IFG_ALL); IF_AFDATA_LOCK(ifp); for (dp = domains; dp; dp = dp->dom_next) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Fri Apr 10 12:20:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri Apr 10 12:20:11 2009 Subject: kern/130977: commit references a PR Message-ID: <200904101920.n3AJK4GZ070886@freefall.freebsd.org> The following reply was made to PR kern/130977; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130977: commit references a PR Date: Fri, 10 Apr 2009 19:16:28 +0000 (UTC) Author: mlaier Date: Fri Apr 10 19:16:14 2009 New Revision: 190903 URL: http://svn.freebsd.org/changeset/base/190903 Log: Follow up for r190895 It's not only the "all" group that is affected, but all groups on the given interface. PR: kern/130977, kern/131310 MFC after: 3 days (%vnet) Modified: head/sys/net/if.c Modified: head/sys/net/if.c ============================================================================== --- head/sys/net/if.c Fri Apr 10 18:46:46 2009 (r190902) +++ head/sys/net/if.c Fri Apr 10 19:16:14 2009 (r190903) @@ -141,6 +141,7 @@ static int if_delmulti_locked(struct ifn static void do_link_state_change(void *, int); static int if_getgroup(struct ifgroupreq *, struct ifnet *); static int if_getgroupmembers(struct ifgroupreq *); +static void if_delgroups(struct ifnet *); #ifdef INET6 /* @@ -887,7 +888,7 @@ if_detach(struct ifnet *ifp) rt_ifannouncemsg(ifp, IFAN_DEPARTURE); EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL); - if_delgroup(ifp, IFG_ALL); + if_delgroups(ifp); IF_AFDATA_LOCK(ifp); for (dp = domains; dp; dp = dp->dom_next) { @@ -1025,6 +1026,54 @@ if_delgroup(struct ifnet *ifp, const cha } /* + * Remove an interface from all groups + */ +static void +if_delgroups(struct ifnet *ifp) +{ + INIT_VNET_NET(ifp->if_vnet); + struct ifg_list *ifgl; + struct ifg_member *ifgm; + char groupname[IFNAMSIZ]; + + IFNET_WLOCK(); + while (!TAILQ_EMPTY(&ifp->if_groups)) { + ifgl = TAILQ_FIRST(&ifp->if_groups); + + strlcpy(groupname, ifgl->ifgl_group->ifg_group, IFNAMSIZ); + + IF_ADDR_LOCK(ifp); + TAILQ_REMOVE(&ifp->if_groups, ifgl, ifgl_next); + IF_ADDR_UNLOCK(ifp); + + TAILQ_FOREACH(ifgm, &ifgl->ifgl_group->ifg_members, ifgm_next) + if (ifgm->ifgm_ifp == ifp) + break; + + if (ifgm != NULL) { + TAILQ_REMOVE(&ifgl->ifgl_group->ifg_members, ifgm, + ifgm_next); + free(ifgm, M_TEMP); + } + + if (--ifgl->ifgl_group->ifg_refcnt == 0) { + TAILQ_REMOVE(&V_ifg_head, ifgl->ifgl_group, ifg_next); + EVENTHANDLER_INVOKE(group_detach_event, + ifgl->ifgl_group); + free(ifgl->ifgl_group, M_TEMP); + } + IFNET_WUNLOCK(); + + free(ifgl, M_TEMP); + + EVENTHANDLER_INVOKE(group_change_event, groupname); + + IFNET_WLOCK(); + } + IFNET_WUNLOCK(); +} + +/* * Stores all groups from an interface in memory pointed * to by data */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From shasan at email.unc.edu Fri Apr 10 14:53:49 2009 From: shasan at email.unc.edu (Shaddi Hasan) Date: Fri Apr 10 14:53:55 2009 Subject: building pftop from source fails Message-ID: <126000990904101420p66082c12o50d1da6c1a0b8ebb@mail.gmail.com> Hello, I'm trying to get pftop-0.6 to compile from source on a FreeBSD 6.0 machine. I downloaded pftop-0.6.tar.gz from the author's website, extracted the contents to the machine, and ran "make" as root. However, the build fails. The output is as follows: ---------------- # make cc -O2 -fno-strict-aliasing -pipe? -Wall -DOS_LEVEL=? -c /root/pftop-0.6/pftop.c In file included from /root/pftop-0.6/pftop.c:33: /root/pftop-0.6/config.h:22:14: operator '>' has no left operand /root/pftop-0.6/config.h:31:14: operator '>' has no left operand /root/pftop-0.6/config.h:42:14: operator '>' has no left operand /root/pftop-0.6/config.h:50:14: operator '>' has no left operand /root/pftop-0.6/config.h:56:14: operator '>' has no left operand /root/pftop-0.6/config.h:61:14: operator '>' has no left operand /root/pftop-0.6/config.h:65:14: operator '>' has no left operand /root/pftop-0.6/pftop.c:79:1: warning: "PFUDPS_NAMES" redefined In file included from /root/pftop-0.6/pftop.c:43: /usr/include/net/pfvar.h:1101:1: warning: this is the location of the previous definition /root/pftop-0.6/pftop.c:89:1: warning: "PFOTHERS_NAMES" redefined /usr/include/net/pfvar.h:1115:1: warning: this is the location of the previous definition /root/pftop-0.6/pftop.c:171:1: warning: "PF_RULE_LABEL_SIZE" redefined /usr/include/net/pfvar.h:582:1: warning: this is the location of the previous definition /root/pftop-0.6/pftop.c: In function `sort_size_callback': /root/pftop-0.6/pftop.c:408: warning: initialization makes integer from pointer without a cast /root/pftop-0.6/pftop.c:409: warning: initialization makes integer from pointer without a cast /root/pftop-0.6/pftop.c: In function `sort_pkt_callback': /root/pftop-0.6/pftop.c:427: warning: initialization makes integer from pointer without a cast /root/pftop-0.6/pftop.c:428: warning: initialization makes integer from pointer without a cast /root/pftop-0.6/pftop.c: In function `print_state': /root/pftop-0.6/pftop.c:969: warning: passing arg 2 of `print_fld_size' makes integer from pointer without a cast /root/pftop-0.6/pftop.c:970: warning: passing arg 2 of `print_fld_size' makes integer from pointer without a cast /root/pftop-0.6/pftop.c:972: error: pointer value used where a floating point value was expected /root/pftop-0.6/pftop.c: In function `tb_print_fromto': /root/pftop-0.6/pftop.c:1340: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1340: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1340: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1340: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1340: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1341: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1341: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1341: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1341: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1341: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1343: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1343: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1343: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1343: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1343: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1344: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1344: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1344: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1344: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1344: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1351: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1351: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1351: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1351: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1351: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1352: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1352: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1352: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1352: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1352: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1358: error: structure has no member named `not' /root/pftop-0.6/pftop.c:1364: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1364: warning: passing arg 1 of `tb_print_addr' from incompatible pointer type /root/pftop-0.6/pftop.c:1376: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1376: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1376: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1376: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1376: error: structure has no member named `pfa' /root/pftop-0.6/pftop.c:1377: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1377: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1377: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1377: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1377: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1383: error: structure has no member named `not' /root/pftop-0.6/pftop.c:1389: error: structure has no member named `mask' /root/pftop-0.6/pftop.c:1389: warning: passing arg 1 of `tb_print_addr' from incompatible pointer type *** Error code 1 Stop in /root/pftop-0.6. ---------------- I got similar output trying to compile pftop-0.7 (the most recent version), as well as both packages on a FreeBSD 7.0 machine. Any thoughts on why the build fails? Thanks! Shaddi From max at love2party.net Fri Apr 10 15:15:55 2009 From: max at love2party.net (Max Laier) Date: Fri Apr 10 15:16:02 2009 Subject: building pftop from source fails In-Reply-To: <126000990904101420p66082c12o50d1da6c1a0b8ebb@mail.gmail.com> References: <126000990904101420p66082c12o50d1da6c1a0b8ebb@mail.gmail.com> Message-ID: <200904110015.51410.max@love2party.net> On Friday 10 April 2009 23:20:12 Shaddi Hasan wrote: > I'm trying to get pftop-0.6 to compile from source on a FreeBSD 6.0 > machine. I downloaded pftop-0.6.tar.gz from the author's website, Okay ... I got a couple of questions about this: 1) Why? There is sysutils/pftop ready for the taking 2) Why 6.0? It's EOL'ed (esp. in the pf department) 3) Why?!? > extracted the contents to the machine, and ran "make" as root. > However, the build fails. The output is as follows: > ---------------- > # make > cc -O2 -fno-strict-aliasing -pipe? -Wall -DOS_LEVEL=? -c There's your problem right there. You need to set the OS_LEVEL in the Makefile in order to compile successfully. See the aforementioned port's Makefile for sensible values depending on __FreeBSD_version. > I got similar output trying to compile pftop-0.7 (the most recent > version), as well as both packages on a FreeBSD 7.0 machine. Any > thoughts on why the build fails? ^ ... simply use the port. Be advised, however, that the port fails to build on recent CURRENT due to the libpcap 1.0 update - workaround patch for that problem is attached, a proper solution should hit the tree over the weekend. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- A non-text attachment was scrubbed... Name: pftop.patch Type: text/x-patch Size: 2600 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090410/908c4da5/pftop.bin From max at love2party.net Fri Apr 10 17:20:03 2009 From: max at love2party.net (Max Laier) Date: Fri Apr 10 17:20:09 2009 Subject: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Message-ID: <200904110020.n3B0K301081510@freefall.freebsd.org> The following reply was made to PR kern/130977; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, darkibot@gmail.com Cc: Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Date: Sat, 11 Apr 2009 01:11:54 +0100 --Boundary-00=_LB+3JRWytgyQ4AY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is the MFC patch - if possible, please try and report back. -- Max --Boundary-00=_LB+3JRWytgyQ4AY Content-Type: text/x-patch; charset="ISO-8859-1"; name="mfc.ifg.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mfc.ifg.patch" Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 190905) +++ sys/net/if.c (working copy) @@ -128,6 +128,7 @@ static void do_link_state_change(void *, int); static int if_getgroup(struct ifgroupreq *, struct ifnet *); static int if_getgroupmembers(struct ifgroupreq *); +static void if_delgroups(struct ifnet *); #ifdef INET6 /* * XXX: declare here to avoid to include many inet6 related files.. @@ -828,6 +829,7 @@ rt_ifannouncemsg(ifp, IFAN_DEPARTURE); EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL); + if_delgroups(ifp); IF_AFDATA_LOCK(ifp); for (dp = domains; dp; dp = dp->dom_next) { @@ -963,6 +965,53 @@ } /* + * Remove an interface from all groups + */ +static void +if_delgroups(struct ifnet *ifp) +{ + struct ifg_list *ifgl; + struct ifg_member *ifgm; + char groupname[IFNAMSIZ]; + + IFNET_WLOCK(); + while (!TAILQ_EMPTY(&ifp->if_groups)) { + ifgl = TAILQ_FIRST(&ifp->if_groups); + + strlcpy(groupname, ifgl->ifgl_group->ifg_group, IFNAMSIZ); + + IF_ADDR_LOCK(ifp); + TAILQ_REMOVE(&ifp->if_groups, ifgl, ifgl_next); + IF_ADDR_UNLOCK(ifp); + + TAILQ_FOREACH(ifgm, &ifgl->ifgl_group->ifg_members, ifgm_next) + if (ifgm->ifgm_ifp == ifp) + break; + + if (ifgm != NULL) { + TAILQ_REMOVE(&ifgl->ifgl_group->ifg_members, ifgm, + ifgm_next); + free(ifgm, M_TEMP); + } + + if (--ifgl->ifgl_group->ifg_refcnt == 0) { + TAILQ_REMOVE(&ifg_head, ifgl->ifgl_group, ifg_next); + EVENTHANDLER_INVOKE(group_detach_event, + ifgl->ifgl_group); + free(ifgl->ifgl_group, M_TEMP); + } + IFNET_WUNLOCK(); + + free(ifgl, M_TEMP); + + EVENTHANDLER_INVOKE(group_change_event, groupname); + + IFNET_WLOCK(); + } + IFNET_WUNLOCK(); +} + +/* * Stores all groups from an interface in memory pointed * to by data */ --Boundary-00=_LB+3JRWytgyQ4AY-- From shasan at email.unc.edu Fri Apr 10 18:57:55 2009 From: shasan at email.unc.edu (Shaddi Hasan) Date: Fri Apr 10 18:58:01 2009 Subject: building pftop from source fails In-Reply-To: <200904110015.51410.max@love2party.net> References: <126000990904101420p66082c12o50d1da6c1a0b8ebb@mail.gmail.com> <200904110015.51410.max@love2party.net> Message-ID: <126000990904101857k2f8789aagf43cd3a39137a282@mail.gmail.com> Thanks Max! I fixed the OS_LEVEL and was able to compile mostly without problems. I ran into some conditionally compiled code in pftop.c (near line 1453) that I removed, and I used OpenBSD's queue.h instead of the default system queue.h, as pftop requires the CIRCLEQ api (pftop is written for OpenBSD). As to why I'm doing this, I'm making modifications to pftop to allow for more finely grained updates. First step of course was getting a non-modified pftop to compile. The machine is on 6.0 for reasons specific to our lab setup. Again, thanks for your help. Shaddi On Fri, Apr 10, 2009 at 6:15 PM, Max Laier wrote: > On Friday 10 April 2009 23:20:12 Shaddi Hasan wrote: >> I'm trying to get pftop-0.6 to compile from source on a FreeBSD 6.0 >> machine. I downloaded pftop-0.6.tar.gz from the author's website, > > Okay ... I got a couple of questions about this: > 1) Why? There is sysutils/pftop ready for the taking > 2) Why 6.0? ?It's EOL'ed (esp. in the pf department) > 3) Why?!? > >> extracted the contents to the machine, and ran "make" as root. >> However, the build fails. The output is as follows: >> ---------------- >> # make >> cc -O2 -fno-strict-aliasing -pipe? -Wall -DOS_LEVEL=? -c > > There's your problem right there. ?You need to set the OS_LEVEL in the > Makefile in order to compile successfully. ?See the aforementioned port's > Makefile for sensible values depending on __FreeBSD_version. > >> I got similar output trying to compile pftop-0.7 (the most recent >> version), as well as both packages on a FreeBSD 7.0 machine. Any >> thoughts on why the build fails? > > ^ ... simply use the port. ?Be advised, however, that the port fails to build > on recent CURRENT due to the libpcap 1.0 update - workaround patch for that > problem is attached, a proper solution should hit the tree over the weekend. > > -- > /"\ ?Best regards, ? ? ? ? ? ? ? ? ? ? ?| mlaier@freebsd.org > \ / ?Max Laier ? ? ? ? ? ? ? ? ? ? ? ? ?| ICQ #67774661 > ?X ? http://pf4freebsd.love2party.net/ ?| mlaier@EFnet > / \ ?ASCII Ribbon Campaign ? ? ? ? ? ? ?| Against HTML Mail and News > From bugmaster at FreeBSD.org Mon Apr 13 04:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:34:30 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200904131106.n3DB6vID085031@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o kern/130977 pf [netgraph][pf] kernel panic trap 12 on user connect to o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From mike at sentex.net Mon Apr 13 12:08:23 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Apr 13 12:34:34 2009 Subject: OpenBSD/FreeBSD pf issue ? Message-ID: <200904131857.n3DIvV7C025975@lava.sentex.ca> ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.4/common/013_pf.patch http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt Not sure if this impacts FreeBSD or not ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From citrin at citrin.ru Mon Apr 13 13:02:15 2009 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Mon Apr 13 13:42:25 2009 Subject: max-src-conn issue Message-ID: <49E39547.201@citrin.ru> Hi All. It seems to be, that max-src-conn is broken under FreeBSD, and not useful to limit incoming connections. 1. I have added 2 rules: $ pfctl -s rule pass quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 3) block drop quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh 2. Open 3 ssh connections: $ pfctl -s state all tcp 81.19.90.176:22 <- 81.19.90.156:47767 ESTABLISHED:ESTABLISHED all tcp 81.19.90.176:22 <- 81.19.90.156:47768 ESTABLISHED:ESTABLISHED all tcp 81.19.90.176:22 <- 81.19.90.156:47769 ESTABLISHED:ESTABLISHED $ netstat -n -p tcp Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 81.19.90.176.22 81.19.90.156.47769 ESTABLISHED tcp4 0 0 81.19.90.176.22 81.19.90.156.47768 ESTABLISHED tcp4 0 0 81.19.90.176.22 81.19.90.156.47767 ESTABLISHED 3. When I tried to open one more connections packets matched by first rule was passed, bat state was not created. $ pfctl -z On remote host: ssh 81.19.90.176 $ pfctl -v -s rule pass quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 3) [ Evaluations: 752 Packets: 2 Bytes: 120 States: 3 ] [ Inserted: uid 0 pid 98818 ] block drop quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh [ Evaluations: 2 Packets: 2 Bytes: 128 States: 0 ] [ Inserted: uid 0 pid 98818 ] $ pfctl -s state all tcp 81.19.90.176:22 <- 81.19.90.156:47767 ESTABLISHED:ESTABLISHED all tcp 81.19.90.176:22 <- 81.19.90.156:47768 ESTABLISHED:ESTABLISHED all tcp 81.19.90.176:22 <- 81.19.90.156:47769 ESTABLISHED:ESTABLISHED $ netstat -np tcp Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 81.19.90.176.22 81.19.90.156.48149 SYN_RCVD tcp4 0 0 81.19.90.176.22 81.19.90.156.47769 ESTABLISHED tcp4 0 0 81.19.90.176.22 81.19.90.156.47768 ESTABLISHED tcp4 0 0 81.19.90.176.22 81.19.90.156.47767 ESTABLISHED New state not created, but packets matched first rule is passed, while should be dropped. Because of this new half-open connection is created (in SYN_RCVD state). This makes max-src-conn not very useful under FreeBSD - bad guys can eat as many sockets as they want on attacked host, even when number of connections is limited by pf. $ uname -psv FreeBSD FreeBSD 8.0-CURRENT #0: Wed Apr 8 05:31:05 MSD 2009 citrin@citrin.park.rambler.ru:/usr/obj/usr/src/sys/GENERIC amd64 I have tested same rules on OpenBSD 4.4 - they works as expected - when limit reached, packets matched by first rule dropped, and new state not created. -- Anton Yuzhaninov From aline at riseup.net Mon Apr 13 13:19:30 2009 From: aline at riseup.net (Aline Freitas) Date: Mon Apr 13 13:45:26 2009 Subject: OpenBSD/FreeBSD pf issue ? In-Reply-To: <200904131857.n3DIvV7C025975@lava.sentex.ca> References: <200904131857.n3DIvV7C025975@lava.sentex.ca> Message-ID: <49E39E4F.8020102@riseup.net> Mike Tancsa wrote: > > > ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.4/common/013_pf.patch > > http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt > > > > Not sure if this impacts FreeBSD or not ? > > ---Mike > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" FreeBSD is not affected: Affected OS : OpenBSD 4.{3,4,5}, OpenBSD-current http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt Warning: When browsing the PF FAQ, please keep in mind that different versions of FreeBSD contain different versions of PF: * FreeBSD 5.X -- PF is at OpenBSD 3.5 * FreeBSD 6.X -- PF is at OpenBSD 3.7 * FreeBSD 7.X -- PF is at OpenBSD 4.1 http://www.freebsd.org/doc/en/books/handbook/firewalls-pf.html []'s Aline From sebastian.tymkow at gmail.com Mon Apr 13 13:27:25 2009 From: sebastian.tymkow at gmail.com (=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=) Date: Mon Apr 13 13:46:34 2009 Subject: Authpf -remove only anchor Message-ID: <692660060904131327n6b7c0659u2888c24a3d538fac@mail.gmail.com> Hi, I wonder if there is any patch which alow me to delete only anchor rules for authpf. Authpf usually closes all conections including ssh. I did some modifications which allow me using authpf as normal program (executing from shell) but this close all my conections at the end. Best regards, Sebastian Tymkow From aline at riseup.net Mon Apr 13 13:29:07 2009 From: aline at riseup.net (Aline Freitas) Date: Mon Apr 13 13:46:39 2009 Subject: OpenBSD/FreeBSD pf issue ? In-Reply-To: <200904131857.n3DIvV7C025975@lava.sentex.ca> References: <200904131857.n3DIvV7C025975@lava.sentex.ca> Message-ID: <49E39AB5.8010208@riseup.net> FreeBSD is not affected: Affected OS : OpenBSD 4.{3,4,5}, OpenBSD-current http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt Warning: When browsing the PF FAQ, please keep in mind that different versions of FreeBSD contain different versions of PF: * FreeBSD 5.X -- PF is at OpenBSD 3.5 * FreeBSD 6.X -- PF is at OpenBSD 3.7 * FreeBSD 7.X -- PF is at OpenBSD 4.1 http://www.freebsd.org/doc/en/books/handbook/firewalls-pf.html []'s Aline Mike Tancsa wrote: > > > ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.4/common/013_pf.patch > > http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt > > > > Not sure if this impacts FreeBSD or not ? > > ---Mike > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From max at love2party.net Mon Apr 13 13:47:08 2009 From: max at love2party.net (Max Laier) Date: Mon Apr 13 14:35:11 2009 Subject: OpenBSD/FreeBSD pf issue ? In-Reply-To: <200904131857.n3DIvV7C025975@lava.sentex.ca> References: <200904131857.n3DIvV7C025975@lava.sentex.ca> Message-ID: <200904132247.04332.max@love2party.net> On Monday 13 April 2009 20:58:14 Mike Tancsa wrote: > ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.4/common/013_pf.patch > > http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kerne >l_panic.txt > > > Not sure if this impacts FreeBSD or not ? It looks like FreeBSD is not vulnerable to this - it seems the problem was introduced with OpenBSD pf.c rev. 1.539 (which first appeared in OpenBSD 4.2). Our last full import was OpenBSD 4.1 which doesn't include the vulnerability. Please note that this a preliminary assessment - I will follow-up with a proper version as soon as more people have looked at the situation. Feel free to pitch in if you see remaining problems in the FreeBSD version of pf.c - maybe off-list. In addition it might make sense to drop this kind of packets as part of the "scrub" process, but that is not an immediate concern at this point. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From aline at bsd.com.br Mon Apr 13 13:54:08 2009 From: aline at bsd.com.br (Aline Freitas) Date: Mon Apr 13 14:43:06 2009 Subject: OpenBSD/FreeBSD pf issue ? In-Reply-To: <200904131857.n3DIvV7C025975@lava.sentex.ca> References: <200904131857.n3DIvV7C025975@lava.sentex.ca> Message-ID: <49E3A1DE.2050404@bsd.com.br> Mike Tancsa wrote: > > > ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.4/common/013_pf.patch > > http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt > > > > Not sure if this impacts FreeBSD or not ? > > ---Mike > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" FreeBSD is not affected: Affected OS : OpenBSD 4.{3,4,5}, OpenBSD-current http://helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_panic.txt Warning: When browsing the PF FAQ, please keep in mind that different versions of FreeBSD contain different versions of PF: * FreeBSD 5.X -- PF is at OpenBSD 3.5 * FreeBSD 6.X -- PF is at OpenBSD 3.7 * FreeBSD 7.X -- PF is at OpenBSD 4.1 http://www.freebsd.org/doc/en/books/handbook/firewalls-pf.html []'s Aline From ohauer at gmx.de Mon Apr 13 14:48:34 2009 From: ohauer at gmx.de (Olli Hauer) Date: Mon Apr 13 15:05:44 2009 Subject: Authpf -remove only anchor In-Reply-To: <692660060904131327n6b7c0659u2888c24a3d538fac@mail.gmail.com> References: <692660060904131327n6b7c0659u2888c24a3d538fac@mail.gmail.com> Message-ID: <20090413212151.241590@gmx.net> > Hi, > > I wonder if there is any patch which alow me to delete only anchor rules > for > authpf. > Authpf usually closes all conections including ssh. I did some > modifications > which allow me > using authpf as normal program (executing from shell) but this close all > my > conections at the end. > > Best regards, > > Sebastian Tymkow No, but you can look at into the function authpf_kill_states in file src/contrib/pf/authpf/authpf.c My question is for what exactly do you use authpf? I use a modified authpf shell inside a chrooted cvs server to terminate only the ssh session and allow a tunnel to the pserver port. This way I can provide secure access to the cvs service to non existent system users. Access to pserver is provided via sshd_config. Even it is a good benefit to lower connections from the scrappy Tortoise and Eclipse which tries to fork many sessions for just an update/commit. Best Regards, olli -- Psssst! Schon vom neuen GMX MultiMessenger geh?rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 From peter at allicient.co.uk Mon Apr 13 15:08:47 2009 From: peter at allicient.co.uk (Peter Maxwell) Date: Mon Apr 13 15:45:26 2009 Subject: max-src-conn issue In-Reply-To: <49E39547.201@citrin.ru> References: <49E39547.201@citrin.ru> Message-ID: <7731938b0904131442q4a6ff305x2cd78e584abf4477@mail.gmail.com> Hi Yuzhaninov, Interestingly enough, I checked the pf.conf man page for max-src-conn: "For stateful TCP connections, limits on established connections (connec- tions which have completed the TCP 3-way handshake) can also be enforced per source IP. max-src-conn Limits the maximum number of simultaneous TCP connections which have completed the 3-way handshake that a single host can make. max-src-conn-rate / Limit the rate of new connections over a time interval. The con- nection rate is an approximation calculated as a moving average." which does indicate that only completed handshakes are counted towards max-src-conn; it doesn't however say anything about the initial SYN packet - essentially it seems undefined. You might be able to get a better answer by looking at the source, or asking someone who knows more than me ;-) Have you tried the rules without the 'quick' keyword, I know it's probably down to personal taste but I've always found using 'quick' unless its absolutely essential (and that's not often at all) can cause unexpected difficulties. I don't think this is necessarily a problem either, as I think FreeBSD comes out of the box with protection against SYN floods - again perhaps someone more knowledgeable can expand on this. Best wishes, Peter 2009/4/13 Anton Yuzhaninov : > Hi All. > > It seems to be, that max-src-conn is broken under FreeBSD, and not useful to > limit incoming connections. > > 1. I have added 2 rules: > > $ pfctl -s rule > pass quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh flags > S/SA keep state (source-track rule, max-src-conn 3) > block drop quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh > > 2. Open 3 ssh connections: > > $ pfctl -s state > all tcp 81.19.90.176:22 <- 81.19.90.156:47767 ? ? ? ESTABLISHED:ESTABLISHED > all tcp 81.19.90.176:22 <- 81.19.90.156:47768 ? ? ? ESTABLISHED:ESTABLISHED > all tcp 81.19.90.176:22 <- 81.19.90.156:47769 ? ? ? ESTABLISHED:ESTABLISHED > > $ netstat -n -p tcp > Active Internet connections > Proto Recv-Q Send-Q ?Local Address ? ? ? ? ?Foreign Address ? ? ? (state) > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47769 > ESTABLISHED > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47768 > ESTABLISHED > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47767 > ESTABLISHED > > 3. When I tried to open one more connections packets matched by first rule > was passed, bat state was not created. > > $ pfctl -z > > On remote host: > ssh 81.19.90.176 > > $ pfctl -v -s rule > pass quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh flags > S/SA keep state (source-track rule, max-src-conn 3) > ?[ Evaluations: 752 ? ? ? Packets: 2 ? ? ? ? Bytes: 120 ? ? ? ? States: 3 > ? ] > ?[ Inserted: uid 0 pid 98818 ] > block drop quick on re0 inet proto tcp from 81.19.90.0/23 to any port = ssh > ?[ Evaluations: 2 ? ? ? ? Packets: 2 ? ? ? ? Bytes: 128 ? ? ? ? States: 0 > ? ] > ?[ Inserted: uid 0 pid 98818 ] > $ pfctl -s state > all tcp 81.19.90.176:22 <- 81.19.90.156:47767 ? ? ? ESTABLISHED:ESTABLISHED > all tcp 81.19.90.176:22 <- 81.19.90.156:47768 ? ? ? ESTABLISHED:ESTABLISHED > all tcp 81.19.90.176:22 <- 81.19.90.156:47769 ? ? ? ESTABLISHED:ESTABLISHED > $ netstat -np tcp > Active Internet connections > Proto Recv-Q Send-Q ?Local Address ? ? ? ? ?Foreign Address ? ? ? (state) > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.48149 ? ? SYN_RCVD > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47769 > ESTABLISHED > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47768 > ESTABLISHED > tcp4 ? ? ? 0 ? ? ?0 81.19.90.176.22 ? ? ? ?81.19.90.156.47767 > ESTABLISHED > > New state not created, but packets matched first rule is passed, while > should be dropped. > > Because of this new half-open connection is created (in SYN_RCVD state). > > This makes max-src-conn not very useful under FreeBSD - bad guys can eat as > many sockets as they want on attacked host, even when number of connections > is limited by pf. > > $ uname -psv > FreeBSD FreeBSD 8.0-CURRENT #0: Wed Apr ?8 05:31:05 MSD 2009 > citrin@citrin.park.rambler.ru:/usr/obj/usr/src/sys/GENERIC ?amd64 > > I have tested same rules on OpenBSD 4.4 - they works as expected - when > limit reached, packets matched by first rule dropped, and new state not > created. > > -- > ?Anton Yuzhaninov > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From darkibot at gmail.com Mon Apr 13 15:46:40 2009 From: darkibot at gmail.com (Oleg S) Date: Mon Apr 13 16:05:52 2009 Subject: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server In-Reply-To: <200904110020.n3B0K301081510@freefall.freebsd.org> References: <200904110020.n3B0K301081510@freefall.freebsd.org> Message-ID: i'm tried to reproduce bug with current patch, but it's not reproduced. as i see bug is fixed. thanks. 2009/4/11 Max Laier : > The following reply was made to PR kern/130977; it has been noted by GNATS. > > From: Max Laier > To: bug-followup@freebsd.org, > ?darkibot@gmail.com > Cc: > Subject: Re: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server > Date: Sat, 11 Apr 2009 01:11:54 +0100 > > ?--Boundary-00=_LB+3JRWytgyQ4AY > ?Content-Type: text/plain; > ? charset="us-ascii" > ?Content-Transfer-Encoding: 7bit > ?Content-Disposition: inline > > ?Here is the MFC patch - if possible, please try and report back. > > ?-- > ? Max > > ?--Boundary-00=_LB+3JRWytgyQ4AY > ?Content-Type: text/x-patch; > ? charset="ISO-8859-1"; > ? name="mfc.ifg.patch" > ?Content-Transfer-Encoding: 7bit > ?Content-Disposition: attachment; > ? ? ? ?filename="mfc.ifg.patch" > > ?Index: sys/net/if.c > ?=================================================================== > ?--- sys/net/if.c ? ? ? (revision 190905) > ?+++ sys/net/if.c ? ? ? (working copy) > ?@@ -128,6 +128,7 @@ > ?static void ? do_link_state_change(void *, int); > ?static int ? ?if_getgroup(struct ifgroupreq *, struct ifnet *); > ?static int ? ?if_getgroupmembers(struct ifgroupreq *); > ?+static void ? if_delgroups(struct ifnet *); > ?#ifdef INET6 > ?/* > ? * XXX: declare here to avoid to include many inet6 related files.. > ?@@ -828,6 +829,7 @@ > ? ? ? ?rt_ifannouncemsg(ifp, IFAN_DEPARTURE); > ? ? ? ?EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); > ? ? ? ?devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL); > ?+ ? ? ?if_delgroups(ifp); > > ? ? ? ?IF_AFDATA_LOCK(ifp); > ? ? ? ?for (dp = domains; dp; dp = dp->dom_next) { > ?@@ -963,6 +965,53 @@ > ?} > > ?/* > ?+ * Remove an interface from all groups > ?+ */ > ?+static void > ?+if_delgroups(struct ifnet *ifp) > ?+{ > ?+ ? ? ?struct ifg_list ? ? ? ? *ifgl; > ?+ ? ? ?struct ifg_member ? ? ? *ifgm; > ?+ ? ? ?char groupname[IFNAMSIZ]; > ?+ > ?+ ? ? ?IFNET_WLOCK(); > ?+ ? ? ?while (!TAILQ_EMPTY(&ifp->if_groups)) { > ?+ ? ? ? ? ? ? ?ifgl = TAILQ_FIRST(&ifp->if_groups); > ?+ > ?+ ? ? ? ? ? ? ?strlcpy(groupname, ifgl->ifgl_group->ifg_group, IFNAMSIZ); > ?+ > ?+ ? ? ? ? ? ? ?IF_ADDR_LOCK(ifp); > ?+ ? ? ? ? ? ? ?TAILQ_REMOVE(&ifp->if_groups, ifgl, ifgl_next); > ?+ ? ? ? ? ? ? ?IF_ADDR_UNLOCK(ifp); > ?+ > ?+ ? ? ? ? ? ? ?TAILQ_FOREACH(ifgm, &ifgl->ifgl_group->ifg_members, ifgm_next) > ?+ ? ? ? ? ? ? ? ? ? ? ?if (ifgm->ifgm_ifp == ifp) > ?+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break; > ?+ > ?+ ? ? ? ? ? ? ?if (ifgm != NULL) { > ?+ ? ? ? ? ? ? ? ? ? ? ?TAILQ_REMOVE(&ifgl->ifgl_group->ifg_members, ifgm, > ?+ ? ? ? ? ? ? ? ? ? ? ? ? ?ifgm_next); > ?+ ? ? ? ? ? ? ? ? ? ? ?free(ifgm, M_TEMP); > ?+ ? ? ? ? ? ? ?} > ?+ > ?+ ? ? ? ? ? ? ?if (--ifgl->ifgl_group->ifg_refcnt == 0) { > ?+ ? ? ? ? ? ? ? ? ? ? ?TAILQ_REMOVE(&ifg_head, ifgl->ifgl_group, ifg_next); > ?+ ? ? ? ? ? ? ? ? ? ? ?EVENTHANDLER_INVOKE(group_detach_event, > ?+ ? ? ? ? ? ? ? ? ? ? ? ? ?ifgl->ifgl_group); > ?+ ? ? ? ? ? ? ? ? ? ? ?free(ifgl->ifgl_group, M_TEMP); > ?+ ? ? ? ? ? ? ?} > ?+ ? ? ? ? ? ? ?IFNET_WUNLOCK(); > ?+ > ?+ ? ? ? ? ? ? ?free(ifgl, M_TEMP); > ?+ > ?+ ? ? ? ? ? ? ?EVENTHANDLER_INVOKE(group_change_event, groupname); > ?+ > ?+ ? ? ? ? ? ? ?IFNET_WLOCK(); > ?+ ? ? ?} > ?+ ? ? ?IFNET_WUNLOCK(); > ?+} > ?+ > ?+/* > ? * Stores all groups from an interface in memory pointed > ? * to by data > ? */ > > ?--Boundary-00=_LB+3JRWytgyQ4AY-- > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From dfilter at FreeBSD.ORG Mon Apr 13 15:50:03 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Apr 13 16:28:46 2009 Subject: kern/130977: commit references a PR Message-ID: <200904132250.n3DMo2fk037553@freefall.freebsd.org> The following reply was made to PR kern/130977; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130977: commit references a PR Date: Mon, 13 Apr 2009 22:47:11 +0000 (UTC) Author: mlaier Date: Mon Apr 13 22:17:03 2009 New Revision: 191025 URL: http://svn.freebsd.org/changeset/base/191025 Log: MFH r190903 & r190895: Remove interfaces from interface groups on detach. Reported by: various Submitted by: Mikolaj Golub (r190895) PR: kern/130977, kern/131310 Approved by: re (gnn) Modified: stable/7/sys/ (props changed) stable/7/sys/contrib/pf/ (props changed) stable/7/sys/dev/ath/ath_hal/ (props changed) stable/7/sys/dev/cxgb/ (props changed) stable/7/sys/net/if.c Modified: stable/7/sys/net/if.c ============================================================================== --- stable/7/sys/net/if.c Mon Apr 13 21:04:53 2009 (r191024) +++ stable/7/sys/net/if.c Mon Apr 13 22:17:03 2009 (r191025) @@ -128,6 +128,7 @@ static void if_start_deferred(void *cont static void do_link_state_change(void *, int); static int if_getgroup(struct ifgroupreq *, struct ifnet *); static int if_getgroupmembers(struct ifgroupreq *); +static void if_delgroups(struct ifnet *); #ifdef INET6 /* * XXX: declare here to avoid to include many inet6 related files.. @@ -828,6 +829,7 @@ if_detach(struct ifnet *ifp) rt_ifannouncemsg(ifp, IFAN_DEPARTURE); EVENTHANDLER_INVOKE(ifnet_departure_event, ifp); devctl_notify("IFNET", ifp->if_xname, "DETACH", NULL); + if_delgroups(ifp); IF_AFDATA_LOCK(ifp); for (dp = domains; dp; dp = dp->dom_next) { @@ -963,6 +965,53 @@ if_delgroup(struct ifnet *ifp, const cha } /* + * Remove an interface from all groups + */ +static void +if_delgroups(struct ifnet *ifp) +{ + struct ifg_list *ifgl; + struct ifg_member *ifgm; + char groupname[IFNAMSIZ]; + + IFNET_WLOCK(); + while (!TAILQ_EMPTY(&ifp->if_groups)) { + ifgl = TAILQ_FIRST(&ifp->if_groups); + + strlcpy(groupname, ifgl->ifgl_group->ifg_group, IFNAMSIZ); + + IF_ADDR_LOCK(ifp); + TAILQ_REMOVE(&ifp->if_groups, ifgl, ifgl_next); + IF_ADDR_UNLOCK(ifp); + + TAILQ_FOREACH(ifgm, &ifgl->ifgl_group->ifg_members, ifgm_next) + if (ifgm->ifgm_ifp == ifp) + break; + + if (ifgm != NULL) { + TAILQ_REMOVE(&ifgl->ifgl_group->ifg_members, ifgm, + ifgm_next); + free(ifgm, M_TEMP); + } + + if (--ifgl->ifgl_group->ifg_refcnt == 0) { + TAILQ_REMOVE(&ifg_head, ifgl->ifgl_group, ifg_next); + EVENTHANDLER_INVOKE(group_detach_event, + ifgl->ifgl_group); + free(ifgl->ifgl_group, M_TEMP); + } + IFNET_WUNLOCK(); + + free(ifgl, M_TEMP); + + EVENTHANDLER_INVOKE(group_change_event, groupname); + + IFNET_WLOCK(); + } + IFNET_WUNLOCK(); +} + +/* * Stores all groups from an interface in memory pointed * to by data */ _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From mlaier at FreeBSD.org Mon Apr 13 16:34:48 2009 From: mlaier at FreeBSD.org (mlaier@FreeBSD.org) Date: Mon Apr 13 16:50:35 2009 Subject: kern/130977: [netgraph][pf] kernel panic trap 12 on user connect to VPN server Message-ID: <200904132334.n3DNYkGU004921@freefall.freebsd.org> Synopsis: [netgraph][pf] kernel panic trap 12 on user connect to VPN server State-Changed-From-To: open->closed State-Changed-By: mlaier State-Changed-When: Mon Apr 13 23:33:36 UTC 2009 State-Changed-Why: Fix commited to head and stable/7. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=130977 From max at love2party.net Tue Apr 14 08:41:59 2009 From: max at love2party.net (Max Laier) Date: Tue Apr 14 09:07:34 2009 Subject: max-src-conn issue In-Reply-To: <49E39547.201@citrin.ru> References: <49E39547.201@citrin.ru> Message-ID: <200904141741.56835.max@love2party.net> Hello Anton, On Monday 13 April 2009 21:40:55 Anton Yuzhaninov wrote: > It seems to be, that max-src-conn is broken under FreeBSD, and not useful > to limit incoming connections. >... > New state not created, but packets matched first rule is passed, while > should be dropped. > > Because of this new half-open connection is created (in SYN_RCVD state). > > This makes max-src-conn not very useful under FreeBSD - bad guys can eat as > many sockets as they want on attacked host, even when number of connections > is limited by pf. > > $ uname -psv > > FreeBSD FreeBSD 8.0-CURRENT #0: Wed Apr 8 05:31:05 MSD 2009 > citrin@citrin.park.rambler.ru:/usr/obj/usr/src/sys/GENERIC amd64 > > I have tested same rules on OpenBSD 4.4 - they works as expected - when > limit reached, packets matched by first rule dropped, and new state not > created. This is indeed a problem in FreeBSD. A workaround solution is to use "synproxy state" instead of a simple "keep state" - this way the connection won't make it through to the final destination and is blocked at the firewall. The fix is a bit intrusive, but I might get to it - could you submit a PR with your analysis, please? Possibly add if the "synproxy state" workaround fixes things for you. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From linimon at FreeBSD.org Tue Apr 14 14:35:11 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Apr 14 15:17:06 2009 Subject: kern/133732: [pf] max-src-conn issue Message-ID: <200904142135.n3ELZAtD025040@freefall.freebsd.org> Synopsis: [pf] max-src-conn issue Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 14 21:35:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133732 From andrew at accid.net Thu Apr 16 06:17:06 2009 From: andrew at accid.net (Andrew Von Cid) Date: Thu Apr 16 06:58:03 2009 Subject: pfctl: Cannot allocate memory. Message-ID: <49E72BCC.9000405@accid.net> Hi, I'm running pf with spamd on 7.0-RELEASE and I'm getting: pfctl: Cannot allocate memory. when I run spamd-setup -b It only happens when the spamd table reaches approx 84530 entries. When I flush the table manually, spamd-setup will work fine for a while (it loaded 75480 entries just now). As far as I understand by default pf can hold up to 200000 entries in a table (please correct me if I'm wrong). I'm nowhere near this. I read somewhere that spamd-setup will load new entries before flushing the old ones so for some time both old and new entries will be held in the table, until the old ones are removed. But even then the table shoudn't hit the size limit. The machine has 4G of RAM, there is usually around 80M free and 56% of swap in use. Is it the lack of free memory that's causing this? If so why wouldn't it use the remaining swap? Many thanks, Andrew. From citrin at citrin.ru Thu Apr 16 07:14:18 2009 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu Apr 16 08:02:28 2009 Subject: pfctl: Cannot allocate memory. In-Reply-To: <49E72BCC.9000405@accid.net> References: <49E72BCC.9000405@accid.net> Message-ID: <49E73D36.4020104@citrin.ru> Andrew Von Cid wrote: > I'm running pf with spamd on 7.0-RELEASE and I'm getting: > > pfctl: Cannot allocate memory. > > when I run spamd-setup -b > > It only happens when the spamd table reaches approx 84530 entries. When > I flush the table manually, spamd-setup will work fine for a while (it > loaded 75480 entries just now). > > As far as I understand by default pf can hold up to 200000 entries in a > table (please correct me if I'm wrong). Better to set this limit explicitly in pf.conf, e. g. set limit table-entries 200000 -- Anton Yuzhaninov From andrew at accid.net Thu Apr 16 09:21:32 2009 From: andrew at accid.net (Andrew Von Cid) Date: Thu Apr 16 09:45:19 2009 Subject: pfctl: Cannot allocate memory. In-Reply-To: <49E73D36.4020104@citrin.ru> References: <49E72BCC.9000405@accid.net> <49E73D36.4020104@citrin.ru> Message-ID: <49E75B09.2000404@accid.net> > Better to set this limit explicitly in pf.conf, e. g. > > set limit table-entries 200000 Thanks Anton, I'll give it a try. Cheers, Andrew. From bugmaster at FreeBSD.org Mon Apr 20 11:06:57 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:08:42 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200904201106.n3KB6ugr033102@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From sebster at sebster.com Thu Apr 23 05:05:58 2009 From: sebster at sebster.com (Sebastiaan van Erk) Date: Thu Apr 23 05:06:05 2009 Subject: "BAD ICMP" message Message-ID: <49EFF732.3010402@sebster.com> Hi, I have the following setup: [openvpn client 10.0.80.150] -> internet -> [vpn server 10.0.80.77] -> internet -> [openvpn client 10.0.80.4] The VPN server has 2 backups with CARP [.76, .75, shared IP .74] though I don't use the CARP failover for their role as VPN server but only for their role as gateway for the 10.0.80.0/24 network. For the VPN I use failover by specifying multiple "remote" lines to their respective external addresses in the openvpn client config. When I try a ssh from 10.0.80.150 to 10.0.80.4 I get to enter my password and sometimes even a few commands, but then pf suddenly starts blocking the connection with the following message: 1. 033789 rule 10/0(match): block in on em1: 10.0.80.150.51422 > 10.0.80.4.22: [|tcp] 2. 079427 rule 10/0(match): block in on em1: 10.0.80.150.51422 > 10.0.80.4.22: [|tcp] 4. 161413 rule 10/0(match): block in on em1: 10.0.80.150.51422 > 10.0.80.4.22: [|tcp] 8. 319210 rule 10/0(match): block in on em1: 10.0.80.150.51422 > 10.0.80.4.22: [|tcp] The 10 rule is the catch-all rule: @10 block drop log all I turned up the debug to load using pfctl -xl and I see these BAD ICMP messages just before the state of the above connection disappears from the state table and the connection gets blocked: Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679 high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0 Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150 state: TCP 10.0.80.4:22 10.0.80.4:22 10.0.80.150:51422 [lo=3150927679 high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] 2:0 seq=3150927679 I see this message several times and the connection no longer works after that. Does anybody know what's going on and how I can fix it? Many thanks, Sebastiaan van Erk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090423/6740f599/smime.bin From max at love2party.net Thu Apr 23 13:59:16 2009 From: max at love2party.net (Max Laier) Date: Thu Apr 23 13:59:23 2009 Subject: "BAD ICMP" message In-Reply-To: <49EFF732.3010402@sebster.com> References: <49EFF732.3010402@sebster.com> Message-ID: <200904231559.13059.max@love2party.net> On Thursday 23 April 2009 07:05:54 Sebastiaan van Erk wrote: > Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP > 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679 > high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] > 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0 > Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150 ^ These are ICMP redirect messages. This clearly suggests that something is very wrong with your routing. I assume your netmasks are wrong. It looks like 10.0.80.77 thinks that 10.0.80.150 can reach 10.0.80.4 directly which is not the case - it needs to route through 10.0.80.77. > state: TCP 10.0.80.4:22 10.0.80.4:22 10.0.80.150:51422 [lo=3150927679 > high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] > 2:0 seq=3150927679 > > I see this message several times and the connection no longer works > after that. > > Does anybody know what's going on and how I can fix it? Use separate ip-ranges on either side of the vpn-router or combine vpn- endpoints from the same subnet in a bridge interface to allow direct communication between all members in one subnet. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From sebster at sebster.com Thu Apr 23 14:37:18 2009 From: sebster at sebster.com (Sebastiaan van Erk) Date: Thu Apr 23 14:37:26 2009 Subject: "BAD ICMP" message In-Reply-To: <200904231559.13059.max@love2party.net> References: <49EFF732.3010402@sebster.com> <200904231559.13059.max@love2party.net> Message-ID: <49F07D1A.9010302@sebster.com> Hi, Thanks for the reply. Actually it is the case that the interface are bridged. Here's a list of the entire setup: em0: flags=8943 metric 0 mtu 1500 options=9b ether 00:0c:29:61:2a:4b inet 111.111.111.111 netmask 0xfffffff0 broadcast 212.61.136.79 media: Ethernet autoselect (1000baseTX ) status: active em1: flags=8943 metric 0 mtu 1500 options=98 ether 00:0c:29:61:2a:55 inet 10.0.80.77 netmask 0xffffff00 broadcast 10.0.80.255 media: Ethernet autoselect (1000baseTX ) status: active em2: flags=8943 metric 0 mtu 1500 options=9b ether 00:0c:29:61:2a:5f inet 10.0.81.77 netmask 0xffffff00 broadcast 10.0.81.255 media: Ethernet autoselect (1000baseTX ) status: active em3: flags=8943 metric 0 mtu 1500 options=9b ether 00:0c:29:61:2a:69 inet 10.0.82.77 netmask 0xffffff00 broadcast 10.0.82.255 media: Ethernet autoselect (1000baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 bridge0: flags=8843 metric 0 mtu 1500 ether f2:f4:c1:45:e7:50 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 2000000 member: em1 flags=143 ifmaxaddr 0 port 2 priority 128 path cost 20000 tap0: flags=8943 metric 0 mtu 1500 ether 00:bd:96:02:00:00 Opened by PID 1310 carp0: flags=49 metric 0 mtu 1500 inet 111.111.111.112 netmask 0xfffffff0 carp: MASTER vhid 1 advbase 1 advskew 0 carp1: flags=49 metric 0 mtu 1500 inet 10.0.80.74 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 0 carp2: flags=49 metric 0 mtu 1500 inet 10.0.81.74 netmask 0xffffff00 carp: MASTER vhid 3 advbase 1 advskew 0 carp3: flags=49 metric 0 mtu 1500 inet 10.0.82.74 netmask 0xffffff00 carp: MASTER vhid 4 advbase 1 advskew 0 pflog0: flags=141 metric 0 mtu 33160 em0 is the external interface, em1 is the vpn interface, and em2 and em3 have production machines on them... The tap0 is the interface used by openvpn. It is bridged in bridge0 to the internal em1 network. Since it is bridged, my feeling says that the two VPN clients (10.0.80.4 and 10.0.80.150) should be able to talk directly to eachother. I have no idea why my linux box (10.0.80.150) thinks it can't directly talk to the other vpn client and talks via the gateway instead. I get a lot of these ICMP redirects on tap0: # tcpdump -ni tap0 icmp tcpdump: WARNING: tap0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes 16:32:51.719979 IP 10.0.80.77 > 10.0.80.150: ICMP redirect 10.0.80.4 to host 10.0.80.4, length 60 I'm sure I'm doing something wrong somewhere, but I can't quite figure it out. Regards, Sebastiaan Max Laier wrote: > On Thursday 23 April 2009 07:05:54 Sebastiaan van Erk wrote: >> Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP >> 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679 >> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] >> 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0 >> Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150 > ^ > > These are ICMP redirect messages. This clearly suggests that something is > very wrong with your routing. I assume your netmasks are wrong. It looks > like 10.0.80.77 thinks that 10.0.80.150 can reach 10.0.80.4 directly which is > not the case - it needs to route through 10.0.80.77. > >> state: TCP 10.0.80.4:22 10.0.80.4:22 10.0.80.150:51422 [lo=3150927679 >> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] >> 2:0 seq=3150927679 >> >> I see this message several times and the connection no longer works >> after that. >> >> Does anybody know what's going on and how I can fix it? > > Use separate ip-ranges on either side of the vpn-router or combine vpn- > endpoints from the same subnet in a bridge interface to allow direct > communication between all members in one subnet. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090423/ecbe0ced/smime.bin From bugmaster at FreeBSD.org Mon Apr 27 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:08:47 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200904271106.n3RB6xMb002376@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From sebster at sebster.com Wed Apr 29 08:49:09 2009 From: sebster at sebster.com (Sebastiaan van Erk) Date: Wed Apr 29 08:49:16 2009 Subject: "BAD ICMP" message In-Reply-To: <49F07D1A.9010302@sebster.com> References: <49EFF732.3010402@sebster.com> <200904231559.13059.max@love2party.net> <49F07D1A.9010302@sebster.com> Message-ID: <49F81481.3020609@sebster.com> Sebastiaan van Erk wrote: > Hi, > > Thanks for the reply. > > Max Laier wrote: >> On Thursday 23 April 2009 07:05:54 Sebastiaan van Erk wrote: >>> Apr 23 06:58:38 vpn3 kernel: pf: loose state match: TCP >>> 10.0.80.150:51422 10.0.80.150:51422 10.0.80.4:22 [lo=3150927679 >>> high=3150923785 win=692 modulator=0] [lo=0 high=692 win=1 modulator=0] >>> 2:0 A seq=3150927679 (3150927679) ack=0 len=0 ackskew=0 pkts=77:0 >>> Apr 23 06:58:38 vpn3 kernel: pf: BAD ICMP 5:1 10.0.80.77 -> 10.0.80.150 >> ^ >> >> These are ICMP redirect messages. This clearly suggests that >> something is very wrong with your routing. I assume your netmasks are >> wrong. It looks like 10.0.80.77 thinks that 10.0.80.150 can reach >> 10.0.80.4 directly which is not the case - it needs to route through >> 10.0.80.77. Actually, I finally figured out what was wrong. I accidentally told OpenVPN to "push 10.0.80.0/24 10.0.80.77", in other words, the client machine 10.0.80.150 tried to route though 10.0.80.77 even though it can reach it directly (since it's a bridged network). After removing the offending line, everything works. Something was definitely wrong with the routing though. :-) Regards, Sebastiaan > Here's a list of the entire setup: > > em0: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:4b > inet 111.111.111.111 netmask 0xfffffff0 broadcast 212.61.136.79 > media: Ethernet autoselect (1000baseTX ) > status: active > em1: flags=8943 metric 0 > mtu 1500 > options=98 > ether 00:0c:29:61:2a:55 > inet 10.0.80.77 netmask 0xffffff00 broadcast 10.0.80.255 > media: Ethernet autoselect (1000baseTX ) > status: active > em2: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:5f > inet 10.0.81.77 netmask 0xffffff00 broadcast 10.0.81.255 > media: Ethernet autoselect (1000baseTX ) > status: active > em3: flags=8943 metric 0 > mtu 1500 > options=9b > ether 00:0c:29:61:2a:69 > inet 10.0.82.77 netmask 0xffffff00 broadcast 10.0.82.255 > media: Ethernet autoselect (1000baseTX ) > status: active > plip0: flags=108810 metric 0 > mtu 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > bridge0: flags=8843 metric 0 mtu > 1500 > ether f2:f4:c1:45:e7:50 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 9 priority 128 path cost 2000000 > member: em1 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 20000 > tap0: flags=8943 metric > 0 mtu 1500 > ether 00:bd:96:02:00:00 > Opened by PID 1310 > carp0: flags=49 metric 0 mtu 1500 > inet 111.111.111.112 netmask 0xfffffff0 > carp: MASTER vhid 1 advbase 1 advskew 0 > carp1: flags=49 metric 0 mtu 1500 > inet 10.0.80.74 netmask 0xffffff00 > carp: MASTER vhid 2 advbase 1 advskew 0 > carp2: flags=49 metric 0 mtu 1500 > inet 10.0.81.74 netmask 0xffffff00 > carp: MASTER vhid 3 advbase 1 advskew 0 > carp3: flags=49 metric 0 mtu 1500 > inet 10.0.82.74 netmask 0xffffff00 > carp: MASTER vhid 4 advbase 1 advskew 0 > pflog0: flags=141 metric 0 mtu 33160 > > em0 is the external interface, em1 is the vpn interface, and em2 and em3 > have production machines on them... > > The tap0 is the interface used by openvpn. It is bridged in bridge0 to > the internal em1 network. Since it is bridged, my feeling says that the > two VPN clients (10.0.80.4 and 10.0.80.150) should be able to talk > directly to eachother. I have no idea why my linux box (10.0.80.150) > thinks it can't directly talk to the other vpn client and talks via the > gateway instead. I get a lot of these ICMP redirects on tap0: > > # tcpdump -ni tap0 icmp > tcpdump: WARNING: tap0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes > 16:32:51.719979 IP 10.0.80.77 > 10.0.80.150: ICMP redirect 10.0.80.4 to > host 10.0.80.4, length 60 > > I'm sure I'm doing something wrong somewhere, but I can't quite figure > it out. > > Regards, > Sebastiaan > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3328 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090429/8e6f8472/smime.bin