From tt-list at simplenet.com Thu Jul 2 21:27:45 2009 From: tt-list at simplenet.com (Tim Traver) Date: Thu Jul 2 21:27:51 2009 Subject: Extremely simple redirect rule doesnt appear to be working Message-ID: <4A4D2010.4020908@simplenet.com> Hi all, ok, I'm a little new to messing around with pf, but have come up for a need that it sounds like it should be able to solve. I want to be able to redirect outgoing http requests from the box back to local addresses on the box... In reading up, it appears that the redirect config line should do that, and in testing, I have a simple line like this in the pf.conf rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal address here] port 80 now, I haven't made that internal address be an address on the local box yet, cause I'm testing to see how this works... I can manually telnet to [internal address here] port 80 with no problems and get the apache greeting. Once I turn on and load the pf.conf file (with pfctl -F all -f /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic www.yahoo.com), I don't get redirected to the internal address port 80 and get the apache greeting that is expected... I did turn on port forwarding as per the instructions for NAT, although it didn't say if it was needed for rdr. net.inet.ip.forwarding=1 in netstat, I see it trying to actually reach the ouside IP, which it cant, so the translation didn't appear to take affect... am I missing something ? Thanks, Tim. From repcsike at gmail.com Fri Jul 3 10:13:03 2009 From: repcsike at gmail.com (=?ISO-8859-1?B?QmFs4XpzIE3hdOlmZnk=?=) Date: Fri Jul 3 10:13:21 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A4D2010.4020908@simplenet.com> References: <4A4D2010.4020908@simplenet.com> Message-ID: Hi there, I think you should check pfctl -sr and pfctl -sn that your rules are ok, and you don't deny that traffic explicitly. However, I don't want to start a war, but on a machine I experienced that with FreeBSD 7.0 or 7.1 the pf redirections didn't work, after a minor release update, the problem went away with the same ruleset! (I think it was 7.0 and updated to 7.1 to get it working again) But rdr pass should add the permitting access rule for your redirection entry. Maybe logging can help you too: http://www.openbsd.org/faq/pf/logging.html Hope this helps! Best Regards, MB. 2009/7/2 Tim Traver > Hi all, > > ok, I'm a little new to messing around with pf, but have come up for a need > that it sounds like it should be able to solve. > > I want to be able to redirect outgoing http requests from the box back to > local addresses on the box... > > In reading up, it appears that the redirect config line should do that, and > in testing, I have a simple line like this in the pf.conf > > rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal > address here] port 80 > > now, I haven't made that internal address be an address on the local box > yet, cause I'm testing to see how this works... > > I can manually telnet to [internal address here] port 80 with no problems > and get the apache greeting. > > Once I turn on and load the pf.conf file (with pfctl -F all -f > /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic > www.yahoo.com), I don't get redirected to the internal address port 80 and > get the apache greeting that is expected... > > I did turn on port forwarding as per the instructions for NAT, although it > didn't say if it was needed for rdr. > > net.inet.ip.forwarding=1 > > in netstat, I see it trying to actually reach the ouside IP, which it cant, > so the translation didn't appear to take affect... > > am I missing something ? > > Thanks, > > Tim. > > _______________________________________________ > 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 dimitry at andric.com Fri Jul 3 10:46:53 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Jul 3 10:47:00 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A4D2010.4020908@simplenet.com> References: <4A4D2010.4020908@simplenet.com> Message-ID: <4A4DE199.4010701@andric.com> On 2009-07-02 23:01, Tim Traver wrote: > In reading up, it appears that the redirect config line should do that, > and in testing, I have a simple line like this in the pf.conf > > rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal > address here] port 80 > > now, I haven't made that internal address be an address on the local box > yet, cause I'm testing to see how this works... > > I can manually telnet to [internal address here] port 80 with no > problems and get the apache greeting. > > Once I turn on and load the pf.conf file (with pfctl -F all -f > /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic > www.yahoo.com), I don't get redirected to the internal address port 80 > and get the apache greeting that is expected... Please post your pf.conf, or it will rather difficult to see what is wrong. From artemrts at ukr.net Fri Jul 3 11:53:03 2009 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Fri Jul 3 11:53:10 2009 Subject: ALTQ traffic shaping problem Message-ID: ? Hi, All! ?I have installed FreeBSD 7.2 with pf as firewall and NAT with ALTQ for traffic shaping. This is my test system on VMWare. ?Below my pf.conf. All works perfectly except, shaping. ?I want limit outbound (128Kb) and inbound (800Kb) traffic to and from Internet for two computers. I have configured queues on interfaces as is write below. But in real I have only half of specified speed in pf.conf. ? ext_if="le0" int_if="le1" lan="172.16.1.0/24" pc1="172.16.1.2" pc2="172.16.1.3" set skip on lo set loginterface le1 set ruleset-optimization basic set block-policy return set state-policy if-bound scrub on $int_if all random-id reassemble tcp fragment reassemble scrub on $ext_if all random-id reassemble tcp fragment reassemble ### ALTQ altq on $int_if cbq bandwidth 100Mb queue { def_download, pc1_download, pc2_download } queue def_download bandwidth 50% cbq(default) queue pc1_download bandwidth 800Kb cbq(red) queue pc2_download bandwidth 800Kb cbq(red) altq on $ext_if cbq bandwidth 10Mb queue {def_upload, pc1_upload, pc2_upload } queue def_upload bandwidth 50% cbq(default) queue pc1_upload bandwidth 128Kb cbq(red) queue pc2_upload bandwidth 128Kb cbq(red) ##### NAT nat on $ext_if from $lan to !$int_if -> $ext_if ### #pass in #pass out block in block out antispoof quick for { lo $int_if } inet #### EXT_IF_OUT pass out quick on $ext_if inet tagged from_pc1 queue pc1_upload pass out quick on $ext_if inet tagged from_pc2 queue pc1_upload pass out quick on $ext_if inet tagged from_def queue def_upload pass out quick on $ext_if inet from $ext_if to any #### EXT_IF_IN pass in quick on $ext_if inet proto tcp from any to $ext_if port ssh #### INT_IF_IN pass in quick on $int_if inet from $pc1 to !$int_if tag from_pc1 queue pc1_download pass in quick on $int_if inet from $pc1 to !$int_if tag from_pc2 queue pc2_download pass in quick on $int_if inet from !$pc1 to !$int_if tag from_def queue def_download pass in quick on $int_if inet proto {tcp udp} from $lan to $int_if port 53 ### INT_IF_OUT ######################### THE END ?? So, where is my mistake? Very much I hope for your help. ?? ?Thanks. From budiyt at gmail.com Fri Jul 3 17:24:49 2009 From: budiyt at gmail.com (budsz) Date: Fri Jul 3 17:24:55 2009 Subject: Problem PF and HFSC Message-ID: <4d4dc3640907030951g627f096fv16e0b3ac58e9765@mail.gmail.com> Hello, I try to use PF under FreeBSD 7.2-STABLE. Here my config file: # Variable global ifint0="rl0" ifext0="rl1" ipcl = "{ 192.168.100.1, 192.168.100.2, 192.168.100.3, 192.168.100.4, 192.168.100.5, \ 192.168.100.6, 192.168.100.7, 192.168.100.8, 192.168.100.11, 192.168.100.12, \ 192.168.100.100 }" ipunlimit = "{ !192.168.1.0/30, !192.168.100.200 }" scrub in all altq on $ifint0 hfsc bandwidth 1Mb queue { downstream } queue downstream bandwidth 10% priority 0 hfsc (upperlimit 99% default) altq on $ifext0 hfsc bandwidth 256Kb queue { upstream } queue upstream bandwidth 10% priority 0 hfsc (upperlimit 99% default) # Outgoing traffic (Downstream banwidth) pass out quick on $ifint0 from $ipunlimit to $ipcl queue (downstream) # Incoming traffic (Upstream bandwidth) pass out quick on $ifext0 from $ipcl to $ipunlimit queue (upstream) This several my problem after I tested: 1. Why PF can't limit incoming traffic in one interface. Let's say on rl0: pass out quick on $ifint0 from $ipunlimit to $ipcl queue (downstream) pass in quick on $ifint0 from $ipcl to $ipunlimit queue (upstream) 2. For list $ipunlimit (192.168.1.0/30 and 192.168.100.200 ) still get limit. I wanna traffic from/to (192.168.1.0/30 and 192.168.100.200 ) to/from pccl _not_ limit, because that's for www/ssh local LAN. 3. I need suggestion for that rule. My purpose is link share for 11 IP address (downstream/upstream), so if saturate traffic reached. The clients still get guaranty with 10% of total bandwidth (About 100KB downstream and 253.44Kb upstream for each other). Thanks for your time. -- budsz From plaxo at mx.plaxo.com Fri Jul 3 20:16:36 2009 From: plaxo at mx.plaxo.com (Jean Dupre) Date: Fri Jul 3 20:17:27 2009 Subject: =?utf-8?q?Jean_Dupre_a_partag=C3=A9_un_message_avec_vous_sur_Pul?= =?utf-8?q?se?= Message-ID: <42cc7405fbeec038d5a25a804c1fd43e@xpertmailer.com> Jean Dupre a partagé un message avec vous sur Pulse et souhaitait vous le faire savoir. http://www.plaxo.com/public/event/189178955319?src=email&et=6&el=fr_o1&key=70634ecb3f154d61ab941ea5fed30e573283e72f&email=freebsd-pf%40freebsd.org&share_id=4662476&share_key=1951352105&name=&webmailfix=1&lang=fr Besoin de prêt ? Bonjour, Je suis DUPRE JEAN ALBERT. Ancien thérapeute, financier suisse et Directeur d’étude de projets dans une banque. J'octroie des prêts à toute personne désireuse selon les critères suivants: Choix du montant : à partir de 15.000 € Choix de la durée de remboursement : 8 ans maximum TEG annuel fixe : 2,15%* (*offre soumise à condition) En option : l’assurance e... http://www.plaxo.com/public/event/189178955319?src=email&et=6&el=fr_o1&key=70634ecb3f154d61ab941ea5fed30e573283e72f&email=freebsd-pf%40freebsd.org&share_id=4662476&share_key=1951352105&name=&webmailfix=1&lang=fr Merci ! L'équipe Plaxo Plus de 20 millions de personnes utilisent Plaxo pour rester en contact avec leur entourage dans le cadre privé comme professionnel. Vous ne voulez plus recevoir d'e-mails de Plaxo ? Rendez-vous sur : http://www.plaxo.com/stop?src=email&et=6&el=fr_o1&email=freebsd-pf%40freebsd.org From tt-list at simplenet.com Sat Jul 4 07:48:32 2009 From: tt-list at simplenet.com (Tim Traver) Date: Sat Jul 4 07:48:40 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: References: <4A4D2010.4020908@simplenet.com> Message-ID: <4A4F0950.7020005@simplenet.com> Thank you for your response. My rules are ok, because I have no other rules than that one, and I ran the syntax checker on it... I am indeed running 7.0, so I guess I could update the sources on that machine to 7.1 and rebuild pf. Thanks, Tim. Bal?zs M?t?ffy wrote: > Hi there, > > I think you should check pfctl -sr and pfctl -sn that your rules are ok, and > you don't deny that traffic explicitly. > > However, I don't want to start a war, but on a machine I experienced that > with FreeBSD 7.0 or 7.1 the pf redirections didn't work, after a minor > release update, the problem went away with the same ruleset! (I think it was > 7.0 and updated to 7.1 to get it working again) > > But rdr pass should add the permitting access rule for your redirection > entry. > > Maybe logging can help you too: http://www.openbsd.org/faq/pf/logging.html > > Hope this helps! > > Best Regards, > > MB. > > > 2009/7/2 Tim Traver > > >> Hi all, >> >> ok, I'm a little new to messing around with pf, but have come up for a need >> that it sounds like it should be able to solve. >> >> I want to be able to redirect outgoing http requests from the box back to >> local addresses on the box... >> >> In reading up, it appears that the redirect config line should do that, and >> in testing, I have a simple line like this in the pf.conf >> >> rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal >> address here] port 80 >> >> now, I haven't made that internal address be an address on the local box >> yet, cause I'm testing to see how this works... >> >> I can manually telnet to [internal address here] port 80 with no problems >> and get the apache greeting. >> >> Once I turn on and load the pf.conf file (with pfctl -F all -f >> /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic >> www.yahoo.com), I don't get redirected to the internal address port 80 and >> get the apache greeting that is expected... >> >> I did turn on port forwarding as per the instructions for NAT, although it >> didn't say if it was needed for rdr. >> >> net.inet.ip.forwarding=1 >> >> in netstat, I see it trying to actually reach the ouside IP, which it cant, >> so the translation didn't appear to take affect... >> >> am I missing something ? >> >> Thanks, >> >> Tim. >> >> _______________________________________________ >> 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-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 tt-list at simplenet.com Sat Jul 4 07:49:37 2009 From: tt-list at simplenet.com (Tim Traver) Date: Sat Jul 4 07:49:43 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A4DE199.4010701@andric.com> References: <4A4D2010.4020908@simplenet.com> <4A4DE199.4010701@andric.com> Message-ID: <4A4F0992.8090906@simplenet.com> Dimitry Andric wrote: > On 2009-07-02 23:01, Tim Traver wrote: > >> In reading up, it appears that the redirect config line should do that, >> and in testing, I have a simple line like this in the pf.conf >> >> rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal >> address here] port 80 >> >> now, I haven't made that internal address be an address on the local box >> yet, cause I'm testing to see how this works... >> >> I can manually telnet to [internal address here] port 80 with no >> problems and get the apache greeting. >> >> Once I turn on and load the pf.conf file (with pfctl -F all -f >> /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic >> www.yahoo.com), I don't get redirected to the internal address port 80 >> and get the apache greeting that is expected... >> > > Please post your pf.conf, or it will rather difficult to see what is > wrong. > Dmitry, I appreciate your post, but my pf.conf file only consists of the rule that I have stated for the redirect. I have no other filtering going on... Thanks, Tim. From cbuechler at gmail.com Sat Jul 4 14:05:44 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Sat Jul 4 14:05:49 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A4F0950.7020005@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> Message-ID: On Sat, Jul 4, 2009 at 3:48 AM, Tim Traver wrote: > Thank you for your response. > > My rules are ok, because I have no other rules than that one, and I ran the > syntax checker on it... > > I am indeed running 7.0, so I guess I could update the sources on that > machine to 7.1 and rebuild pf. > rdr works fine in 7.0 and 7.1 and 7.2 and every other version since pf has been in FreeBSD. The person who claimed it didn't work in some version is wrong. I suspect you're testing from inside your network, which won't work. Test from outside. From tt-list at simplenet.com Mon Jul 6 05:28:10 2009 From: tt-list at simplenet.com (Tim Traver) Date: Mon Jul 6 05:28:16 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> Message-ID: <4A518B6B.1010407@simplenet.com> Chris Buechler wrote: > > rdr works fine in 7.0 and 7.1 and 7.2 and every other version since pf > has been in FreeBSD. The person who claimed it didn't work in some > version is wrong. I suspect you're testing from inside your network, > which won't work. Test from outside. > _______________________________________________ > Chris, Thanks for responding. I am indeed testing this from within the same machine, as I need the redirection to take place when attempting to make requests FROM the machine to an outside source. Is there not a way to do that with pf ??? Thanks, Tim. From cbuechler at gmail.com Mon Jul 6 05:37:57 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Mon Jul 6 05:38:04 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A518B6B.1010407@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> Message-ID: On Mon, Jul 6, 2009 at 1:28 AM, Tim Traver wrote: > > Thanks for responding. I am indeed testing this from within the same > machine, as I need the redirection to take place when attempting to make > requests FROM the machine to an outside source. > > Is there not a way to do that with pf ??? > There are multiple options, see: http://www.openbsd.org/faq/pf/rdr.html From tt-list at simplenet.com Mon Jul 6 05:43:33 2009 From: tt-list at simplenet.com (Tim Traver) Date: Mon Jul 6 05:43:40 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> Message-ID: <4A518F07.1070209@simplenet.com> Chris Buechler wrote: > On Mon, Jul 6, 2009 at 1:28 AM, Tim Traver wrote: > >> Thanks for responding. I am indeed testing this from within the same >> machine, as I need the redirection to take place when attempting to make >> requests FROM the machine to an outside source. >> >> Is there not a way to do that with pf ??? >> >> > > There are multiple options, see: > http://www.openbsd.org/faq/pf/rdr.html > Chris, yes, that is where I originally got all of the information, and made my original post with my redirection line in the pf.conf that does not appear to be doing anything. I couldn't figure out why, hence the post here. Here is a copy of the original post if you think you might have any insight... Hi all, ok, I'm a little new to messing around with pf, but have come up for a need that it sounds like it should be able to solve. I want to be able to redirect outgoing http requests from the box back to local addresses on the box... In reading up, it appears that the redirect config line should do that, and in testing, I have a simple line like this in the pf.conf rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> [internal address here] port 80 now, I haven't made that internal address be an address on the local box yet, cause I'm testing to see how this works... I can manually telnet to [internal address here] port 80 with no problems and get the apache greeting. Once I turn on and load the pf.conf file (with pfctl -F all -f /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic www.yahoo.com), I don't get redirected to the internal address port 80 and get the apache greeting that is expected... I did turn on port forwarding as per the instructions for NAT, although it didn't say if it was needed for rdr. net.inet.ip.forwarding=1 in netstat, I see it trying to actually reach the ouside IP, which it cant, so the translation didn't appear to take affect... am I missing something ? Thanks, Tim. From cbuechler at gmail.com Mon Jul 6 05:54:26 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Mon Jul 6 05:54:32 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A518F07.1070209@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> <4A518F07.1070209@simplenet.com> Message-ID: On Mon, Jul 6, 2009 at 1:43 AM, Tim Traver wrote: > > > > yes, that is where I originally got all of the information, and made my > original post with my redirection line in the pf.conf that does not appear > to be doing anything. Then you didn't read the bottom of that page. What you're missing is "Redirection and Reflection". http://www.openbsd.org/faq/pf/rdr.html#reflect From rmaglasang at infoweapons.com Mon Jul 6 06:20:59 2009 From: rmaglasang at infoweapons.com (Ronnel P. Maglasang) Date: Mon Jul 6 06:21:06 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A518F07.1070209@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> <4A518F07.1070209@simplenet.com> Message-ID: <4A5190C1.2060205@infoweapons.com> Tim Traver wrote: > > > Chris Buechler wrote: >> On Mon, Jul 6, 2009 at 1:28 AM, Tim Traver wrote: >> >>> Thanks for responding. I am indeed testing this from within the same >>> machine, as I need the redirection to take place when attempting to >>> make >>> requests FROM the machine to an outside source. >>> >>> Is there not a way to do that with pf ??? >>> >>> >> >> There are multiple options, see: >> http://www.openbsd.org/faq/pf/rdr.html >> > > Chris, > > yes, that is where I originally got all of the information, and made > my original post with my redirection line in the pf.conf that does not > appear to be doing anything. I couldn't figure out why, hence the post > here. > > Here is a copy of the original post if you think you might have any > insight... > > Hi all, > > ok, I'm a little new to messing around with pf, but have come up for a > need that it sounds like it should be able to solve. > > I want to be able to redirect outgoing http requests from the box back > to local addresses on the box... > > In reading up, it appears that the redirect config line should do > that, and in testing, I have a simple line like this in the pf.conf > > rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> > [internal address here] port 80 > > now, I haven't made that internal address be an address on the local > box yet, cause I'm testing to see how this works... > > I can manually telnet to [internal address here] port 80 with no > problems and get the apache greeting. > > Once I turn on and load the pf.conf file (with pfctl -F all -f > /etc/pf.conf), and I try to telnet to 209.131.36.158 port 80 (generic > www.yahoo.com), I don't get redirected to the internal address port 80 > and get the apache greeting that is expected... > > I did turn on port forwarding as per the instructions for NAT, > although it didn't say if it was needed for rdr. > > net.inet.ip.forwarding=1 > > in netstat, I see it trying to actually reach the ouside IP, which it > cant, so the translation didn't appear to take affect... > > am I missing something ? > Yes, I believe so. rdr works only for incoming traffic. To redirect outgoing traffic locally you need to re-route the traffic using the route-to option. Try these rules. -- rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> port 80 pass out log quick on lo0 no state pass in log quick on lo0 no state pass out quick on route-to (lo0 ) inet proto tcp from any to 209.131.36.158 port 80 keep state -- > Thanks, > > Tim. > > > _______________________________________________ > 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 greenx at yartv.ru Mon Jul 6 08:15:05 2009 From: greenx at yartv.ru (Andrey Groshev) Date: Mon Jul 6 08:15:11 2009 Subject: tftp-proxy don't work Message-ID: <4A51B0A2.5060208@yartv.ru> Hi, Today there was a need to have tftp-proxy, but I found that it does not work. It was this way: Jul 6 10:53:27 vakhtyor tftp-proxy [47783]: pf connection lookup failed (no rdr?) Jul 6 10:53:27 vakhtyor inetd [47778]: / usr / libexec / tftp-proxy [47783]: exited, status 1 After that I looked the source code, and found the error: tftp-proxy trying to find is state connection to him and did not find it, because not correctly sets the protocol: server_lookup4 (struct sockaddr_in * client, struct sockaddr_in * proxy, struct sockaddr_in * server) ( ..... --> pnl.proto = IPPROTO_TCP; ..... After that I started looking for where the legs grow and discovered that it corrected openbsd (added argument function proto). It may be to synchronize the source code? Best regards, Andrey Groshev From bugmaster at FreeBSD.org Mon Jul 6 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:09:08 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200907061107.n66B73X3010878@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/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w 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 34 problems total. From gdakos at enovation.gr Tue Jul 7 08:43:07 2009 From: gdakos at enovation.gr (John Dakos [ Enovation Technologies ]) Date: Tue Jul 7 08:43:15 2009 Subject: Simple Config PF Message-ID: Hello All, I m newbie on PF I want a simple pf.conf, I have one NIC I want filtered ports 21,22,25,80,110, 53 DNS and Samba, and all other ports to be closed. Is any one to have this config? Thanks John Dakos Network Administrator Enovation Technologies Filellinon 35, Chalandrion 15232 Athens, GREECE Tel: +30-210 8119784 Mob: +30-6979348082 From Greg.Hennessy at nviz.net Tue Jul 7 09:02:16 2009 From: Greg.Hennessy at nviz.net (Greg Hennessy) Date: Tue Jul 7 09:02:24 2009 Subject: Simple Config PF In-Reply-To: References: Message-ID: <6CE8D2A5CE118747811E51143A68BA0A72F4406606@PEMEXMBXVS01.jellyfishnet.co.uk.local> http://www.openbsd.org/faq/pf/index.html will teach you everything you need to know. -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of John Dakos [ Enovation Technologies ] Sent: 07 July 2009 09:30 To: freebsd-pf@freebsd.org Subject: Simple Config PF Hello All, I m newbie on PF I want a simple pf.conf, I have one NIC I want filtered ports 21,22,25,80,110, 53 DNS and Samba, and all other ports to be closed. Is any one to have this config? Thanks John Dakos Network Administrator Enovation Technologies Filellinon 35, Chalandrion 15232 Athens, GREECE Tel: +30-210 8119784 Mob: +30-6979348082 _______________________________________________ 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" __________ Information from ESET NOD32 Antivirus, version of virus signature database 4219 (20090705) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From valentin.bud at gmail.com Tue Jul 7 09:26:38 2009 From: valentin.bud at gmail.com (Valentin Bud) Date: Tue Jul 7 09:26:45 2009 Subject: Simple Config PF In-Reply-To: References: Message-ID: <139b44430907070153o12a1da1dx39fb67292743016c@mail.gmail.com> On Tue, Jul 7, 2009 at 11:30 AM, John Dakos [ Enovation Technologies ] < gdakos@enovation.gr> wrote: > > > Hello All, I m newbie on PF > > > > I want a simple pf.conf, I have one NIC > > > > I want filtered ports 21,22,25,80,110, 53 DNS and Samba, and all other > ports to be closed. > > > > Is any one to have this config? > > > > Thanks Hello Mr. John, The pf FAQ should be a good place to start. http://openbsd.org/faq/pf/index.html Blindly copying some rules written here by some person be them good will not make you understand how pf works and how to debug and use in the future. Another must have resource regarding PF is "The book of PF" by Peter N. M. Hansteen. And to quote him: "The Pledge of the Network Admin This is my network. It is mine, or technically, my employer's; it is my responsibility, and I care for it with all my heart. There are many other networks a lot like mine, but none are just like it. I solemnly swear that I will not mindlessly paste from HOWTOs." I don't want to be rude with you, I (as well as many others) could provide a simple ruleset but that would break "Your Pledge" as a Network Admin and plus the knowledge you'll gain by learning pf will be of use in the future. a great day, v -- network warrior since 2005 From v.prokofyev at gmail.com Wed Jul 8 00:52:40 2009 From: v.prokofyev at gmail.com (Prokofyev Vladislav) Date: Wed Jul 8 00:52:46 2009 Subject: Simple Config PF In-Reply-To: <139b44430907070153o12a1da1dx39fb67292743016c@mail.gmail.com> References: <139b44430907070153o12a1da1dx39fb67292743016c@mail.gmail.com> Message-ID: <46dcef4e0907071752y868f57s162b4026d26475f9@mail.gmail.com> 2009/7/7 Valentin Bud > "The Pledge of the Network Admin > This is my network. > It is mine, > or technically, my employer's; > it is my responsibility, > and I care for it with all my heart. > There are many other networks a lot like mine, > but none are just like it. > I solemnly swear > that I will not mindlessly paste from HOWTOs." > > Sounds like devotion to a rifle in "Full Metal Jacket" by Stanley Kubrick :) Thanks for this quote, will keep in mind it. -- With best regards, Vladislav Prokofyev From tt-list at simplenet.com Sat Jul 11 06:06:28 2009 From: tt-list at simplenet.com (Tim Traver) Date: Sat Jul 11 06:06:34 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A5190C1.2060205@infoweapons.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> <4A518F07.1070209@simplenet.com> <4A5190C1.2060205@infoweapons.com> Message-ID: <4A582BE5.8020300@simplenet.com> >> >> am I missing something ? >> > Yes, I believe so. > > rdr works only for incoming traffic. To redirect outgoing traffic > locally you > need to re-route the traffic using the route-to option. > > Try these rules. > > -- > rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> > port 80 > pass out log quick on lo0 no state > pass in log quick on lo0 no state > > pass out quick on route-to (lo0 ) > inet proto tcp from any to 209.131.36.158 port 80 keep state > -- > Hmmm...I tried that configuration, but it still doesn't seem to produce anything : here is the exact config that I am using based on your statements : rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> 209.132.4.203 port 80 pass out log quick on lo0 no state pass in log quick on lo0 no state pass out quick on fxp0 route-to 127.0.0.1 inet proto tcp from any to 209.131.36.158 port 80 keep state when I reload pf, it looks like the rules and nat stuff is indeed in place, but I get nothing when I attempt from the command line to telnet to 209.131.36.158 on port 80 I was expecting it to get answered on the local 127.0.0.1 port 80 which is indeed responding... any other ideas on how to accomplish this? Once again, I'm trying to make it so that any calls out from this box to certain IP's get redirected to a local IP on the box, so it never actually leaves the server... Thanks, Tim. From rascal1981 at gmail.com Sat Jul 11 18:09:33 2009 From: rascal1981 at gmail.com (rascal) Date: Sat Jul 11 18:09:41 2009 Subject: pfsync question Message-ID: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> Hello all, I have a question regarding pfsync and configuring it. I guess the first thing I need to make sure of is that I understand it's functionality. As I understand it pfsync is used to sync the state tables and the pf.conf file between two firewalls setup with pfsync/pf/carp. So I have setup two firewalls in a test environment with the following configurations (on both firewalls, em0 is the primary interface, em2 is the heartbeat/crossover connection between the two firewalls and carp0 has a VIP assigned to it): *firewall 1 rc.conf* # -- sysinstall generated deltas -- # Tue Jun 30 12:57:37 2009 # Created: Tue Jun 30 12:57:37 2009 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. sshd_enable="YES" pf_enable="YES" pf_rules="/etc/pf.conf" pf_flags="" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags="" gateway_enable="YES" pfsync_enable="YES" pfsync_syncdev="em2" defaultrouter="10.222.5.1" hostname="firewall1" network_interfaces="em0 em1 em2 lo0 pfsync0" cloned_interfaces="carp0" ifconfig_em0="inet 10.222.5.159 netmask 255.255.255.0" ifconfig_em2="192.168.0.1 netmask 0xffffff00" ifconfig_carp0="advskew 200 vhid 1 pass blah 10.222.5.164 netmask 255.255.255.0" ifconfig_pfsync0="up syncif em2" *pf.conf* ##### increase limit on states ##### set limit { states 100000, frags 5000 } ##### set our macros ##### #### testing the sync### ext_if="em0" int_if="em1" sync_if="em2" ###### Network Infrastructure ###### infrastructure_ip="{bunch of ips}" scrub in all pass quick on $sync_if proto pfsync keep state pass on { $ext_if, $sync_if } proto carp keep state #pass on $sync_if proto pfsync #pass quick on { em2 } proto pfsync keep state #pass on { em0 em1 } proto carp keep state *ifconfig output* em0: flags=8943 metric 0 mtu 1500 options=9b ether 00:c0:9f:3d:b9:ad inet 10.222.5.159 netmask 0xffffff00 broadcast 10.222.5.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 metric 0 mtu 1500 options=9b ether 00:c0:9f:3d:b9:ae media: Ethernet autoselect status: no carrier em2: flags=8843 metric 0 mtu 1500 options=9b ether 00:04:23:d6:df:16 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active em3: flags=8802 metric 0 mtu 1500 options=9b ether 00:04:23:d6:df:17 media: Ethernet autoselect status: no carrier pflog0: flags=141 metric 0 mtu 33204 pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: em2 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 carp0: flags=49 metric 0 mtu 1500 inet 10.222.5.164 netmask 0xffffff00 carp: MASTER vhid 1 advbase 1 advskew 200 *pfctl -vvss output* No ALTQ support in kernel ALTQ related functions disabled all pfsync 192.168.0.1 -> 224.0.0.240 SINGLE:NO_TRAFFIC age 10:22:46, expires in 00:00:28, 20964:0 pkts, 2683640:0 bytes id: 4a582b5900000000 creatorid: 1801692c (no-sync) all carp 10.222.5.159 -> 224.0.0.18 SINGLE:NO_TRAFFIC age 10:22:46, expires in 00:00:29, 20957:0 pkts, 1173592:0 bytes id: 4a582b5900000002 creatorid: 1801692c all pfsync 224.0.0.240 <- 192.168.0.2 NO_TRAFFIC:SINGLE age 10:05:54, expires in 00:00:28, 20393:0 pkts, 2610328:0 bytes id: 4a582b5900000003 creatorid: 1801692c (no-sync) all carp 224.0.0.18 <- 10.222.5.159 NO_TRAFFIC:SINGLE age 10:05:25, expires in 00:00:28, 0:0 pkts, 0:0 bytes id: 4a582cf200000004 creatorid: 3b64bdb5 *pftop output* pfTop: Up State 1-4/4, View: default, Order: none, Cache: 10000 12:27:19 PR DIR SRC DEST STATE AGE EXP PKTS BYTES pfsync Out 192.168.0.1:0 224.0.0.240:0 SINGLE:NO_TRAFFIC 10:23:05 00:00:29 20975 2685048 carp Out 10.222.5.159:0 224.0.0.18:0 SINGLE:NO_TRAFFIC 10:23:05 00:00:30 20968 1174208 pfsync In 192.168.0.2:0 224.0.0.240:0 NO_TRAFFIC:SINGLE 10:06:13 00:00:29 20404 2611736 carp In 10.222.5.159:0 224.0.0.18:0 NO_TRAFFIC:SINGLE 10:05:44 00:00:29 0 0 *Firewall 2 rc.conf* # -- sysinstall generated deltas -- # Tue Jun 30 13:09:12 2009 # Created: Tue Jun 30 13:09:12 2009 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. sshd_enable="YES" pf_enable="YES" pf_rules="/etc/pf.conf" pf_flags="" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags="" gateway_enable="YES" pfsync_enable="YES" pfsync_syncdev="em2" defaultrouter="10.222.5.1" hostname="firewall2" network_interfaces="em0 em1 em2 lo0 pfsync0" cloned_interfaces="carp0" ifconfig_em0="inet 10.222.5.160 netmask 255.255.255.0" ifconfig_em2="192.168.0.2 netmask 0xffffff00" ifconfig_carp0="advskew 202 vhid 1 pass blah 10.222.5.164 netmask 255.255.255.0" ifconfig_pfsync0="up syncif em2" *pf.conf* ##### increase limit on states ##### set limit { states 100000, frags 5000 } ##### set our macros ##### #### testing the sync### ext_if="em0" int_if="em1" sync_if="em2" ###### Network Infrastructure ###### infrastructure_ip="{ bunch of ips }" pass quick on $sync_if proto pfsync keep state pass on { $ext_if, $sync_if } proto carp keep state #pass on $sync_if proto pfsync #pass quick on { em2 } proto pfsync keep state #pass on { em0 em1 } proto carp keep state *ifconfig output* em0: flags=8943 metric 0 mtu 1500 options=9b ether 00:c0:9f:3e:23:9d inet 10.222.5.160 netmask 0xffffff00 broadcast 10.222.5.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 metric 0 mtu 1500 options=9b ether 00:c0:9f:3e:23:9e media: Ethernet autoselect status: no carrier em2: flags=8843 metric 0 mtu 1500 options=9b ether 00:04:23:d6:de:0a inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseTX ) status: active em3: flags=8802 metric 0 mtu 1500 options=9b ether 00:04:23:d6:de:0b media: Ethernet autoselect status: no carrier pflog0: flags=141 metric 0 mtu 33204 pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: em2 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 carp0: flags=49 metric 0 mtu 1500 inet 10.222.5.164 netmask 0xffffff00 carp: BACKUP vhid 1 advbase 1 advskew 202 *pfctl -vvss output* No ALTQ support in kernel ALTQ related functions disabled all pfsync 224.0.0.240 <- 192.168.0.1 NO_TRAFFIC:SINGLE age 10:04:48, expires in 00:00:30, 20362:0 pkts, 2606504:0 bytes, rule 0 id: 4a582cf200000000 creatorid: 3b64bdb5 (no-sync) all carp 10.222.5.159 -> 224.0.0.18 SINGLE:NO_TRAFFIC age 10:21:40, expires in 00:00:30, 0:0 pkts, 0:0 bytes, rule 1 id: 4a582b5900000002 creatorid: 1801692c all pfsync 192.168.0.2 -> 224.0.0.240 SINGLE:NO_TRAFFIC age 10:04:47, expires in 00:00:30, 20354:0 pkts, 2605544:0 bytes, rule 0 id: 4a582cf200000003 creatorid: 3b64bdb5 (no-sync) all carp 224.0.0.18 <- 10.222.5.159 NO_TRAFFIC:SINGLE age 10:04:21, expires in 00:00:29, 20337:0 pkts, 1138872:0 bytes, rule 1 id: 4a582cf200000004 creatorid: 3b64bdb5 *pftop output* pfTop: Up State 1-4/4, View: default, Order: none, Cache: 10000 12:16:18 PR DIR SRC DEST STATE AGE EXP PKTS BYTES pfsync In 192.168.0.1:0 224.0.0.240:0 NO_TRAFFIC:SINGLE 10:05:15 00:00:29 20377 2608424 carp Out 10.222.5.159:0 224.0.0.18:0 SINGLE:NO_TRAFFIC 10:22:07 00:00:29 0 0 pfsync Out 192.168.0.2:0 224.0.0.240:0 SINGLE:NO_TRAFFIC 10:05:14 00:00:29 20369 2607464 carp In 10.222.5.159:0 224.0.0.18:0 NO_TRAFFIC:SINGLE 10:04:48 00:00:30 20353 1139768 As you can see from pf.conf on firewall1, I have added spacing and the additional "scrub in all" line and on firewall2 these are not present. I guess I am curious, based on what I have presented, is if I am not doing something wrong (must be) or if I have something mis-configured or if pfsync doesn't really sync the two files, just the state table. Thanks in advance for any help! -- Matthew From lists at loveturtle.net Sat Jul 11 19:38:10 2009 From: lists at loveturtle.net (Dillon Kass) Date: Sat Jul 11 19:38:16 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A4F0992.8090906@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4DE199.4010701@andric.com> <4A4F0992.8090906@simplenet.com> Message-ID: <4A58E5EC.1020905@loveturtle.net> It's hard to say exactly what is happening here without more information but here is the likely scenario. What is most likely happening is simple but a little tricky to notice. Your rdr rule is likely working fine. For the sake of this example lets just say that your lan is 192.168.0.0/24 your router is 192.168.0.1 the machine you want to forward to is 192.168.0.2 and your computer is 192.168.0.100 So lets say you have your rdr rule as follows rdr pass inet proto tcp from any to 209.131.36.158 port 80 -> 192.168.0.2 port 80 This rule is probably working just fine, this is most likely what is happening. Your computer is 192.168.0.100 and you send a request to 209.131.36.158 which is redirected to 192.168.0.2, 192.168.0.2 recives a request with the source ip of 192.168.0.100 and responds directly to you. This is the problem. You send a packet to 209.131.36.158 You get a response from 192.168.0.2, the packet is then dropped because your computer has no idea why 192.168.0.2 is sending you what would appear to be random crap. Install something like trafshow and open it up and attempt to connect again, look for two things. look at pfctl -vsr and see if your rule is being hit, and look at the output of trafshow and see if you're getting tcp traffic directly from the ip you're forwarding to. If you are than this is your problem. You should be able to use some fancy nat magic in pf so that the forwarded packet has a different source address (not from the same subnet) which will cause your 192.168.0.2 to send it's packet back to the router instead of directly to your 192.168.0.100 lan machine. On the way back through the router you can use some more fancy nat magic to rewrite the replys source ip to be 209.131.36.158 instead of 192.168.0.2. From apetar at gmail.com Sun Jul 12 14:20:52 2009 From: apetar at gmail.com (Aleksic Predrag) Date: Sun Jul 12 14:21:04 2009 Subject: pf between two lans In-Reply-To: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> Message-ID: <20090712155707.4925813c@overlord> Hi all. I've got two networks setup. 192.168.0.x and 192.168.2.x and I have an freebsd firewall between the two. Problem is people on the 192.168.0.x and 192.168.2.x. cant talk to each other. tzarlazar@192.168.2.248 $ ssh -p 22 -l tzarlazar 192.168.0.246 [root@192.168.0.1 ~]# tcpdump -n -e -vv -i pflog0 port 22 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 15:49:54.633735 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 18042, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:00.632597 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 27911, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:12.832179 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 36732, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:36.828468 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 27440, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:51:05.754673 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 40476, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:05.956165 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 2615, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 32 [bad hdr length 0 - too short, < 20] 15:51:06.362872 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 21085, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:07.176242 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 59723, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 32 [bad hdr length 0 - too short, < 20] 15:51:08.803001 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 25347, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:12.056479 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 57211, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:18.563581 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 64430, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:25.021046 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 4002, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 24 [bad hdr length 16 - too short, < 20] 15:51:31.577586 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 65157, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] Does anyone have any ideas why this is happening? And how to fix it? I've attached my pf.conf. If you need more info, please let me know as I'm new to playing with pf and the like. intIF = "vr0" intIF2 = "vr1" extIF = "sk0" tcpPubServices = "{ 22, 80 }" torrentPort = "57277" IcmpTypes = "echoreq" myNet = "192.168.0.0/16" myLaptop = "192.168.2.248" table persist table persist file "/etc/pf.blocked.sites.conf" set block-policy drop set skip on lo0 scrub in all fragment reassemble random-id no nat on $extIF inet proto {tcp, udp} from $intIF:network to $intIF2:network no nat on $extIF inet proto {tcp, udp} from $intIF2:network to $intIF:network nat on $extIF inet proto {tcp, udp} from $intIF:network to any -> (sk0) port 1024:32255 nat on $extIF inet proto {tcp, udp} from $intIF2:network to any -> (sk0) port 32255:65535 rdr on $extIF proto { tcp, udp } from any to any port $torrentPort -> $myLaptop block log (all, to pflog0) all block drop out log (all) quick on $extIF from any to block drop in log (all) quick on $extIF from to any pass in on $extIF inet proto { tcp, udp } from any to $myLaptop port $torrentPort pass out on $extIF proto { udp, tcp } from $myLaptop port $torrentPort pass in on $extIF inet proto { udp, tcp } from any to any port 80 pass quick proto { tcp, udp } from any to any port 22 \ flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 10/3, \ overload flush global) pass out on $extIF proto tcp all modulate state flags S/SA pass out on $extIF proto { udp, icmp } all keep state pass out on $extIF proto esp from any to any keep state pass in on $intIF from $intIF:network to any keep state pass out on $intIF from any to $intIF:network keep state pass in on $intIF2 from $intIF2:network to any keep state pass out on $intIF2 from any to $intIF2:network keep state From rmaglasang at infoweapons.com Mon Jul 13 04:15:39 2009 From: rmaglasang at infoweapons.com (Ronnel Maglasang) Date: Mon Jul 13 04:15:45 2009 Subject: Extremely simple redirect rule doesnt appear to be working In-Reply-To: <4A582BE5.8020300@simplenet.com> References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> <4A518F07.1070209@simplenet.com> <4A5190C1.2060205@infoweapons.com> <4A582BE5.8020300@simplenet.com> Message-ID: <4A5AB160.8040306@infoweapons.com> Tim Traver wrote: >>> am I missing something ? >>> >>> >> Yes, I believe so. >> >> rdr works only for incoming traffic. To redirect outgoing traffic >> locally you >> need to re-route the traffic using the route-to option. >> >> Try these rules. >> >> -- >> rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> >> port 80 >> pass out log quick on lo0 no state >> pass in log quick on lo0 no state >> >> pass out quick on route-to (lo0 ) >> inet proto tcp from any to 209.131.36.158 port 80 keep state >> -- >> >> > Hmmm...I tried that configuration, but it still doesn't seem to produce > anything : > > here is the exact config that I am using based on your statements : > > rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> > 209.132.4.203 port 80 > pass out log quick on lo0 no state > pass in log quick on lo0 no state > > pass out quick on fxp0 route-to 127.0.0.1 inet proto tcp from any to > 209.131.36.158 port 80 keep state > > when I reload pf, it looks like the rules and nat stuff is indeed in > place, but I get nothing when I attempt from the command line to telnet > to 209.131.36.158 on port 80 > > I was expecting it to get answered on the local 127.0.0.1 port 80 which > is indeed responding... > > any other ideas on how to accomplish this? > > Once again, I'm trying to make it so that any calls out from this box to > certain IP's get redirected to a local IP on the box, so it never > actually leaves the server... > > I have similar setup and appears to be working... Please attach the output of the following commands: ifconfig -a sockstat pfctl -sa > Thanks, > > Tim. > > > > > From bugmaster at FreeBSD.org Mon Jul 13 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:09:15 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200907131107.n6DB71A5040712@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/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w 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 34 problems total. From mksmith at adhost.com Mon Jul 13 12:05:31 2009 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon Jul 13 12:05:38 2009 Subject: pf between two lans In-Reply-To: <20090712155707.4925813c@overlord> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> Message-ID: <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> Hello Aleksic: > > no nat on $extIF inet proto {tcp, udp} from $intIF:network to > $intIF2:network > no nat on $extIF inet proto {tcp, udp} from $intIF2:network to > $intIF:network > If nothing else, these rules won't match because the traffic isn't traversing the External Interface. no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to $intIF2:network no nat on $intIF inet proto {tcp, udp} from $infIF2:network to $intIF:network Regards, Mike From peter at allicient.co.uk Tue Jul 14 00:47:36 2009 From: peter at allicient.co.uk (Peter Maxwell) Date: Tue Jul 14 00:47:43 2009 Subject: pf between two lans In-Reply-To: <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> Message-ID: <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> Hi Aleksic, On a cursory glance, your pf.conf looks ok. The tcpdump you supplied is showing both incoming and outgoing packets being blocked which is wierd - why would there be a return packet if the initial SYN didn't get through? Can you post the output of: pfctl -s r What happens if you try things without pf loaded, and with pf loaded but a pass all ruleset? Have you got gateway_enable set in your rc.conf (I think it shows as net.inet.ip.forwarding being set to 1 in your sysctl)? Can you post the results of the same tcpdump with a larger window size ( -s 1024 ) and/or a tcpdump on the network interface itself? There's probably a simple explanation I'm not seeing, but those are the kind of things I'd try/check. Peter 2009/7/13 Michael K. Smith - Adhost : > Hello Aleksic: >> >> no nat on $extIF inet proto {tcp, udp} from $intIF:network to >> $intIF2:network >> no nat on $extIF inet proto {tcp, udp} from $intIF2:network to >> $intIF:network >> > If nothing else, these rules won't match because the traffic isn't > traversing the External Interface. > > no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to > $intIF2:network > no nat on $intIF inet proto {tcp, udp} from $infIF2:network to > $intIF:network > > Regards, > > 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 mandrei05 at gmail.com Tue Jul 14 08:04:38 2009 From: mandrei05 at gmail.com (Andrei Manescu) Date: Tue Jul 14 08:04:45 2009 Subject: pftpx + pf issue Message-ID: Hello. 2nd message to this list because from my first subscribtion I get: delivery 328: deferral: 69.147.83.52_does_not_like_recipient./Remote_host_said:_450_4.7.1_:_Recipient_address_rejected:_Service_is_unavailable/Giving_up_on_69.147.83.52./ I'm trying to setup an ftp-proxy (pftpx) with PF. I have set up the nat anchors and rdr in pf.conf. My setup: +-------------+ | INTERNET | +-------------+ | | | +-------------+ | PF | | pftpx | +-------------+ | | | +-------------+ | PRFTPD | +-------------+ The client in internet: 52.125.11.51 PF External IP address: 81.157.22.26 FTP Server: 192.168.1.10 The rules in pf added by pftpx: # pfctl -v -a `pfctl -sA -v | grep -v "pftpx$"` -sr; pfctl -vvv -a `pfctl -sA -v | grep -v "pftpx$"` -sn pass in log quick inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] pass out log quick inet proto tcp from 192.168.1.10 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 nat inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 -> 192.168.1.10 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 rdr inet proto tcp from 52.125.11.51 to 81.157.22.26 port = 53266 -> 192.168.1.10 port 65186 [ Evaluations: 3 Packets: 2 Bytes: 80 States: 1 ] Proftpd ouput: domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - in dir_check_full(): path = '/', fullpath = '/usr/home/www/test_dir/'. domain.com (192.168.1.10[192.168.1.10]) - ROOT PRIVS at inet.c:237 domain.com (192.168.1.10[192.168.1.10]) - RELINQUISH PRIVS at inet.c:254 domain.com (192.168.1.10[192.168.1.10]) - Entering Extended Passive Mode (|||65186|) domain.com (192.168.1.10[192.168.1.10]) - dispatching POST_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_log domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_ratio domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'LIST' to mod_ls domain.com (192.168.1.10[192.168.1.10]) - SECURITY VIOLATION: Passive connection from 52.125.11.51 rejected. FTP Client: 230 User test_user logged in Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||53266|) 421 Service not available, remote server has closed connection. ftp> ftp> ^D PFTPX output: #1 server: 230 User test_user logged in\r\n #1 client: SYST\r\n #1 server: 215 UNIX Type: L8\r\n #1 client: FEAT\r\n #1 server: 211-Featuresn #1 server: MDTM\n #1 server: MFMT\n #1 server: MFF modify;UNIX.group;UNIX.mode;\n #1 server: MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX .mode*;UNIX.owner*;\n #1 server: REST STREAM\n #1 server: SIZE\r\n #1 server: 211 End\r\n #1 client: PWD\r\n #1 server: 257 "/" is the current directory\r\n #1 client: EPSV\r\n #1 server: 229 Entering Extended Passive Mode (|||65186|)\r\n #1 passive: client to server port 65186 via port 53266 #1 proxy: 229 Entering Extended Passive Mode (|||53266|)\r\n #1 client: LIST\r\n ^Cpftpx exiting on signal 2 #1 ending session As you can see, pftpx adds correct rules in PF, but the client's IP (52.125.11.51) isn't nated (proftpd complains: Passive connection from 52.125.11.51 rejected). The packets from the client are being redirected to ftp server, but the nat rule isn't applied to them. First part of my pf.conf: ext_if1="xl0" # replace with actual external interface name i.e., dc0 int_if1="dc0" # replace with actual internal interface name i.e., dc1 WEB_HOST="192.168.1.10" SMTP_HOST="192.168.1.11" internal_net1="192.168.1.0/24" external_addr1="81.157.22.26" icmp_types="echoreq" set optimization normal set block-policy drop set state-policy if-bound set skip on lo0 scrub all reassemble tcp scrub in all fragment reassemble scrub out all random-id nat-anchor "pftpx/*" rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $ext_adr2, $external_addr1} port 80 -> 192.168.1.10 port 80 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6122 -> 192.168.1.10 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6123 -> 192.168.1.11 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 25 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 993 -> 192.168.1.11 rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $external_addr1} port 443 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 33890 -> 192.168.1.1 port 33890 rdr-anchor "pftpx/*" rdr pass on $ext_if1 proto tcp from any to $external_addr1 port 21 -> $external_addr1 port 8021 nat on $ext_if1 inet from $internal_net1 to any -> $ext_if1 block drop log-all all block drop in log quick from block drop in log quick from block drop in log quick from any os {SCO, NMAP} to any pass out quick on $gre_if from any to 192.168.25.0/24 flags S/SA keep state queue ssh pass in quick on $gre_if from 192.168.25.0/24 to any flags S/SA keep state queue ssh block drop in log quick proto tcp from any to any flags FUP/FUP block drop in log quick proto tcp from any to any flags SAFRPU/SAFRPU block drop in log quick proto tcp from any to any flags SAFRU/SAFRU block drop in log quick proto tcp from any to any flags SF/SF block drop in log-all quick proto tcp from any to any flags SR/SR block drop in log-all quick proto tcp from any to any flags SF/SFRA block drop in log-all quick proto tcp from any to any flags /SFRA antispoof log quick for $ext_if1 inet antispoof log quick for lo0 inet Any hints on why the nat rule added by pftpx isn't evaluated even ([ Evaluations: 0)? From andrei.manescu at ivorde.ro Tue Jul 14 10:47:20 2009 From: andrei.manescu at ivorde.ro (Andrei Manescu - Ivorde) Date: Tue Jul 14 10:47:28 2009 Subject: pftpx + pf issue Message-ID: <2b4d7fa39913928c4086e754656e9f7e.squirrel@mail.ivorde.ro> Hello. I'm trying to setup an ftp-proxy (pftpx) with PF. I have set up the nat anchors and rdr in pf.conf. My setup: +-------------+ | INTERNET | +-------------+ | | | +-------------+ | PF | | pftpx | +-------------+ | | | +-------------+ | PRFTPD | +-------------+ The client in internet: 52.125.11.51 PF External IP address: 81.157.22.26 FTP Server: 192.168.1.10 The rules in pf added by pftpx: # pfctl -v -a `pfctl -sA -v | grep -v "pftpx$"` -sr; pfctl -vvv -a `pfctl -sA -v | grep -v "pftpx$"` -sn pass in log quick inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] pass out log quick inet proto tcp from 192.168.1.10 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 nat inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 -> 192.168.1.10 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 rdr inet proto tcp from 52.125.11.51 to 81.157.22.26 port = 53266 -> 192.168.1.10 port 65186 [ Evaluations: 3 Packets: 2 Bytes: 80 States: 1 ] Proftpd ouput: domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - in dir_check_full(): path = '/', fullpath = '/usr/home/www/test_dir/'. domain.com (192.168.1.10[192.168.1.10]) - ROOT PRIVS at inet.c:237 domain.com (192.168.1.10[192.168.1.10]) - RELINQUISH PRIVS at inet.c:254 domain.com (192.168.1.10[192.168.1.10]) - Entering Extended Passive Mode (|||65186|) domain.com (192.168.1.10[192.168.1.10]) - dispatching POST_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_log domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_ratio domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'LIST' to mod_ls domain.com (192.168.1.10[192.168.1.10]) - SECURITY VIOLATION: Passive connection from 52.125.11.51 rejected. FTP Client: 230 User test_user logged in Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||53266|) 421 Service not available, remote server has closed connection. ftp> ftp> ^D PFTPX output: #1 server: 230 User test_user logged in\r\n #1 client: SYST\r\n #1 server: 215 UNIX Type: L8\r\n #1 client: FEAT\r\n #1 server: 211-Featuresn #1 server: MDTM\n #1 server: MFMT\n #1 server: MFF modify;UNIX.group;UNIX.mode;\n #1 server: MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX .mode*;UNIX.owner*;\n #1 server: REST STREAM\n #1 server: SIZE\r\n #1 server: 211 End\r\n #1 client: PWD\r\n #1 server: 257 "/" is the current directory\r\n #1 client: EPSV\r\n #1 server: 229 Entering Extended Passive Mode (|||65186|)\r\n #1 passive: client to server port 65186 via port 53266 #1 proxy: 229 Entering Extended Passive Mode (|||53266|)\r\n #1 client: LIST\r\n ^Cpftpx exiting on signal 2 #1 ending session As you can see, pftpx adds correct rules in PF, but the client's IP (52.125.11.51) isn't nated (proftpd complains: Passive connection from 52.125.11.51 rejected). The packets from the client are being redirected to ftp server, but the nat rule isn't applied to them. First part of my pf.conf: ext_if1="xl0" # replace with actual external interface name i.e., dc0 int_if1="dc0" # replace with actual internal interface name i.e., dc1 WEB_HOST="192.168.1.10" SMTP_HOST="192.168.1.11" internal_net1="192.168.1.0/24" external_addr1="81.157.22.26" icmp_types="echoreq" set optimization normal set block-policy drop set state-policy if-bound set skip on lo0 scrub all reassemble tcp scrub in all fragment reassemble scrub out all random-id nat-anchor "pftpx/*" rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $ext_adr2, $external_addr1} port 80 -> 192.168.1.10 port 80 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6122 -> 192.168.1.10 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6123 -> 192.168.1.11 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 25 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 993 -> 192.168.1.11 rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $external_addr1} port 443 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 33890 -> 192.168.1.1 port 33890 rdr-anchor "pftpx/*" rdr pass on $ext_if1 proto tcp from any to $external_addr1 port 21 -> $external_addr1 port 8021 nat on $ext_if1 inet from $internal_net1 to any -> $ext_if1 block drop log-all all block drop in log quick from block drop in log quick from block drop in log quick from any os {SCO, NMAP} to any pass out quick on $gre_if from any to 192.168.25.0/24 flags S/SA keep state queue ssh pass in quick on $gre_if from 192.168.25.0/24 to any flags S/SA keep state queue ssh block drop in log quick proto tcp from any to any flags FUP/FUP block drop in log quick proto tcp from any to any flags SAFRPU/SAFRPU block drop in log quick proto tcp from any to any flags SAFRU/SAFRU block drop in log quick proto tcp from any to any flags SF/SF block drop in log-all quick proto tcp from any to any flags SR/SR block drop in log-all quick proto tcp from any to any flags SF/SFRA block drop in log-all quick proto tcp from any to any flags /SFRA antispoof log quick for $ext_if1 inet antispoof log quick for lo0 inet Any hints on why the nat rule added by pftpx isn't evaluated even ([ Evaluations: 0)? From apetar at gmail.com Tue Jul 14 11:27:16 2009 From: apetar at gmail.com (Aleksic Predrag) Date: Tue Jul 14 11:27:23 2009 Subject: pf between two lans In-Reply-To: <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> Message-ID: <20090714132430.75bb46c8@overlord> On Tue, 14 Jul 2009 01:22:06 +0100 Peter Maxwell wrote: > Can you post the output of: pfctl -s r # pfctl -sr scrub in all random-id fragment reassemble block drop log (all) all block drop in on sk0 inet proto icmp all icmp-type echoreq block drop out log (all) quick on sk0 from any to block drop in log (all) quick on sk0 from to any pass in on sk0 inet proto tcp from any to 192.168.2.248 port = 57277 flags S/SA keep state pass in on sk0 inet proto udp from any to 192.168.2.248 port = 57277 keep state pass out on sk0 inet proto udp from 192.168.2.248 port = 57277 to any keep state pass out on sk0 inet proto tcp from 192.168.2.248 port = 57277 to any flags S/SA keep state pass in on sk0 inet proto udp from any to any port = http keep state pass in on sk0 inet proto tcp from any to any port = http flags S/SA keep state pass in on sk0 proto udp from any to any port = 2706 keep state pass in on sk0 proto tcp from any to any port = 2706 flags S/SA keep state pass quick proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) pass quick proto udp from any to any port = ssh keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) pass out on sk0 proto tcp all flags S/SA modulate state pass out on sk0 proto udp all keep state pass out on sk0 proto icmp all keep state pass out on sk0 proto esp all keep state pass in on vr0 inet from 192.168.2.0/24 to any flags S/SA keep state pass out on vr0 inet from any to 192.168.2.0/24 flags S/SA keep state pass in on vr1 inet from 192.168.0.0/24 to any flags S/SA keep state pass out on vr1 inet from any to 192.168.0.0/24 flags S/SA keep state Should i replace netmask to /16 in last four rules? > What happens if you try things without pf loaded > and with pf loaded but a pass all ruleset? With pf loaded i can open almost anything but not ssh connection. I can ping, browse shares and printers between lans. Without pf loaded i can do all that and ssh. Yesterday i changed default ssh port on remote box and it let me in with the same pf rules loaded. Now, I'm also suspicious about remote box, it is CentOS box with untouched config files, maybe SELinux is preventing ssh login. > Have you got gateway_enable set in your rc.conf (I think it shows as > net.inet.ip.forwarding being set to 1 in your sysctl)? sysctl -a | grep net.inet.ip.forwarding net.inet.ip.forwarding: 1 > Can you post the results of the same tcpdump with a larger window size > ( -s 1024 ) and/or a tcpdump on the network interface itself? see attachment > > > > > > > 2009/7/13 Michael K. Smith - Adhost : > > Hello Aleksic: > >> > >> no nat on $extIF inet proto {tcp, udp} from $intIF:network to > >> $intIF2:network > >> no nat on $extIF inet proto {tcp, udp} from $intIF2:network to > >> $intIF:network > >> > > If nothing else, these rules won't match because the traffic isn't > > traversing the External Interface. > > > > no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to > > $intIF2:network > > no nat on $intIF inet proto {tcp, udp} from $infIF2:network to > > $intIF:network > > > > Regards, > > > > 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" > > -------------- next part -------------- A non-text attachment was scrubbed... Name: vr1 Type: application/octet-stream Size: 6290 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090714/5b4ca4ca/vr1.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: pflog0 Type: application/octet-stream Size: 11561 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20090714/5b4ca4ca/pflog0.obj From ghostsniper007 at hotmail.com Tue Jul 14 15:25:00 2009 From: ghostsniper007 at hotmail.com (Tony) Date: Tue Jul 14 15:25:07 2009 Subject: question about max-src-conn and max-src-conn-rate Message-ID: Below is a packet filter snippet from my config file: block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass out quick on $int_if proto tcp from any to port 80 flags S/SA keep state pass out quick on $ext_if proto tcp from port 80 to any flags SA/SA keep state pass in quick on $int_if proto tcp from port 80 to any flags SA/SA keep state Question 1: Should the bruteforce rules be on each line, or just that first one? Question 2: If they should be on each line, should I multiply the values (80, 200/2) by 4 ? Question 3: Are the rates I'm using reasonable? blocking should be on the loose side I'm open to any thoughts, opinions or screams on best practices _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=9666046 From k at kevinkevin.com Tue Jul 14 23:15:39 2009 From: k at kevinkevin.com (Kevin) Date: Tue Jul 14 23:15:49 2009 Subject: PF + ALT QUEUE for DDOS DNS attack Message-ID: <00a001ca04d6$37a122e0$a6e368a0$@com> Greetings, I am currently attempting to mitigate a DDoS attack on our network that is comprised mainly of bogus DNS requests. The attacks seem to be coming in waves of DNS queries on our internal systems. I have tried several different ways of mitigating this, one of which is to queue the DNS traffic via PF + ALTQ. I have attempted to limit the DNS traffic to the particular host that is being attacked. However, this doesn't seem to be very effective, as the nature of a DDoS attack means that the queries being made are fairly simple and straightforward. I was hoping to get some tips / tricks from people who have encountered similar scenarios. My firewall is (obviously) PF. FreeBSD specific information : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 fw@fw:/usr/obj/usr/src/sys/FW i386 I'm looking for tips / tricks as far as what I can do on the firewall level, of course. Any help is greatly appreciated! :) ~kevin From peter at allicient.co.uk Tue Jul 14 23:36:56 2009 From: peter at allicient.co.uk (Peter Maxwell) Date: Tue Jul 14 23:37:02 2009 Subject: pf between two lans In-Reply-To: <20090714132430.75bb46c8@overlord> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> <20090714132430.75bb46c8@overlord> Message-ID: <7731938b0907141636p51a6cb6bp9e6553e494d465d9@mail.gmail.com> Comments inline... 2009/7/14 Aleksic Predrag : > On Tue, 14 Jul 2009 01:22:06 +0100 > Peter Maxwell wrote: > > ?> Can you post the output of: pfctl -s r > > # pfctl -sr > scrub in all random-id fragment reassemble > block drop log (all) all > block drop in on sk0 inet proto icmp all icmp-type echoreq > block drop out log (all) quick on sk0 from any to > block drop in log (all) quick on sk0 from to any > pass in on sk0 inet proto tcp from any to 192.168.2.248 port = 57277 flags S/SA keep state > pass in on sk0 inet proto udp from any to 192.168.2.248 port = 57277 keep state > pass out on sk0 inet proto udp from 192.168.2.248 port = 57277 to any keep state > pass out on sk0 inet proto tcp from 192.168.2.248 port = 57277 to any flags S/SA keep state > pass in on sk0 inet proto udp from any to any port = http keep state > pass in on sk0 inet proto tcp from any to any port = http flags S/SA keep state > pass in on sk0 proto udp from any to any port = 2706 keep state > pass in on sk0 proto tcp from any to any port = 2706 flags S/SA keep state > pass quick proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) > pass quick proto udp from any to any port = ssh keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) > pass out on sk0 proto tcp all flags S/SA modulate state > pass out on sk0 proto udp all keep state > pass out on sk0 proto icmp all keep state > pass out on sk0 proto esp all keep state > I'd comment out the two (single rule in the pf.conf) "pass quick" rules with the max-src-conn/max-src-conn-rate and see if it helps. Starting with a simple ruleset which works, then incrementally adding in additional rules is usually a good stategy. I know that others may disagree, but I would also suggest that you avoid using the "quick" keyword unless you *really* need it - most rulesets can be written entirely without it and are easier to debug. > pass in on vr0 inet from 192.168.2.0/24 to any flags S/SA keep state > pass out on vr0 inet from any to 192.168.2.0/24 flags S/SA keep state > pass in on vr1 inet from 192.168.0.0/24 to any flags S/SA keep state > pass out on vr1 inet from any to 192.168.0.0/24 flags S/SA keep state > > Should i replace netmask to /16 in last four rules? > No, you have it right as it is. >> What happens if you try things without pf loaded >> and with pf loaded but a pass all ruleset? > > With pf loaded i can open almost anything but not ssh connection. > I can ping, browse shares and printers between lans. > > Without pf loaded i can do all that and ssh. > > Yesterday i changed default ssh port on remote box and it let me in > with the same pf rules loaded. > > Now, I'm also suspicious about remote box, it is CentOS box with untouched > config files, maybe SELinux is preventing ssh login. While ssh can be configured with a tcpwrapper style hosts.allow, I doubt that this is the problem as you'd still not be able to ssh without pf loaded as well if it was the ssh daemon. You can test and make sure by connecting to the remote ssh port with telnet: if you get a normal ssh header returned there isn't any ip filter configured in sshd, if there is you'll get some form of error messge back. It sounds like a problem with the pass quick max-src-conn/max-src-conn-rate rule. > >> Have you got gateway_enable set in your rc.conf (I think it shows as >> net.inet.ip.forwarding being set to 1 in your sysctl)? > > sysctl -a | grep net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > >> Can you post the results of the same tcpdump with a larger window size >> ( -s 1024 ) and/or a tcpdump on the network interface itself? > > see attachment >> From torsten at cnc-london.net Tue Jul 14 23:46:20 2009 From: torsten at cnc-london.net (Torsten Kersandt) Date: Tue Jul 14 23:46:26 2009 Subject: PF + ALT QUEUE for DDOS DNS attack In-Reply-To: <00a001ca04d6$37a122e0$a6e368a0$@com> References: <00a001ca04d6$37a122e0$a6e368a0$@com> Message-ID: <001501ca04dd$4d6ec8f0$e84c5ad0$@net> Hi It is a common problem and can best be prevented configuring your DNS server to limit recursion (lookup requests of non local or authoritive domains) to the internal network and trusted Internet IP addresses only. All other solutions you may just delay or limit normal dns server responses Most DNS server software does that very simple and if it is a internal machine doing this , block udp/tcp requests to port 53 from that address to your server using pf until resolved. Regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Kevin Sent: 14 July 2009 23:56 To: freebsd-pf@freebsd.org Subject: PF + ALT QUEUE for DDOS DNS attack Greetings, I am currently attempting to mitigate a DDoS attack on our network that is comprised mainly of bogus DNS requests. The attacks seem to be coming in waves of DNS queries on our internal systems. I have tried several different ways of mitigating this, one of which is to queue the DNS traffic via PF + ALTQ. I have attempted to limit the DNS traffic to the particular host that is being attacked. However, this doesn't seem to be very effective, as the nature of a DDoS attack means that the queries being made are fairly simple and straightforward. I was hoping to get some tips / tricks from people who have encountered similar scenarios. My firewall is (obviously) PF. FreeBSD specific information : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 fw@fw:/usr/obj/usr/src/sys/FW i386 I'm looking for tips / tricks as far as what I can do on the firewall level, of course. Any help is greatly appreciated! :) ~kevin _______________________________________________ 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 valentin.bud at gmail.com Wed Jul 15 13:19:03 2009 From: valentin.bud at gmail.com (Valentin Bud) Date: Wed Jul 15 13:19:09 2009 Subject: question about max-src-conn and max-src-conn-rate In-Reply-To: References: Message-ID: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> On Tue, Jul 14, 2009 at 6:12 PM, Tony wrote: > > Below is a packet filter snippet from my config file: > > > > block drop log quick from > ... > pass in quick on $ext_if proto tcp from any to port 80 flags S/SA > keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush > global) > pass out quick on $int_if proto tcp from any to port 80 flags S/SA > keep state > > pass out quick on $ext_if proto tcp from port 80 to any flags > SA/SA keep state > pass in quick on $int_if proto tcp from port 80 to any flags > SA/SA keep state > > > > > Question 1: > Should the bruteforce rules be on each line, or just that first one? > > > > Question 2: > If they should be on each line, should I multiply the values (80, 200/2) by > 4 ? > > > > Question 3: > Are the rates I'm using reasonable? blocking should be on the loose side > > > > > I'm open to any thoughts, opinions or screams on best practices > > _________________________________________________________________ > Attention all humans. We are your photos. Free us. > > http://go.microsoft.com/?linkid=9666046_______________________________________________ > freebsd-pf@freebsd.orgmailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict connections to WEB_SRV to 200 conns in 2 seconds and a maximum of 80 connections from one source IP. If any one of those conditions are met overload the table with that IP and flush all the states that IP created. Now the questions is: do you want the above conditions to apply to traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass in quick on $int_if proto tcp from port 80 to any flags S/SA keep state No need for "pass out" rules because of the *keep state* keyword which tells the firewall to allow outgoing traffic to IPs that already established a connection with WEB_SRV on port 80. So the answer to "Question 1" is: *depends *and *no *You don't need the "pass out" rules so no need to repeat the brute force rule :). Now it depends, if you want the same policy to apply to traffic coming in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit the connections coming from one source IP to 80 and no more than 200 conns in 2 seconds for traffic coming in from both directions. You can change them as you need. Suppose you want to limit the maximum connections from one LAN IP to 120 and no more than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from one source IP. For example if a visitor tries to open 81 connections at the same time and you wish to let that happen you must increase the max-src-conn to something above 81. The same applies to max-src-conn-rate. I suggest you (re)read the pf faq from openbsd website ( http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v -- network warrior since 2005 From ghostsniper007 at hotmail.com Thu Jul 16 02:37:41 2009 From: ghostsniper007 at hotmail.com (Tony B) Date: Thu Jul 16 02:37:48 2009 Subject: question about max-src-conn and max-src-conn-rate In-Reply-To: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> Message-ID: thank you for the reply, This is the network layout I have: INTERNET-----($ext_if)[firewall/gateway]($int_if)-------[webservers on lan] Does that change must as per the suggestions ? I would need the pass out rules if the webservers executed a CURL or wget, correct ? Can someone suggest a max-src-conn-rate that would identify an attack? all the online examples are far too strict. From: Valentin Bud Sent: Wednesday, July 15, 2009 9:18 AM To: Tony Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate On Tue, Jul 14, 2009 at 6:12 PM, Tony wrote: Below is a packet filter snippet from my config file: block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass out quick on $int_if proto tcp from any to port 80 flags S/SA keep state pass out quick on $ext_if proto tcp from port 80 to any flags SA/SA keep state pass in quick on $int_if proto tcp from port 80 to any flags SA/SA keep state Question 1: Should the bruteforce rules be on each line, or just that first one? Question 2: If they should be on each line, should I multiply the values (80, 200/2) by 4 ? Question 3: Are the rates I'm using reasonable? blocking should be on the loose side I'm open to any thoughts, opinions or screams on best practices _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=9666046_______________________________________________ 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" Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict connections to WEB_SRV to 200 conns in 2 seconds and a maximum of 80 connections from one source IP. If any one of those conditions are met overload the table with that IP and flush all the states that IP created. Now the questions is: do you want the above conditions to apply to traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass in quick on $int_if proto tcp from port 80 to any flags S/SA keep state No need for "pass out" rules because of the keep state keyword which tells the firewall to allow outgoing traffic to IPs that already established a connection with WEB_SRV on port 80. So the answer to "Question 1" is: depends and no You don't need the "pass out" rules so no need to repeat the brute force rule :). Now it depends, if you want the same policy to apply to traffic coming in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit the connections coming from one source IP to 80 and no more than 200 conns in 2 seconds for traffic coming in from both directions. You can change them as you need. Suppose you want to limit the maximum connections from one LAN IP to 120 and no more than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from one source IP. For example if a visitor tries to open 81 connections at the same time and you wish to let that happen you must increase the max-src-conn to something above 81. The same applies to max-src-conn-rate. I suggest you (re)read the pf faq from openbsd website (http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v -- network warrior since 2005 From torsten at cnc-london.net Thu Jul 16 02:47:19 2009 From: torsten at cnc-london.net (Torsten Kersandt) Date: Thu Jul 16 02:47:25 2009 Subject: question about max-src-conn and max-src-conn-rate In-Reply-To: References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> Message-ID: <015901ca05bf$bf85cd70$3e916850$@net> HI I know that many people disagree with this but I would not block any outgoing requests front the gateway in the first place: As in: pass out quick keep state regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Tony B Sent: 16 July 2009 03:36 To: Valentin Bud Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate thank you for the reply, This is the network layout I have: INTERNET-----($ext_if)[firewall/gateway]($int_if)-------[webservers on lan] Does that change must as per the suggestions ? I would need the pass out rules if the webservers executed a CURL or wget, correct ? Can someone suggest a max-src-conn-rate that would identify an attack? all the online examples are far too strict. From: Valentin Bud Sent: Wednesday, July 15, 2009 9:18 AM To: Tony Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate On Tue, Jul 14, 2009 at 6:12 PM, Tony wrote: Below is a packet filter snippet from my config file: block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass out quick on $int_if proto tcp from any to port 80 flags S/SA keep state pass out quick on $ext_if proto tcp from port 80 to any flags SA/SA keep state pass in quick on $int_if proto tcp from port 80 to any flags SA/SA keep state Question 1: Should the bruteforce rules be on each line, or just that first one? Question 2: If they should be on each line, should I multiply the values (80, 200/2) by 4 ? Question 3: Are the rates I'm using reasonable? blocking should be on the loose side I'm open to any thoughts, opinions or screams on best practices _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=9666046_____________________________________ __________ 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" Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict connections to WEB_SRV to 200 conns in 2 seconds and a maximum of 80 connections from one source IP. If any one of those conditions are met overload the table with that IP and flush all the states that IP created. Now the questions is: do you want the above conditions to apply to traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass in quick on $int_if proto tcp from port 80 to any flags S/SA keep state No need for "pass out" rules because of the keep state keyword which tells the firewall to allow outgoing traffic to IPs that already established a connection with WEB_SRV on port 80. So the answer to "Question 1" is: depends and no You don't need the "pass out" rules so no need to repeat the brute force rule :). Now it depends, if you want the same policy to apply to traffic coming in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit the connections coming from one source IP to 80 and no more than 200 conns in 2 seconds for traffic coming in from both directions. You can change them as you need. Suppose you want to limit the maximum connections from one LAN IP to 120 and no more than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from one source IP. For example if a visitor tries to open 81 connections at the same time and you wish to let that happen you must increase the max-src-conn to something above 81. The same applies to max-src-conn-rate. I suggest you (re)read the pf faq from openbsd website (http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v -- network warrior since 2005 _______________________________________________ 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 Greg.Hennessy at nviz.net Thu Jul 16 08:09:07 2009 From: Greg.Hennessy at nviz.net (Greg Hennessy) Date: Thu Jul 16 08:09:13 2009 Subject: question about max-src-conn and max-src-conn-rate In-Reply-To: <015901ca05bf$bf85cd70$3e916850$@net> References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> , <015901ca05bf$bf85cd70$3e916850$@net> Message-ID: <6CE8D2A5CE118747811E51143A68BA0A72F4C625B5@PEMEXMBXVS01.jellyfishnet.co.uk.local> That converts the operation of PF into a PIX. :-) I would tend to caveat the advice below with liberal use of tag and 'tagged' Greg ________________________________________ From: owner-freebsd-pf@freebsd.org [owner-freebsd-pf@freebsd.org] On Behalf Of Torsten Kersandt [torsten@cnc-london.net] Sent: 16 July 2009 03:47 Cc: freebsd-pf@freebsd.org Subject: RE: question about max-src-conn and max-src-conn-rate HI I know that many people disagree with this but I would not block any outgoing requests front the gateway in the first place: As in: pass out quick keep state regards Torsten From linimon at FreeBSD.org Fri Jul 17 04:14:34 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Jul 17 04:14:46 2009 Subject: kern/136781: [pf] Packets appear to drop with pf scrub and if_bridge Message-ID: <200907170414.n6H4EYMZ092552@freefall.freebsd.org> Old Synopsis: Packets appear to drop with pf scrub and if_bridge New Synopsis: [pf] Packets appear to drop with pf scrub and if_bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 17 04:14:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136781 From elliott at mywedding.com Fri Jul 17 16:11:01 2009 From: elliott at mywedding.com (Elliott Barrere) Date: Fri Jul 17 16:11:07 2009 Subject: pfsync synchronize rules? Message-ID: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> Hey all, I've seen references to synchronizing rules and macros through CARP/ pfsync, but only in relation to pfSense. Is this built in to CARP or the pfsync protocol or is it dependent on pfSense? I can use rsync or something if not, but I'd like to use what's built in if it's available. Thanks! -elliott- From elliott at mywedding.com Fri Jul 17 16:22:11 2009 From: elliott at mywedding.com (Elliott Barrere) Date: Fri Jul 17 16:22:17 2009 Subject: pfsync synchronize rules? In-Reply-To: References: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> Message-ID: On Jul 17, 2009, at 9:17 AM, Scott Ullrich wrote: > On Fri, Jul 17, 2009 at 11:53 AM, Elliott Barrere > wrote: >> Hey all, >> >> I've seen references to synchronizing rules and macros through CARP/ >> pfsync, >> but only in relation to pfSense. Is this built in to CARP or the >> pfsync >> protocol or is it dependent on pfSense? I can use rsync or >> something if >> not, but I'd like to use what's built in if it's available. > > Syncing of rules is not done via CARP. It is specific to pfSense. Perfect, all I needed to know. Thanks for the quick response! > > Scott From sullrich at gmail.com Fri Jul 17 16:43:48 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Jul 17 16:43:55 2009 Subject: pfsync synchronize rules? In-Reply-To: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> References: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> Message-ID: On Fri, Jul 17, 2009 at 11:53 AM, Elliott Barrere wrote: > Hey all, > > I've seen references to synchronizing rules and macros through CARP/pfsync, > but only in relation to pfSense. ?Is this built in to CARP or the pfsync > protocol or is it dependent on pfSense? ?I can use rsync or something if > not, but I'd like to use what's built in if it's available. Syncing of rules is not done via CARP. It is specific to pfSense. Scott From bugmaster at FreeBSD.org Mon Jul 20 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:09:13 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200907201107.n6KB70L3002386@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/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w 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 35 problems total. From gdakos at enovation.gr Mon Jul 20 12:44:28 2009 From: gdakos at enovation.gr (John Dakos [ Enovation Technologies ]) Date: Mon Jul 20 12:44:35 2009 Subject: Filtered Ports or Closed Ports ? Message-ID: <1B1238E1D957409EA47868C515354286@john> Hello All. Im newbie on PF , I install PF on FreeBSD 7.2 Released. I have a question, what is more secure for the system Filtered Ports or Closed Ports? Thanks All John Dakos Network Administrator Enovation Technologies Filellinon 35, Chalandrion 15232 Athens, GREECE Tel: +30-210 8119784 Mob: +30-6979348082 From leccine at gmail.com Mon Jul 20 13:22:19 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Mon Jul 20 13:22:25 2009 Subject: Filtered Ports or Closed Ports ? In-Reply-To: <1B1238E1D957409EA47868C515354286@john> References: <1B1238E1D957409EA47868C515354286@john> Message-ID: are you talking about the block-policy? I think drop is better because if somebody is flooding you from fake addresses you are going to send out million packets to wrong targets. I vote for set block-policy drop Regards, Istvan On Mon, Jul 20, 2009 at 5:44 AM, John Dakos [ Enovation Technologies ] < gdakos@enovation.gr> wrote: > > > Hello All. > > > > Im newbie on PF , I install PF on FreeBSD 7.2 Released. > > > > I have a question, what is more secure for the system Filtered Ports or > Closed Ports? > > > > Thanks All > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > John Dakos > Network Administrator > Enovation Technologies > Filellinon 35, Chalandrion > 15232 Athens, GREECE > Tel: +30-210 8119784 > Mob: +30-6979348082 > > > > _______________________________________________ > 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" > -- the sun shines for all From unix.co at gmail.com Thu Jul 23 13:24:00 2009 From: unix.co at gmail.com (Umar) Date: Thu Jul 23 13:24:06 2009 Subject: please Help Message-ID: <24625659.post@talk.nabble.com> Dear Members! I have FreeBSD 7.1 with squid proxy running. PF is configured. Last few days i am facing some problems. Browsing is stuck time by time on clients machine. I tried to ping my local network from my FreeBSD server there i found the issue. here is the output of ping. [root@proxyServer ~]# ping 10.11.0.3 PING 10.11.0.3 (10.11.0.3): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted 64 bytes from 10.11.0.3: icmp_seq=3 ttl=64 time=0.111 ms 64 bytes from 10.11.0.3: icmp_seq=4 ttl=64 time=0.147 ms 64 bytes from 10.11.0.3: icmp_seq=5 ttl=64 time=0.099 ms [root@proxyServer ~]# ping 10.11.0.5 PING 10.11.0.5 (10.11.0.5): 56 data bytes ping: sendto: Operation not permitted ping: sendto: Operation not permitted ping: sendto: Operation not permitted 64 bytes from 10.11.0.5: icmp_seq=3 ttl=64 time=0.111 ms 64 bytes from 10.11.0.5: icmp_seq=4 ttl=64 time=0.147 ms 64 bytes from 10.11.0.5: icmp_seq=5 ttl=64 time=0.099 ms On DNS queury [root@proxyServer~]# nslookup www.yahoo.com ;; connection timed out; no servers could be reached [root@proxyServer~]# nslookup www.yahoo.com Server: 10.11.0.9 Address: 10.11.0.9#53 Non-authoritative answer: www.yahoo.com canonical name = www.wa1.b.yahoo.com. www.wa1.b.yahoo.com canonical name = www-real.wa1.b.yahoo.com. Name: www-real.wa1.b.yahoo.com Address: 87.248.113.14 As you can see some time its getting response and some times not. If I stop (PF) then its working fine. Is there any traffic load issue or PF issue? or any kernel tunning required for heavy traffic. Please help Regards, Umar -- View this message in context: http://www.nabble.com/please-Help-tp24625659p24625659.html Sent from the freebsd-pf mailing list archive at Nabble.com. From leccine at gmail.com Thu Jul 23 13:27:21 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Thu Jul 23 13:27:29 2009 Subject: please Help In-Reply-To: <24625659.post@talk.nabble.com> References: <24625659.post@talk.nabble.com> Message-ID: check the pf logs if you are logging at all.... http://www.openbsd.org/faq/pf/logging.html regards, Istvan On Thu, Jul 23, 2009 at 6:23 AM, Umar wrote: > > Dear Members! > > I have FreeBSD 7.1 with squid proxy running. PF is configured. > > Last few days i am facing some problems. Browsing is stuck time by time on > clients machine. > > I tried to ping my local network from my FreeBSD server there i found the > issue. > > here is the output of ping. > > [root@proxyServer ~]# ping 10.11.0.3 > PING 10.11.0.3 (10.11.0.3): 56 data bytes > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > 64 bytes from 10.11.0.3: icmp_seq=3 ttl=64 time=0.111 ms > 64 bytes from 10.11.0.3: icmp_seq=4 ttl=64 time=0.147 ms > 64 bytes from 10.11.0.3: icmp_seq=5 ttl=64 time=0.099 ms > > [root@proxyServer ~]# ping 10.11.0.5 > PING 10.11.0.5 (10.11.0.5): 56 data bytes > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > ping: sendto: Operation not permitted > 64 bytes from 10.11.0.5: icmp_seq=3 ttl=64 time=0.111 ms > 64 bytes from 10.11.0.5: icmp_seq=4 ttl=64 time=0.147 ms > 64 bytes from 10.11.0.5: icmp_seq=5 ttl=64 time=0.099 ms > > On DNS queury > [root@proxyServer~]# nslookup www.yahoo.com > ;; connection timed out; no servers could be reached > > [root@proxyServer~]# nslookup www.yahoo.com > Server: 10.11.0.9 > Address: 10.11.0.9#53 > > Non-authoritative answer: > www.yahoo.com canonical name = www.wa1.b.yahoo.com. > www.wa1.b.yahoo.com canonical name = www-real.wa1.b.yahoo.com. > Name: www-real.wa1.b.yahoo.com > Address: 87.248.113.14 > > As you can see some time its getting response and some times not. If I stop > (PF) then its working fine. > > Is there any traffic load issue or PF issue? or any kernel tunning required > for heavy traffic. > > Please help > > Regards, > > Umar > -- > View this message in context: > http://www.nabble.com/please-Help-tp24625659p24625659.html > Sent from the freebsd-pf mailing list archive at Nabble.com. > > _______________________________________________ > 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" > -- the sun shines for all From bugmaster at FreeBSD.org Mon Jul 27 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:09:17 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200907271106.n6RB6x7e019046@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/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w 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 35 problems total. From elliott at mywedding.com Tue Jul 28 21:18:41 2009 From: elliott at mywedding.com (Elliott Barrere) Date: Tue Jul 28 21:19:23 2009 Subject: CARP and NAT Message-ID: Hi everyone, please excuse my noobiness. I have a basic firewall setup with CARP running on the LAN and WAN interfaces. CARP and pfsync seem to be functioning properly. The problem is I can't seem to figure out how to make pf NAT from the internal network to the carp1 interface IP on the outside (packets always end up coming from the IP of the physical interface in question). I thought I could do something like: nat on $carp_if from $lan_net to any -> ($carp_if) but that doesn't work. Can anyone provide me examples of a setup using CARP and NAT? I feel like this should be pretty common... Thanks! :: elliott barrere :: 206.855.7011 :: From elliott at mywedding.com Tue Jul 28 21:31:56 2009 From: elliott at mywedding.com (Elliott Barrere) Date: Tue Jul 28 21:32:01 2009 Subject: CARP and NAT In-Reply-To: References: Message-ID: <2B0E2B36-CB22-4C8B-B9FF-64D958B20FDA@mywedding.com> Nevermind, I sorted out my issue. The carp1 interface had multiple IPs assigned and PF was pulling the last one. Adding a carp_ip variable and changing the NAT statement makes it work: nat on $cable_if from $lan_net to any -> $carp_ip This does make me wonder though more generally about when to use the carp interface versus the physical interface in PF. Does anyone know of a guide or a good rule of thumb? Thanks! :: elliott barrere :: 206.855.7011 :: On Jul 28, 2009, at 1:56 PM, Elliott Barrere wrote: > Hi everyone, please excuse my noobiness. > > I have a basic firewall setup with CARP running on the LAN and WAN > interfaces. CARP and pfsync seem to be functioning properly. The > problem is I can't seem to figure out how to make pf NAT from the > internal network to the carp1 interface IP on the outside (packets > always end up coming from the IP of the physical interface in > question). > > I thought I could do something like: > > nat on $carp_if from $lan_net to any -> ($carp_if) > > but that doesn't work. Can anyone provide me examples of a setup > using CARP and NAT? I feel like this should be pretty common... > > > Thanks! > > :: elliott barrere :: 206.855.7011 :: > > >