Re: ipfilter mystery
Fbsd8 wrote: Running 9.0 and connecting to Time Warner for the first time. I have private lan behind my 9.0 box. I have made a real simple rule set and nat rule just to get log of what is happing. ipfilter rules. dc0 faces lan, fxp0 faces public internet pass in log quick on dc0 all pass out log quick on dc0 all #pass in quick on fxp0 from 10.2.0.1 pass in log quick on fxp0 all pass out log quick on fxp0 all pass in quick on lo0 all pass out quick on lo0 all nat rule map fxp0 10.0.10.0/29 - 0/32 Ipmon log fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 384 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 384 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast dc0 @0:1 p 10.0.10.1,55884 - 209.18.47.61,53 PR udp len 20 61 IN fxp0 @0:2 p 177.99.209.140,55884 - 209.18.47.61,53 PR udp len 20 61 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,55884 PR udp len 20 95 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,55884 PR udp len 20 95 OUT bad dc0 @0:1 p 10.0.10.1,55660 - 209.18.47.61,53 PR udp len 20 64 IN fxp0 @0:2 p 177.99.209.140,55660 - 209.18.47.61,53 PR udp len 20 64 OUT NAT dc0 @0:1 p 10.0.10.1,51926 - 209.18.47.61,53 PR udp len 20 62 IN fxp0 @0:2 p 177.99.209.140,51926 - 209.18.47.61,53 PR udp len 20 62 OUT NAT dc0 @0:1 p 10.0.10.1,58697 - 209.18.47.61,53 PR udp len 20 61 IN fxp0 @0:2 p 177.99.209.140,58697 - 209.18.47.61,53 PR udp len 20 61 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,55660 PR udp len 20 80 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,55660 PR udp len 20 80 OUT bad dc0 @0:1 p 10.0.10.1,49947 - 209.18.47.61,53 PR udp len 20 64 IN fxp0 @0:2 p 177.99.209.140,49947 - 209.18.47.61,53 PR udp len 20 64 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,58697 PR udp len 20 77 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,58697 PR udp len 20 77 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,51926 PR udp len 20 100 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,51926 PR udp len 20 100 OUT bad dc0 @0:1 p 10.0.10.1,49901 - 209.18.47.61,53 PR udp len 20 63 IN fxp0 @0:2 p 177.99.209.140,49901 - 209.18.47.61,53 PR udp len 20 63 OUT NAT dc0 @0:1 p 10.0.10.1,59865 - 209.18.47.61,53 PR udp len 20 66 IN fxp0 @0:2 p 177.99.209.140,59865 - 209.18.47.61,53 PR udp len 20 66 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,59865 PR udp len 20 82 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,59865 PR udp len 20 82 OUT bad dc0 @0:1 p 10.0.10.1,53742 - 209.18.47.61,53 PR udp len 20 71 IN fxp0 @0:2 p 177.99.209.140,53742 - 209.18.47.61,53 PR udp len 20 71 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,49947 PR udp len 20 116 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,49947 PR udp len 20 116 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,49901 PR udp len 20 99 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,49901 PR udp len 20 99 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,53742 PR udp len 20 120 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,53742 PR udp len 20 120 OUT bad fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast dc0 @0:1 p 10.0.10.1,1320 - 69.147.83.34,80 PR tcp len 20 48 -S IN fxp0 @0:2 p 177.99.209.140,1320 - 69.147.83.34,80 PR tcp len 20 48 -S OUT NAT 10.0.10.1 is the laptop in the lan. 10.2.0.1 is being sent by time warner I can not understand why I am getting the IN bad NAT The webpage loaded ok on the lan laptop. I have been using ipfilter since release 3.2 and this is the first isp i ever got this kind of problem with. This turns out to be a bug in ipfilter. It’s now been reported as a bug to Darren Reed the maintainer of ipfilter. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter mystery
Running 9.0 and connecting to Time Warner for the first time. I have private lan behind my 9.0 box. I have made a real simple rule set and nat rule just to get log of what is happing. ipfilter rules. dc0 faces lan, fxp0 faces public internet pass in log quick on dc0 all pass out log quick on dc0 all #pass in quick on fxp0 from 10.2.0.1 pass in log quick on fxp0 all pass out log quick on fxp0 all pass in quick on lo0 all pass out quick on lo0 all nat rule map fxp0 10.0.10.0/29 - 0/32 Ipmon log fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 384 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 384 IN bad broadcast fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast dc0 @0:1 p 10.0.10.1,55884 - 209.18.47.61,53 PR udp len 20 61 IN fxp0 @0:2 p 177.99.209.140,55884 - 209.18.47.61,53 PR udp len 20 61 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,55884 PR udp len 20 95 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,55884 PR udp len 20 95 OUT bad dc0 @0:1 p 10.0.10.1,55660 - 209.18.47.61,53 PR udp len 20 64 IN fxp0 @0:2 p 177.99.209.140,55660 - 209.18.47.61,53 PR udp len 20 64 OUT NAT dc0 @0:1 p 10.0.10.1,51926 - 209.18.47.61,53 PR udp len 20 62 IN fxp0 @0:2 p 177.99.209.140,51926 - 209.18.47.61,53 PR udp len 20 62 OUT NAT dc0 @0:1 p 10.0.10.1,58697 - 209.18.47.61,53 PR udp len 20 61 IN fxp0 @0:2 p 177.99.209.140,58697 - 209.18.47.61,53 PR udp len 20 61 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,55660 PR udp len 20 80 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,55660 PR udp len 20 80 OUT bad dc0 @0:1 p 10.0.10.1,49947 - 209.18.47.61,53 PR udp len 20 64 IN fxp0 @0:2 p 177.99.209.140,49947 - 209.18.47.61,53 PR udp len 20 64 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,58697 PR udp len 20 77 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,58697 PR udp len 20 77 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,51926 PR udp len 20 100 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,51926 PR udp len 20 100 OUT bad dc0 @0:1 p 10.0.10.1,49901 - 209.18.47.61,53 PR udp len 20 63 IN fxp0 @0:2 p 177.99.209.140,49901 - 209.18.47.61,53 PR udp len 20 63 OUT NAT dc0 @0:1 p 10.0.10.1,59865 - 209.18.47.61,53 PR udp len 20 66 IN fxp0 @0:2 p 177.99.209.140,59865 - 209.18.47.61,53 PR udp len 20 66 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,59865 PR udp len 20 82 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,59865 PR udp len 20 82 OUT bad dc0 @0:1 p 10.0.10.1,53742 - 209.18.47.61,53 PR udp len 20 71 IN fxp0 @0:2 p 177.99.209.140,53742 - 209.18.47.61,53 PR udp len 20 71 OUT NAT fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,49947 PR udp len 20 116 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,49947 PR udp len 20 116 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,49901 PR udp len 20 99 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,49901 PR udp len 20 99 OUT bad fxp0 @0:2 p 209.18.47.61,53 - 10.0.10.1,53742 PR udp len 20 120 IN bad NAT dc0 @0:1 p 209.18.47.61,53 - 10.0.10.1,53742 PR udp len 20 120 OUT bad fxp0 @0:2 p 10.2.0.1,67 - 255.255.255.255,68 PR udp len 20 328 IN bad broadcast dc0 @0:1 p 10.0.10.1,1320 - 69.147.83.34,80 PR tcp len 20 48 -S IN fxp0 @0:2 p 177.99.209.140,1320 - 69.147.83.34,80 PR tcp len 20 48 -S OUT NAT 10.0.10.1 is the laptop in the lan. 10.2.0.1 is being sent by time warner I can not understand why I am getting the IN bad NAT The webpage loaded ok on the lan laptop. I have been using ipfilter since release 3.2 and this is the first isp i ever got this kind of problem with. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFilter and IPMon logging to syslog
On Tue, Mar 1, 2011 at 8:38 PM, Dean E. Weimer dwei...@dweimer.net wrote: I have been doing some work with cleaning up my log files to make them easier to read, and for the life of me can't figure out how to get my IPFilter logs to stop going into the /var/log/messages log. I have a syslog entry for local0.* /var/log/ipfilter.log which works great, and captures all the logs I want. I have tried adding local0.none on the /var/log/messages line, but it seems to have no effect. Can anyone tell me what I am doing wrong here, the below lines are from my syslog.conf configuration file. *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local0.none /var/log/messages local0.* /var/log/ipfilter.log I usually do it this way: !-local0 # disable logging of local0 [log whatever] /var/log/messages !local0 # enable logging of local0 local0.* /var/log/ipfilter.log Regards, -- Nino ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFilter and IPMon logging to syslog
On Wed, 02 Mar 2011 12:23:27 +0100, Bernt Hansson wrote: Put this in your rc.conf ipmon_flags=-D -f /var/log/ipf.log I don't doubt that would work, but I would rather stick with using syslogd to handle the logging. As I am hoping to implement remote logging to another server for log consolidation of several servers, which is why I started the process of cleaning up the local logs. --- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: IPFilter and IPMon logging to syslog
On Wed, 2 Mar 2011 09:34:39 +0100, n j wrote: On Tue, Mar 1, 2011 at 8:38 PM, Dean E. Weimer wrote: I have been doing some work with cleaning up my log files to make them easier to read, and for the life of me can't figure out how to get my IPFilter logs to stop going into the /var/log/messages log. I have a syslog entry for local0.* /var/log/ipfilter.log which works great, and captures all the logs I want. I have tried adding local0.none on the /var/log/messages line, but it seems to have no effect. Can anyone tell me what I am doing wrong here, the below lines are from my syslog.conf configuration file. *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local0.none /var/log/messages local0.* /var/log/ipfilter.log I usually do it this way: !-local0 # disable logging of local0 [log whatever] /var/log/messages !local0 # enable logging of local0 local0.* /var/log/ipfilter.log Regards, -- Nino ___ freebsd-questions@freebsd.org [2] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions [3] To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org [4] Interesting method, I will keep this in mind for the future. One thing to note, my config above seems to have started working after the messages log rotated. I had restarted the syslog process by running /etc/rc.d/syslogd restart, but for some reason these messages continued until the newsyslog process rotated the messages file. Now to get the rest of my servers local logs cleaned up and implement a new server for log consolidation. --- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
IPFilter and IPMon logging to syslog
I have been doing some work with cleaning up my log files to make them easier to read, and for the life of me can't figure out how to get my IPFilter logs to stop going into the /var/log/messages log. I have a syslog entry for local0.* /var/log/ipfilter.log which works great, and captures all the logs I want. I have tried adding local0.none on the /var/log/messages line, but it seems to have no effect. Can anyone tell me what I am doing wrong here, the below lines are from my syslog.conf configuration file. *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err;local0.none /var/log/messages local0.* /var/log/ipfilter.log -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter rules question
I'm using ipfilter on -current. Here's a fragment of the outgoing rules: # ipfstat -on *skip* @14 pass out quick on bge0 proto udp from any to any port = 8649 keep state *skip* @18 pass out log first quick on bge0 all And I see these ipmon entries in /var/log/ipfilter.log: ipmon[765]: 00:01:04.242290 bge0 @0:18 p 137.222.187.221,10280 - 239.2.11.71,8649 PR udp len 20 96 OUT multicast ipmon[765]: 00:01:09.702391 5x bge0 @0:18 p 137.222.187.221,10280 - 239.2.11.71,8649 PR udp len 20 92 OUT multicast ipmon[765]: 00:01:24.062025 7x bge0 @0:18 p 137.222.187.221,10280 - 239.2.11.71,8649 PR udp len 20 92 OUT multicast I don't understand why these packets are not sent via rule 14. Is rule 14 not matched? Or I'm missing someting else? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter unwanted blocking
Hi, I use FreeBSD 7.2-RELEASE with IPFilter used as proxy server for our LAN. I have following rules for external interface: block in log on rl0 all head 100 block out log on rl0 all head 200 pass out quick proto udp from a.b.c.d/32 to any keep state group 200 pass out quick proto tcp from a.b.c.d/32 to any flags S/SA keep state keep frags group 200 All works but sometimes IPF block all (or most of them) packets to ports 80 and 53 for about 2-3 up to 40-50 s. After this IPF returns to normal operation. How to investigate this problem? I tried remove flags and keep frags but without success. No regularity. Is this a IPF problem, wrong packages or kernel settings? Any idea? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter nat redirect udp packets
Have this nat rule rdr rl0 0.0.0.0/0 port 6355 - 10.0.10.3 port 6355 I can see in the log that tcp packets are being redirected but udp packets are not. Can not find any verbiage in man 5 0r 8 ipnat that states rdr rule only matches on tcp packets. I thought tcp/udp packets should be redirected? Can anyone clarify this? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter nat redirect udp packets
Have this nat rule rdr rl0 0.0.0.0/0 port 6355 - 10.0.10.3 port 6355 I can see in the log that tcp packets are being redirected but udp packets are not. Can not find any verbiage in man 5 0r 8 ipnat that states rdr rule only matches on tcp packets. I thought tcp/udp packets should be redirected? Can anyone clarify this? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ioctl (SIOCIPFL6): input/output error. when start ipfilter at freebsd 7.2 x64
This is my freebsd 7.2: [code] FreeBSD fbsd.test.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon Aug 3 06:40:56 UTC 2009 r...@vfbsd.shstorm.com:/usr/src/sys/amd64/compile/kernel_IPF amd64 [/code] In kenrel_IPF, I add these lines: [code] options IPFILTER options IPFILTER_LOG [/code] Add these lines in /etc/rc.conf: [code] ipfilter_enable=YES ipfilter_program=/sbin/ipf ipfilter_rules=/etc/ipf.rules ipfilter_flags=-D ipmon_enable=YES ipmon_flags=-D /var/log/ipfilter.log [/code] This is /etc/ipf.rules: [code] pass out quick on lo0 all pass in quick on lo0 all block in on re0 all block out on re0 all block in log quick all with short block in log quick all with ipopts block in log quick all with frag block in log quick all with opt lsrr block in log quick all with opt ssrr pass in on re0 proto tcp from any to any port = 80 flags S/SA keep state pass in on re0 proto tcp from any to any port = 22 flags S/SA keep state pass in on re0 proto tcp from any to any port = ftp flags S/SA keep state pass in on re0 proto tcp from any to any port = ftp-data flags S/SA keep state pass in on re0 proto tcp from any to any port 3 50001 flags S/SA keep state [/code] When start system, it shows some error messages: [code] .. Enabling ipfilter ioctl (SIOCIPFL6): input/output error. .. [/code] Who can help me? -- View this message in context: http://www.nabble.com/%22ioctl-%28SIOCIPFL6%29%3A-input-output-error.%22-when-start-ipfilter-at-freebsd-7.2-x64-tp24787848p24787848.html Sent from the freebsd-questions mailing list archive at Nabble.com. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ipfilter, ipnat, and if driver ath: what's just changed?
updating my system friday from the feb 7 version of 7.1 to the latest broke tcp and udp (but *not* icmp) over ipnat, which had worked forever with my current ipfilter rules and ipnat mapping rules, which are pretty simple. what has changed? /etc/ipnat.rules: map age0 10.0.0.0/24 - external ip/32 @ the top of /etc/ipf.rules: pass out quick on age0 proto tcp/udp from any to any keep state keep frags pass out quick on age0 proto icmp from any to any keep state keep frags that used to work. now it doesn't, witness ipmon: 01/03/2009 13:07:46.274707 age0 @0:28 b 74.125.93.102,80 - 10.0.0.253,2914 PR tcp len 20 48 -AS IN NAT what's changed? ipf? ipnat? age? am i using an obsolete therefore unworkable set of ipfilter rules? icmp still works, btw. i'd be grateful for any help. thx. david coder network engineer emeritus ntt/verio ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ipfilter, ipnat, and if driver ath [should have been age]: what's just changed?
+++ dacoder [01/03/09 13:17 -0500]: updating my system friday from the feb 7 version of 7.1 to the latest broke tcp and udp (but *not* icmp) over ipnat, which had worked forever with my current ipfilter rules and ipnat mapping rules, which are pretty simple. what has changed? /etc/ipnat.rules: map age0 10.0.0.0/24 - external ip/32 @ the top of /etc/ipf.rules: pass out quick on age0 proto tcp/udp from any to any keep state keep frags pass out quick on age0 proto icmp from any to any keep state keep frags that used to work. now it doesn't, witness ipmon: 01/03/2009 13:07:46.274707 age0 @0:28 b 74.125.93.102,80 - 10.0.0.253,2914 PR tcp len 20 48 -AS IN NAT what's changed? ipf? ipnat? age? am i using an obsolete therefore unworkable set of ipfilter rules? icmp still works, btw. i'd be grateful for any help. thx. david coder network engineer emeritus ntt/verio ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org i meant, of course, age, not ath in my subject line. sorry for the confusion. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: IPFilter section in Handbook needs updating
First, thanks for your work on writing the section in the handbook, its greatly appreciated. The updates about where ipmon logging to local0 looks good. Not sure whether or not you want to change the bumping the syslogd using the ps and kill commands as /etc/rc.d/syslogd reload does work, and would be easier for someone that is just learning how everything works. Thanks, Dean Weimer Network Administrator Orscheln Management Co -Original Message- From: Fbsd1 [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2008 9:05 PM To: [EMAIL PROTECTED] Cc: freebsd-questions@freebsd.org; Dean Weimer Subject: Re: IPFilter section in Handbook needs updating G magicman wrote: And incomplete yes i agree that the doc does need to be updated and examples (more) need to be added. --- On Fri, 12/5/08, Dean Weimer [EMAIL PROTECTED] wrote: From: Dean Weimer [EMAIL PROTECTED] Subject: IPFilter section in Handbook needs updating To: freebsd-questions@freebsd.org Date: Friday, December 5, 2008, 10:07 AM I was just setting up ipfilter and ipmon on a FreeBSD 7 server, and noticed that the ipmon and syslog information under the ipfilter section of the handbook is incorrect. The section reads: -snip- 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in -Ds mode uses security as the facility name. All IPMON logged data goes to security The following levels can be used to further segregate the logged data if desired: LOG_INFO - packets logged using the log keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short To setup IPFILTER to log all data to /var/log/ipfilter.log, you will need to create the file. The following command will do that: # touch /var/log/ipfilter.log The syslog function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to /etc/syslog.conf: security.* /var/log/ipfilter.log The security.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log you just created above. -snip- In trying to configure this I found that ipmon -Dsa doesn't log to security, but logs to local0 instead. Reading the man page for ipmon does in fact state this. However it also list the -L option as being able to change this default behavior, I tried ipmon -DSa -L security, it excepts this, but doesn't actually change the logging to use security. It still only outputs to the syslog using local0, I also tried using ipmon -DSa -L local7 as well, still outputs to local0. It was easy enough to modify my syslog.conf to output the local0.* as well as security.* to the /var/log/security file. However it would be greatly appreciated if someone that actually understands what's going on here could get this info updated. It would have saved me some time, as well as I am sure some other people in the future. Of course it's always possible I am missing something simple here that is causing this discrepancy, please do inform me if I did. It's probably worth mentioning that I am starting ipmon using the rc.conf file with ipmon_enable=YES and ipmon_flags=-DSa, just in case the /etc/rc.d/ipmon script actually changes the default behavior of ipmon in some way, though I didn't see anything in it that should. And ps wwaux | grep ipmon does display the process running with the flags exactly as stated on the ipmon_flags line of the /etc/rc.conf file. Thanks, Dean Weimer Network Administrator Orscheln Management Co I wrote that whole firewall handbook section. How is the following for complete replacement of the 31.5.7 IPMON Logging section? 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called 'facility' and 'level'. IPMON in -Ds mode uses local0 as the 'facility' name. All IPMON logged data goes to local0. You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory. First allocate the new named log file for the IPFMON logged data. touch /var/log/ipfilter.log # will allocate the file The syslog function is controlled by definition statements in the /etc/syslog.conf file. You will have to edit the /etc
Re: IPFilter section in Handbook needs updating
G magicman wrote: And incomplete yes i agree that the doc does need to be updated and examples (more) need to be added. --- On Fri, 12/5/08, Dean Weimer [EMAIL PROTECTED] wrote: From: Dean Weimer [EMAIL PROTECTED] Subject: IPFilter section in Handbook needs updating To: freebsd-questions@freebsd.org Date: Friday, December 5, 2008, 10:07 AM I was just setting up ipfilter and ipmon on a FreeBSD 7 server, and noticed that the ipmon and syslog information under the ipfilter section of the handbook is incorrect. The section reads: -snip- 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in -Ds mode uses security as the facility name. All IPMON logged data goes to security The following levels can be used to further segregate the logged data if desired: LOG_INFO - packets logged using the log keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short To setup IPFILTER to log all data to /var/log/ipfilter.log, you will need to create the file. The following command will do that: # touch /var/log/ipfilter.log The syslog function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to /etc/syslog.conf: security.* /var/log/ipfilter.log The security.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log you just created above. -snip- In trying to configure this I found that ipmon -Dsa doesn't log to security, but logs to local0 instead. Reading the man page for ipmon does in fact state this. However it also list the -L option as being able to change this default behavior, I tried ipmon -DSa -L security, it excepts this, but doesn't actually change the logging to use security. It still only outputs to the syslog using local0, I also tried using ipmon -DSa -L local7 as well, still outputs to local0. It was easy enough to modify my syslog.conf to output the local0.* as well as security.* to the /var/log/security file. However it would be greatly appreciated if someone that actually understands what's going on here could get this info updated. It would have saved me some time, as well as I am sure some other people in the future. Of course it's always possible I am missing something simple here that is causing this discrepancy, please do inform me if I did. It's probably worth mentioning that I am starting ipmon using the rc.conf file with ipmon_enable=YES and ipmon_flags=-DSa, just in case the /etc/rc.d/ipmon script actually changes the default behavior of ipmon in some way, though I didn't see anything in it that should. And ps wwaux | grep ipmon does display the process running with the flags exactly as stated on the ipmon_flags line of the /etc/rc.conf file. Thanks, Dean Weimer Network Administrator Orscheln Management Co I wrote that whole firewall handbook section. How is the following for complete replacement of the 31.5.7 IPMON Logging section? 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called ‘facility’ and ‘level’. IPMON in –Ds mode uses local0 as the ‘facility’ name. All IPMON logged data goes to local0. You have to manually configure the /etc/syslog.conf file by adding the statements to direct the Local0 'facility' to the log file name recording the log records. FBSD keeps all of its syslog files in /var/log/ directory. First allocate the new named log file for the IPFMON logged data. touch /var/log/ipfilter.log # will allocate the file The syslog function is controlled by definition statements in the /etc/syslog.conf file. You will have to edit the /etc/syslog.conf file. Add the following statement to syslog.conf: local0.* /var/log/ipfilter.log The local0.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by kill –HUP pid. You get the pid (IE: process number) by listing the tasks with the ps ax command. Find syslog in the display and the pid number is the number in the left column. Don’t forget to change /etc/newsyslog.conf to rotate the new named IPFILTER log you just created above. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail
IPFilter section in Handbook needs updating
I was just setting up ipfilter and ipmon on a FreeBSD 7 server, and noticed that the ipmon and syslog information under the ipfilter section of the handbook is incorrect. The section reads: -snip- 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in -Ds mode uses security as the facility name. All IPMON logged data goes to security The following levels can be used to further segregate the logged data if desired: LOG_INFO - packets logged using the log keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short To setup IPFILTER to log all data to /var/log/ipfilter.log, you will need to create the file. The following command will do that: # touch /var/log/ipfilter.log The syslog function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to /etc/syslog.conf: security.* /var/log/ipfilter.log The security.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log you just created above. -snip- In trying to configure this I found that ipmon -Dsa doesn't log to security, but logs to local0 instead. Reading the man page for ipmon does in fact state this. However it also list the -L option as being able to change this default behavior, I tried ipmon -DSa -L security, it excepts this, but doesn't actually change the logging to use security. It still only outputs to the syslog using local0, I also tried using ipmon -DSa -L local7 as well, still outputs to local0. It was easy enough to modify my syslog.conf to output the local0.* as well as security.* to the /var/log/security file. However it would be greatly appreciated if someone that actually understands what's going on here could get this info updated. It would have saved me some time, as well as I am sure some other people in the future. Of course it's always possible I am missing something simple here that is causing this discrepancy, please do inform me if I did. It's probably worth mentioning that I am starting ipmon using the rc.conf file with ipmon_enable=YES and ipmon_flags=-DSa, just in case the /etc/rc.d/ipmon script actually changes the default behavior of ipmon in some way, though I didn't see anything in it that should. And ps wwaux | grep ipmon does display the process running with the flags exactly as stated on the ipmon_flags line of the /etc/rc.conf file. Thanks, Dean Weimer Network Administrator Orscheln Management Co ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFilter section in Handbook needs updating
On Dec 5, 2008, at 7:07 AM, Dean Weimer wrote: I was just setting up ipfilter and ipmon on a FreeBSD 7 server, and noticed that the ipmon and syslog information under the ipfilter section of the handbook is incorrect. A couple of years back, I submitted a one liner to some email address of a documentation maintainer. I just looked on the site and couldn't find this address. Instead, it said if you have a change, it suggested putting in a PR. It sounds like it you should create a diff of the current wording and your recommended change. Here is where I was looking: http://www.freebsd.org/docproj/submitting.html The section reads: -snip- 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in -Ds mode uses security as the facility name. All IPMON logged data goes to security The following levels can be used to further segregate the logged data if desired: LOG_INFO - packets logged using the log keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short To setup IPFILTER to log all data to /var/log/ipfilter.log, you will need to create the file. The following command will do that: # touch /var/log/ipfilter.log The syslog function is controlled by definition statements in the / etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to /etc/syslog.conf: security.* /var/log/ipfilter.log The security.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by running /etc/ rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log you just created above. -snip- In trying to configure this I found that ipmon -Dsa doesn't log to security, but logs to local0 instead. Reading the man page for ipmon does in fact state this. However it also list the -L option as being able to change this default behavior, I tried ipmon -DSa - L security, it excepts this, but doesn't actually change the logging to use security. It still only outputs to the syslog using local0, I also tried using ipmon -DSa -L local7 as well, still outputs to local0. It was easy enough to modify my syslog.conf to output the local0.* as well as security.* to the /var/log/security file. However it would be greatly appreciated if someone that actually understands what's going on here could get this info updated. It would have saved me some time, as well as I am sure some other people in the future. Of course it's always possible I am missing something simple here that is causing this discrepancy, please do inform me if I did. It's probably worth mentioning that I am starting ipmon using the rc.conf file with ipmon_enable=YES and ipmon_flags=-DSa, just in case the /etc/rc.d/ipmon script actually changes the default behavior of ipmon in some way, though I didn't see anything in it that should. And ps wwaux | grep ipmon does display the process running with the flags exactly as stated on the ipmon_flags line of the /etc/rc.conf file. Thanks, Dean Weimer Network Administrator Orscheln Management Co ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFilter section in Handbook needs updating
And incomplete yes i agree that the doc does need to be updated and examples (more) need to be added. --- On Fri, 12/5/08, Dean Weimer [EMAIL PROTECTED] wrote: From: Dean Weimer [EMAIL PROTECTED] Subject: IPFilter section in Handbook needs updating To: freebsd-questions@freebsd.org Date: Friday, December 5, 2008, 10:07 AM I was just setting up ipfilter and ipmon on a FreeBSD 7 server, and noticed that the ipmon and syslog information under the ipfilter section of the handbook is incorrect. The section reads: -snip- 31.5.7 IPMON Logging Syslogd uses its own special method for segregation of log data. It uses special groupings called facility and level. IPMON in -Ds mode uses security as the facility name. All IPMON logged data goes to security The following levels can be used to further segregate the logged data if desired: LOG_INFO - packets logged using the log keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed LOG_WARNING - packets logged which are also blocked LOG_ERR - packets which have been logged and which can be considered short To setup IPFILTER to log all data to /var/log/ipfilter.log, you will need to create the file. The following command will do that: # touch /var/log/ipfilter.log The syslog function is controlled by definition statements in the /etc/syslog.conf file. The syslog.conf file offers considerable flexibility in how syslog will deal with system messages issued by software applications like IPF. Add the following statement to /etc/syslog.conf: security.* /var/log/ipfilter.log The security.* means to write all the logged messages to the coded file location. To activate the changes to /etc/syslog.conf you can reboot or bump the syslog task into re-reading /etc/syslog.conf by running /etc/rc.d/syslogd reload Do not forget to change /etc/newsyslog.conf to rotate the new log you just created above. -snip- In trying to configure this I found that ipmon -Dsa doesn't log to security, but logs to local0 instead. Reading the man page for ipmon does in fact state this. However it also list the -L option as being able to change this default behavior, I tried ipmon -DSa -L security, it excepts this, but doesn't actually change the logging to use security. It still only outputs to the syslog using local0, I also tried using ipmon -DSa -L local7 as well, still outputs to local0. It was easy enough to modify my syslog.conf to output the local0.* as well as security.* to the /var/log/security file. However it would be greatly appreciated if someone that actually understands what's going on here could get this info updated. It would have saved me some time, as well as I am sure some other people in the future. Of course it's always possible I am missing something simple here that is causing this discrepancy, please do inform me if I did. It's probably worth mentioning that I am starting ipmon using the rc.conf file with ipmon_enable=YES and ipmon_flags=-DSa, just in case the /etc/rc.d/ipmon script actually changes the default behavior of ipmon in some way, though I didn't see anything in it that should. And ps wwaux | grep ipmon does display the process running with the flags exactly as stated on the ipmon_flags line of the /etc/rc.conf file. Thanks, Dean Weimer Network Administrator Orscheln Management Co ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd6.2-stable + ipfilter + policy routing mbuf leak
Hi all, I have a server running 6.2-stable that experiences mbuf leakage if I perform policy routing with ipfilter. This is independent of the hardware as I have moved the disk to a different machine with different MB, NICs etc and had the same result. The server is running quagga, postfix and ipfilter for some basic firewalling. The policy routing was to route outgoing web traffic to a second internet link. I have been running the same setup for several years on a 4.11 machine without any problems. Can anyone confirm this problem? Cheers, Colin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange problem of ipfilter
Hallo, I got strange problem ipfilter on FreeBSD 6.2-STABLE. After uptime my machine running 7 days until 10 days, I can't access DNS, sometime SSH, and etc, to my box, but this happen randomly. For example I've rule like this: # SSH pass in quick on rl0 proto tcp from 192.168.0.0/24 to 192.168.0.100/32 port = 22 keep state # DNS pass in quick proto udp from 192.168.0.0/24 to 192.168.0.100/32 port = 53 keep state Whereis: 192.168.0.0/24 my client block ip, 192.168.0.200/32 ip box running ipfilter. I try to create rule: pass in all pass out all Then reload ipfilter rule. Or I try to restart my machine with my default rule. So everything gone be alright. FYI, I use: root:~# ipf -V ipf: IP Filter: v4.1.13 (416) Kernel: IP Filter: v4.1.13 Running: yes Log Flags: 0 = none set Default: block all, Logging: available Active list: 0 Feature mask: 0xa root:~# uname -srm FreeBSD 6.2-STABLE i386 I do compile ipfilter with default block in kernel configuration. This night I'll try to make world my FreeBSD box and I hope FreeBSD's commiter already revision with this bug. Would you give some clue to fix this problem. Thanks you for your help. TIA -- budsz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter and DHCP
Ok...what do you guys do to handle a change of IP/network via DHCP with ipfilter? I have been told that if my IP changes while the machine is up and running that ipfilter WON'T see this change and needs to be told...supposedly it only reads the IP when it starts itself. If this is true, is there any easy way to fix this? I run ipcheck.py and that can invoke a script if needed if it notices and IP changed ipnat.conf: map bge1 192.43.82.0/24 - 0/32 proxy port ftp ftp/tcp map bge1 192.43.82.0/24 - 0/32 portmap tcp/udp auto map bge1 192.43.82.0/24 - 0/32 rdr bge1 0.0.0.0/0 port 25 - 192.43.82.170 port 25 I presume if it reads the IP and fills in the '0/32' + '0.0.0.0/0' values at startup...having my IP change could be disasterous. thanks for any tips- -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter and DHCP
J.D. Bronson [EMAIL PROTECTED] writes: Ok...what do you guys do to handle a change of IP/network via DHCP with ipfilter? I have been told that if my IP changes while the machine is up and running that ipfilter WON'T see this change and needs to be told...supposedly it only reads the IP when it starts itself. If this is true, is there any easy way to fix this? I run ipcheck.py and that can invoke a script if needed if it notices and IP changed ipnat.conf: map bge1 192.43.82.0/24 - 0/32 proxy port ftp ftp/tcp map bge1 192.43.82.0/24 - 0/32 portmap tcp/udp auto map bge1 192.43.82.0/24 - 0/32 rdr bge1 0.0.0.0/0 port 25 - 192.43.82.170 port 25 I presume if it reads the IP and fills in the '0/32' + '0.0.0.0/0' values at startup...having my IP change could be disasterous. When your IP changes, you can have dhclient trigger a script of your choosing. You can use that to alter your firewall rules. There are probably other approaches too. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter and DHCP
On Tue, 10 Apr 2007 15:26:36 -0400 Lowell Gilbert [EMAIL PROTECTED] wrote: J.D. Bronson [EMAIL PROTECTED] writes: Ok...what do you guys do to handle a change of IP/network via DHCP with ipfilter? I have been told that if my IP changes while the machine is up and running that ipfilter WON'T see this change and needs to be told...supposedly it only reads the IP when it starts itself. If this is true, is there any easy way to fix this? I run ipcheck.py and that can invoke a script if needed if it notices and IP changed ipnat.conf: map bge1 192.43.82.0/24 - 0/32 proxy port ftp ftp/tcp map bge1 192.43.82.0/24 - 0/32 portmap tcp/udp auto map bge1 192.43.82.0/24 - 0/32 rdr bge1 0.0.0.0/0 port 25 - 192.43.82.170 port 25 I presume if it reads the IP and fills in the '0/32' + '0.0.0.0/0' values at startup...having my IP change could be disasterous. When your IP changes, you can have dhclient trigger a script of your choosing. You can use that to alter your firewall rules. Does it matter though? # rcorder /etc/rc.d/* |egrep ipfil|dhc /etc/rc.d/ipfilter /etc/rc.d/dhclient ipfilter doesn't actually have an ip address for the interface when it starts up, so it seem unlikely it can't cope with a new address. It wouldn't hurt to do an /etc/rc.d/ipfilter resync though ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvement to IPFilter / nfsd in FBSD (6.2+?)
Garrett Cooper : Hello, Just wondering if anyone has IPFilter / nfsd setup properly on their boxes with any beta versions of FBSD. I am having loads of issues transferring large files (~300MB apiece) or issues transferring a large number of smaller files (3MB ~ 10MB apiece) from a FBSD 6.1 client to a FBSD 6.1 server, where it transfers part of the files, then cp / mv get stuck indefinitely on the client system. The stuck cp / mv processes cause the client to hang on reboot, and then terminate before all of the buffers are written to disk (which forces fsck on next boot). Did you try to use tcp transport with NFS ? See the '-T' option of mount_nfs(8). See also the -i option (Make the mount interruptible). Regards. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Improvement to IPFilter / nfsd in FBSD (6.2+?)
Just wondering if anyone has IPFilter / nfsd setup properly on their boxes with any beta versions of FBSD. I am having loads of issues transferring large files (~300MB apiece) or issues transferring a large number of smaller files (3MB ~ 10MB apiece) from a FBSD 6.1 client to a FBSD 6.1 server, where it transfers part of the files, then cp / mv get stuck indefinitely on the client system. The stuck cp / mv processes cause the client to hang on reboot, and then terminate before all of the buffers are written to disk (which forces fsck on next boot). Also if you suggest 7-CURRENT, what's the CVS tag for that version? -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvement to IPFilter / nfsd in FBSD (6.2+?)
On Jan 11, 2007, at 10:58 AM, Garrett Cooper wrote: Just wondering if anyone has IPFilter / nfsd setup properly on their boxes with any beta versions of FBSD. It is typically not useful to implement firewall rules between NFS servers and legitimate NFS clients. The large number of RPC services using randomly assigned ports needed by NFS and the fact that machines which trust each other enough to permit filesharing and generally utilize a common set of directory services to keep the user/group mappings synced mean that the NFS server clients should be considered in the same trust domain in most cases. Also if you suggest 7-CURRENT, what's the CVS tag for that version? The HEAD of the CVS tree (aka .). Updating the 7-CURRENT won't have any affect upon firewall configuration for NFS, however. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Firewalls and RPC (was Re: Improvement to IPFilter / nfsd in FBSD (6.2+?))
Chuck Swiger wrote: On Jan 11, 2007, at 10:58 AM, Garrett Cooper wrote: Just wondering if anyone has IPFilter / nfsd setup properly on their boxes with any beta versions of FBSD. It is typically not useful to implement firewall rules between NFS servers and legitimate NFS clients. The large number of RPC services using randomly assigned ports needed by NFS and the fact that machines which trust each other enough to permit filesharing and generally utilize a common set of directory services to keep the user/group mappings synced mean that the NFS server clients should be considered in the same trust domain in most cases. Right, ok. I suppose I was just being lazy/trying to blanket support all machines on my subnet without having to delve into individual hosts, but that makes perfect sense. rpcbind (and RPC in general) strictly uses ports under 1023--assuming that there are enough allocatable ports available for each RPC service in the port range 1-1023--if running as root, does it not? Does the same rationale apply for Samba? That's part of the reason why I'm concerned with running a firewall.. I run smbd/nmbd on the server machine. Either that, or I could switch to another firewall setup (albeit it'd be sort of a pain). Does ipfw / pf work better with RPC than IPFilter? Also if you suggest 7-CURRENT, what's the CVS tag for that version? The HEAD of the CVS tree (aka .). Updating the 7-CURRENT won't have any affect upon firewall configuration for NFS, however. Right. I was just going to see if there was any improvement in how things were implemented in 7-CURRENT, because maybe the issues that I'm encountering had been 'solved' in 7-CURRENT (although I would probably have more issues with core kernel items as they're under heavy development it appears given traffic on the current@ list). Thanks Chuck! -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewalls and RPC (was Re: Improvement to IPFilter / nfsd in FBSD (6.2+?))
On Jan 11, 2007, at 12:54 PM, Garrett Cooper wrote: It is typically not useful to implement firewall rules between NFS servers and legitimate NFS clients. The large number of RPC services using randomly assigned ports needed by NFS and the fact that machines which trust each other enough to permit filesharing and generally utilize a common set of directory services to keep the user/group mappings synced mean that the NFS server clients should be considered in the same trust domain in most cases. Right, ok. I suppose I was just being lazy/trying to blanket support all machines on my subnet without having to delve into individual hosts, but that makes perfect sense. rpcbind (and RPC in general) strictly uses ports under 1023--assuming that there are enough allocatable ports available for each RPC service in the port range 1-1023--if running as root, does it not? Actually, no. While rpcbind/portmap/portmapper is assigned to 111/ tcp udp, most other RPC services get assigned high port numbers in the 327xx range, but that varies considerably from platform to platform. Does the same rationale apply for Samba? That's part of the reason why I'm concerned with running a firewall.. I run smbd/nmbd on the server machine. Somewhat, yes. Samba/CIFS filesharing can require less trust between server and client as accessing a Samba share does not require superuser permissions, just limited user access, but Samba does require root access to start up and bind to the low ports it uses, and it also involves the network browse master (which nmbd can do) and so forth which involve subnet-oriented broadcast traffic. Samba/CIFS is a chatty protocol. Either that, or I could switch to another firewall setup (albeit it'd be sort of a pain). Does ipfw / pf work better with RPC than IPFilter? No, not really. What you probably want to focus on is protecting your entire subnet, including the fileserver and clients, from malicious traffic via your Internet link(s), and then worry about egress filtering, dividing your machines into a trusted internal LAN and a semi-trusted DMZ, and so forth. A firewall system should not be running any kind of filesharing; while you can run PF, IPFW, etc on your fileserver, that ought to be a secondary line of protection for defense in depth, and your Internet connection ought to have a dual-homed or multihomed firewall machine which is dedicated to that role and which runs zero services. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewalls and RPC (was Re: Improvement to IPFilter / nfsd in FBSD (6.2+?))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Swiger wrote: Actually, no. While rpcbind/portmap/portmapper is assigned to 111/tcp udp, most other RPC services get assigned high port numbers in the 327xx range, but that varies considerably from platform to platform. True. NFS is port 2049 by default, anyhow.. Somewhat, yes. Samba/CIFS filesharing can require less trust between server and client as accessing a Samba share does not require superuser permissions, just limited user access, but Samba does require root access to start up and bind to the low ports it uses, and it also involves the network browse master (which nmbd can do) and so forth which involve subnet-oriented broadcast traffic. Samba/CIFS is a chatty protocol. No kidding. The funny thing is that smbclient (Xbox Media Center runs smbclient) I've learned requires more open ports than regular CIFS enabled Windows XP hosts to RPC services, which has caused more issues than it's worth in the past. No, not really. What you probably want to focus on is protecting your entire subnet, including the fileserver and clients, from malicious traffic via your Internet link(s), and then worry about egress filtering, dividing your machines into a trusted internal LAN and a semi-trusted DMZ, and so forth. A firewall system should not be running any kind of filesharing; while you can run PF, IPFW, etc on your fileserver, that ought to be a secondary line of protection for defense in depth, and your Internet connection ought to have a dual-homed or multihomed firewall machine which is dedicated to that role and which runs zero services. Right. However, I don't trust the rest of the clients on my subnet other than the ones I maintain, so that's why I have setup the firewall rules I have. Sorry for not more clearly defining the situation earlier, but here's the reasoning / rationale for what I'm doing.. IT nightmare - -I live in a house with a shared LAN with a total of around 50 hosts connected / disconnected at various times of the day. - -I don't trust any of the Windows clients devoid a small handful because I have had a variety of connectivity problems caused by improperly managed personal machines, virii, and spyware on machines here. - -There isn't a real means of properly controlling IP distribution and people are free to change their IP addresses to whatever they choose (host information is set statically, not dynamically). - -I have 5 machines which have access to the network--2 serving machines and 3 clients which aren't always attached to the network. I have set the IP addresses up so they all lie in a range, but I don't trust whether someone will IP squat my address and do whatever they want to my serving machines (whether they mean to or it happens by accident). - -Some of the machines on the network have access to the machine serving via Samba, but that's a limited number. /IT nightmare - -Garrett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFprE4EnKyINQw/HARAjwyAKCY9F8O2rkdet2/gxNNqCQXij0xgwCfSF3/ tswDC5ovt0A5r3Tg7s7BSqE= =iVhr -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewalls and RPC (was Re: Improvement to IPFilter / nfsd in FBSD (6.2+?))
On Jan 11, 2007, at 1:50 PM, Garrett Cooper wrote: Actually, no. While rpcbind/portmap/portmapper is assigned to 111/ tcp udp, most other RPC services get assigned high port numbers in the 327xx range, but that varies considerably from platform to platform. True. NFS is port 2049 by default, anyhow.. Good example, yet this is true on some platforms but not on others. A firewall system should not be running any kind of filesharing; while you can run PF, IPFW, etc on your fileserver, that ought to be a secondary line of protection for defense in depth, and your Internet connection ought to have a dual-homed or multihomed firewall machine which is dedicated to that role and which runs zero services. Right. However, I don't trust the rest of the clients on my subnet other than the ones I maintain, so that's why I have setup the firewall rules I have. You really don't want to mix machines which are trusted with machines which are not trusted on the same subnet. If you can't control which client machines get which IPs, you pretty much cannot use firewall rules to restrict filesharing only to the legit clients. Sorry for not more clearly defining the situation earlier, but here's the reasoning / rationale for what I'm doing.. IT nightmare - -I live in a house with a shared LAN with a total of around 50 hosts connected / disconnected at various times of the day. - -I don't trust any of the Windows clients devoid a small handful because I have had a variety of connectivity problems caused by improperly managed personal machines, virii, and spyware on machines here. - -There isn't a real means of properly controlling IP distribution and people are free to change their IP addresses to whatever they choose (host information is set statically, not dynamically). - -I have 5 machines which have access to the network--2 serving machines and 3 clients which aren't always attached to the network. I have set the IP addresses up so they all lie in a range, but I don't trust whether someone will IP squat my address and do whatever they want to my serving machines (whether they mean to or it happens by accident). - -Some of the machines on the network have access to the machine serving via Samba, but that's a limited number. Perhaps you should consider setting up your own private subnet for your machines, and having a firewall guarding access to your machines which performs static NAT for the set of five IP addresses you've made claim to. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Firewalls and RPC (was Re: Improvement to IPFilter / nfsd in FBSD (6.2+?))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Swiger wrote: snip You really don't want to mix machines which are trusted with machines which are not trusted on the same subnet. If you can't control which client machines get which IPs, you pretty much cannot use firewall rules to restrict filesharing only to the legit clients. Excellent point. snip Perhaps you should consider setting up your own private subnet for your machines, and having a firewall guarding access to your machines which performs static NAT for the set of five IP addresses you've made claim to. I'm really starting to think that'd be a good idea. Thanks again for the comments--it really helps. - -Garrett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFprRBEnKyINQw/HARAo8cAJ4sHIowqgCRbFMv6JDufsowxEDGGACePLKj NqyrOFDj6gbTQscMws0q6zg= =mDqk -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Quality of Services with FreeBSD NAT and IPFilter
Dear all, I have install one FreeBSD Firewall in my office and its running NATD and IPFilter now. My external Interface is connected to my ISP through Wimax PPPoE (256 kbps). I have install another PC for PC-to-Phone VoIP Call and there is no Internet Application running on that PC except Ring-Voiz Dialer. I have asked my ISP they said they already optimized the QoS for This VoIP Services already (Media ring), but my ISP backbone is locate in US and the server that I will connect to make call to Hong Kong and other asia countries in at Singapore (as I knew). Any ideas how to optimize my Gateway (FreeBSD/NATD/IPFilter) to ensure that it will reserv the bandwidth priority for my VoIP Application? Thanks for your comments. -- *Rithy Ray, RCSA* Chief Executive Officer Web: www.rithy4u.net http://www.rithy4u.net Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone: (855) 12 403 001 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Quality of Services with FreeBSD NAT and IPFilter
On Sat, 28 Oct 2006 08:59:40 +0700, in sentex.lists.freebsd.questions you wrote: Any ideas how to optimize my Gateway (FreeBSD/NATD/IPFilter) to ensure that it will reserv the bandwidth priority for my VoIP Application? You are better off using pf+ALTQ rather than mixing ipfilter and natd. If you want to use ipfilter (pf is better) than get rid of natd and use the built in ipnat in ipfilter. There are some good writeups around on pf and altq as well e.g. http://www.benzedrine.cx/pf.html and http://www.benzedrine.cx/ackpri.html ---Mike Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 [EMAIL PROTECTED], (http://www.tancsa.com) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter / ipnat /usr/sbin/ppp ?
using: ppp -ddial -nat profile How does the -nat flag implement nat for PPPoE ? Using ipfw/natd, ipnat/ipfilter, and is it hard-coded or can it be optionally changed? Can I use rules created for/through ipfilter/ipnat, or should I simply disable NAT translation on the ppp interface and enable it through ipnat on it's own? -- Nathan Vidican [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter / ipnat /usr/sbin/ppp ? (answered)
Answer found, NAT implemented using libalias library: man 3 libalias -- Nathan Vidican [EMAIL PROTECTED] On Wed, 18 Oct 2006 13:59:29 -0400, Nathan Vidican wrote using: ppp -ddial -nat profile How does the -nat flag implement nat for PPPoE ? Using ipfw/natd, ipnat/ipfilter, and is it hard-coded or can it be optionally changed? Can I use rules created for/through ipfilter/ipnat, or should I simply disable NAT translation on the ppp interface and enable it through ipnat on it's own? -- Nathan Vidican [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet in an IPFilter setup
Hiya,
Since freebsd-ipfw is dead and mostly for spammers, let me try my luck
here once more ;)
I am trying to prove a point to a customer - that he can save the cost
of expensive routing hardware by just having a FreeBSD box on their LAN.
Unfortunately, this also means that I need to spend days reading about
IPFW, which, sincerely, is not one of those firewall implementations
that is easy for me. I therefore need help to prove a point and keep
a customer..
The scenario:
I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
interfaces at the moment, external interface connected to the hostile
Internet and internal interface connected to a switch for the LAN.
The ISP gives 256Kbit/s on the external interface. Out of this, I
need to dedicate/guarantee 128Kbit/s to just one machine.
A streaming server has been introduced on the LAN, and it is considered
a VIP host as far as bandwidth allocation is concerned.
The problem is that p2p is also officially allowed on the LAN. I hate
it but it is allowed. Period. No argument about it.
I need to guarantee 128Kbit/s of the available bandwidth to the
streaming host (server, if you can call it).
My thinking/plan:
1. Add one more NIC to the FreeBSD box (it's also the router,
firewall, _everything_ server) and put this on a separate IP block.
To this NIC I will connect the VIP host, which needs the guaranteed
bandwidth. I will therefore NAT traffic to/from it.
2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
this means that:
(a) They cannot go beyond 128Kbit/s
(b) The VIP box will go above 128K/bit's in case the throttled
LAN is not using all of the 128Kbit/s
I need to control bandwidth on the external interface only, not on the
LAN (internal interfaces).
Is this rightful thinking or sheer imagination which is not practical?
My problem:
Most important is being dumb when it comes to IPFW and hence the pipes
and all that pertains to it.
Here is my ipfw configuration, in black and white (firewall_type=OPEN)
# Outside interface network and netmask and ip
oif=bfe0
iif=xl0
onet=62.8.68.0
omask=255.255.255.252
oip=62.8.68.22
# Inside interface network and netmask and ip
iif=xl0
inet=10.0.0.0
imask=255.255.255.0
iip=10.0.0.2
ipfw pipe 1 config bw 128Kbit/s
# Allow any traffic to or from my own net.
${fwcmd} add pass all from ${iip} to ${inet}:${imask}
${fwcmd} add pass all from ${inet}:${imask} to ${iip}
# Throttle now
ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif} state
${fwcmd} add 65000 pass all from any to any
With this configuration, it seems like even LAN-LAN communication is
being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
Can someone tell me why that is happening?
Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
bandwidth limitation configuration, is it not true that I will have
achieved my goal?
I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
have a static route for the VIP box, with NAT for any connections
to/from it.
I'll really appreciate any help/advise towards a perfect configuration
for the firewall, and how I can get this to work.
Thanks in advance.
-Wash
http://www.netmeister.org/news/learn2quote.html
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--
+==+
|\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED]
Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com
|,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922
'---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121
+==+
Minnie Mouse is a slow maze learner.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
In response to Odhiambo Washington [EMAIL PROTECTED]:
[snip]
The scenario:
I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
interfaces at the moment, external interface connected to the hostile
Internet and internal interface connected to a switch for the LAN.
The ISP gives 256Kbit/s on the external interface. Out of this, I
need to dedicate/guarantee 128Kbit/s to just one machine.
A streaming server has been introduced on the LAN, and it is considered
a VIP host as far as bandwidth allocation is concerned.
The problem is that p2p is also officially allowed on the LAN. I hate
it but it is allowed. Period. No argument about it.
I need to guarantee 128Kbit/s of the available bandwidth to the
streaming host (server, if you can call it).
My thinking/plan:
1. Add one more NIC to the FreeBSD box (it's also the router,
firewall, _everything_ server) and put this on a separate IP block.
To this NIC I will connect the VIP host, which needs the guaranteed
bandwidth. I will therefore NAT traffic to/from it.
2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
this means that:
(a) They cannot go beyond 128Kbit/s
(b) The VIP box will go above 128K/bit's in case the throttled
LAN is not using all of the 128Kbit/s
I need to control bandwidth on the external interface only, not on the
LAN (internal interfaces).
Is this rightful thinking or sheer imagination which is not practical?
Seems reasonable. See below ...
My problem:
Most important is being dumb when it comes to IPFW and hence the pipes
and all that pertains to it.
Here is my ipfw configuration, in black and white (firewall_type=OPEN)
# Outside interface network and netmask and ip
oif=bfe0
iif=xl0
onet=62.8.68.0
omask=255.255.255.252
oip=62.8.68.22
# Inside interface network and netmask and ip
iif=xl0
inet=10.0.0.0
imask=255.255.255.0
iip=10.0.0.2
ipfw pipe 1 config bw 128Kbit/s
# Allow any traffic to or from my own net.
${fwcmd} add pass all from ${iip} to ${inet}:${imask}
${fwcmd} add pass all from ${inet}:${imask} to ${iip}
# Throttle now
ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif} state
^^
Is this direct cut/paste? If so, you've got a sticky $ key.
${fwcmd} add 65000 pass all from any to any
With this configuration, it seems like even LAN-LAN communication is
being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
Can someone tell me why that is happening?
Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
bandwidth limitation configuration, is it not true that I will have
achieved my goal?
I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
have a static route for the VIP box, with NAT for any connections
to/from it.
I'll really appreciate any help/advise towards a perfect configuration
for the firewall, and how I can get this to work.
Thanks in advance.
--
Bill Moran
Collaborative Fusion Inc.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
Odhiambo Washington wrote: I need to control bandwidth on the external interface only, not on the LAN (internal interfaces). Is this rightful thinking or sheer imagination which is not practical? If you're happy with IPFilter and need to ensure minimum bandwidth for some network segment, take a look at packet filter, you can take much of your knowledge with you and then set up queues that will ensure the minimum bandwidth. And you don't need extra interfaces. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
* On 20/09/06 11:16 -0400, Bill Moran wrote:
| In response to Odhiambo Washington [EMAIL PROTECTED]:
|
| [snip]
|
| The scenario:
|
| I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
| interfaces at the moment, external interface connected to the hostile
| Internet and internal interface connected to a switch for the LAN.
|
| The ISP gives 256Kbit/s on the external interface. Out of this, I
| need to dedicate/guarantee 128Kbit/s to just one machine.
|
| A streaming server has been introduced on the LAN, and it is considered
| a VIP host as far as bandwidth allocation is concerned.
| The problem is that p2p is also officially allowed on the LAN. I hate
| it but it is allowed. Period. No argument about it.
|
| I need to guarantee 128Kbit/s of the available bandwidth to the
| streaming host (server, if you can call it).
|
|
| My thinking/plan:
|
| 1. Add one more NIC to the FreeBSD box (it's also the router,
|firewall, _everything_ server) and put this on a separate IP block.
|To this NIC I will connect the VIP host, which needs the guaranteed
|bandwidth. I will therefore NAT traffic to/from it.
|
| 2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
| this means that:
| (a) They cannot go beyond 128Kbit/s
| (b) The VIP box will go above 128K/bit's in case the throttled
| LAN is not using all of the 128Kbit/s
|
| I need to control bandwidth on the external interface only, not on the
| LAN (internal interfaces).
|
| Is this rightful thinking or sheer imagination which is not practical?
|
| Seems reasonable. See below ...
Thanks, Bill for that verification.
| My problem:
|
|
| Most important is being dumb when it comes to IPFW and hence the pipes
| and all that pertains to it.
|
| Here is my ipfw configuration, in black and white (firewall_type=OPEN)
|
|
| # Outside interface network and netmask and ip
| oif=bfe0
| iif=xl0
| onet=62.8.68.0
| omask=255.255.255.252
| oip=62.8.68.22
|
| # Inside interface network and netmask and ip
| iif=xl0
| inet=10.0.0.0
| imask=255.255.255.0
| iip=10.0.0.2
|
| ipfw pipe 1 config bw 128Kbit/s
|
| # Allow any traffic to or from my own net.
| ${fwcmd} add pass all from ${iip} to ${inet}:${imask}
| ${fwcmd} add pass all from ${inet}:${imask} to ${iip}
|
| # Throttle now
| ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif}
state
|^^
|
| Is this direct cut/paste? If so, you've got a sticky $ key.
Yes, it was a paste in the process of modifying ;)
Noted with thanks.
|
| ${fwcmd} add 65000 pass all from any to any
|
|
| With this configuration, it seems like even LAN-LAN communication is
| being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
| Can someone tell me why that is happening?
|
| Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
| bandwidth limitation configuration, is it not true that I will have
| achieved my goal?
|
| I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
| have a static route for the VIP box, with NAT for any connections
| to/from it.
|
|
| I'll really appreciate any help/advise towards a perfect configuration
| for the firewall, and how I can get this to work.
|
| Thanks in advance.
Bill, you did not say anything on my problem with intra-LAN traffic.
Does that mean this configuration is okay, and should not at all affect
traffic within the LAN?
Best regards,
Odhiambo Washington
Systems Admin,
Wananchi Online Ltd.
Are you hosting your domain name with the leaders??:
See http://webhosting.info/webhosts/tophosts/Country/KE
DISCLAIMER: See http://www.wananchi.com/bms/terms.php
--+-
Odhiambo WASHINGTON. WANANCHI ONLINE LTD (Nairobi, KE)
http://www.wananchi.com/email/ . 1ere Etage, Laptrust Plaza, Loita St.,
Mobile: (+254) 722 743 223 . # 10286, 00100 NAIROBI
--+-
Many are the plans in a man's heart,
but it is the Lord's purpose that prevails.
Proverbs 19:21
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
* On 20/09/06 17:16 +0200, Erik Norgaard wrote: | Odhiambo Washington wrote: | | I need to control bandwidth on the external interface only, not on the | LAN (internal interfaces). | | Is this rightful thinking or sheer imagination which is not practical? | | If you're happy with IPFilter and need to ensure minimum bandwidth for | some network segment, take a look at packet filter, you can take much of | your knowledge with you and then set up queues that will ensure the | minimum bandwidth. And you don't need extra interfaces. That is the way to go ultimately, but I am still a newbie with PF. I would not want to transfer my newbie-ness into a customers network ;) I am happy with IPFilter, yes, but I am gradually shifting to PF, but I have to graduate before I can put that out there. At the moment, I just want to solve an immediate problem which has presented itself. -Wash http://www.netmeister.org/news/learn2quote.html DISCLAIMER: See http://www.wananchi.com/bms/terms.php -- +==+ |\ _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED] Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ A university is what a college becomes when the faculty loses interest in students. -- John Ciardi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dummynet in an IPFilter setup
In response to Odhiambo Washington [EMAIL PROTECTED]:
* On 20/09/06 11:16 -0400, Bill Moran wrote:
| In response to Odhiambo Washington [EMAIL PROTECTED]:
|
| [snip]
|
| The scenario:
|
| I am running a FreeBSD 5.x box with IPFilter/IPNAT. The box has two
| interfaces at the moment, external interface connected to the hostile
| Internet and internal interface connected to a switch for the LAN.
|
| The ISP gives 256Kbit/s on the external interface. Out of this, I
| need to dedicate/guarantee 128Kbit/s to just one machine.
|
| A streaming server has been introduced on the LAN, and it is considered
| a VIP host as far as bandwidth allocation is concerned.
| The problem is that p2p is also officially allowed on the LAN. I hate
| it but it is allowed. Period. No argument about it.
|
| I need to guarantee 128Kbit/s of the available bandwidth to the
| streaming host (server, if you can call it).
|
|
| My thinking/plan:
|
| 1. Add one more NIC to the FreeBSD box (it's also the router,
|firewall, _everything_ server) and put this on a separate IP block.
|To this NIC I will connect the VIP host, which needs the guaranteed
|bandwidth. I will therefore NAT traffic to/from it.
|
| 2. Restrict the current LAN hosts to 128Kbit/s via ipfw pipe. To me,
| this means that:
| (a) They cannot go beyond 128Kbit/s
| (b) The VIP box will go above 128K/bit's in case the throttled
| LAN is not using all of the 128Kbit/s
|
| I need to control bandwidth on the external interface only, not on the
| LAN (internal interfaces).
|
| Is this rightful thinking or sheer imagination which is not practical?
|
| Seems reasonable. See below ...
Thanks, Bill for that verification.
| My problem:
|
|
| Most important is being dumb when it comes to IPFW and hence the pipes
| and all that pertains to it.
|
| Here is my ipfw configuration, in black and white (firewall_type=OPEN)
|
|
| # Outside interface network and netmask and ip
| oif=bfe0
| iif=xl0
| onet=62.8.68.0
| omask=255.255.255.252
| oip=62.8.68.22
|
| # Inside interface network and netmask and ip
| iif=xl0
| inet=10.0.0.0
| imask=255.255.255.0
| iip=10.0.0.2
|
| ipfw pipe 1 config bw 128Kbit/s
|
| # Allow any traffic to or from my own net.
| ${fwcmd} add pass all from ${iip} to ${inet}:${imask}
| ${fwcmd} add pass all from ${inet}:${imask} to ${iip}
|
| # Throttle now
| ipfw add pipe 1 tcp from $${inet}:${imask} to any out via ${oif}
state
|^^
|
| Is this direct cut/paste? If so, you've got a sticky $ key.
Yes, it was a paste in the process of modifying ;)
Noted with thanks.
|
| ${fwcmd} add 65000 pass all from any to any
|
|
| With this configuration, it seems like even LAN-LAN communication is
| being restricted to 128Kbit/s. I am not sure why, as simple as it looks!
| Can someone tell me why that is happening?
|
| Now, supposing the 3rd NIC was on 10.0.1.0/24 network, and there is no
| bandwidth limitation configuration, is it not true that I will have
| achieved my goal?
|
| I'll simply give the FreeBSD box 10.0.1.1 and the VIP box 10.0.1.2 and
| have a static route for the VIP box, with NAT for any connections
| to/from it.
|
|
| I'll really appreciate any help/advise towards a perfect configuration
| for the firewall, and how I can get this to work.
|
| Thanks in advance.
Bill, you did not say anything on my problem with intra-LAN traffic.
Does that mean this configuration is okay, and should not at all affect
traffic within the LAN?
I assumed that any problems you were seeing were a result of the typo.
Seems to me that the config you propose will do what you want, but I
haven't spent a lot of time thinking about it.
Besides, these kind of configs rarely work perfectly on the first try,
it usually takes a bit of tweaking after you implement them, as a result
of unforseen consequences. I think you've got a good starting point
and you should just monitor the set up for a while after implementation.
--
Bill Moran
Collaborative Fusion Inc.
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure
ipfilter dedicate firewall
Dear all, I have tried to read some documents online and build my own firewall using ipfilter enabled in my kernel. but now I want some idea regarding a coperate, dedicate firewall for company upto 250 users something. what should we do to get those type of firewall system? how to scale for it? what options and things we should consider and config with this firewall server? Best regards, Richard Ben, CIO -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter dedicate firewall
Dear all, I have tried to read some documents online and build my own firewall using ipfilter enabled in my kernel. but now I want some idea regarding a coperate, dedicate firewall for company upto 250 users something. what should we do to get those type of firewall system? how to scale for it? what options and things we should consider and config with this firewall server? Best regards, Richard Ben, CIO -- Hint: you should consider running a VPN for those who travel and need to access the (secure) internal network from the (insecure) outside world. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html Regards -- Christophe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter dedicate firewall
On 9/9/06, rithy4u- CEO [EMAIL PROTECTED] wrote: Dear all, I have tried to read some documents online and build my own firewall using ipfilter enabled in my kernel. but now I want some idea regarding a coperate, dedicate firewall for company upto 250 users something. what should we do to get those type of firewall system? how to scale for it? what options and things we should consider and config with this firewall server? you may want to try a dedicated firewall system like pfsense and monowall, they're based on FreeBSD, i for one use monowall. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 20:31, J.D. Bronson [EMAIL PROTECTED] wrote: At 07:59 PM 8/26/2006, you wrote: I'd go for the simpler syntax of: MYADDR: ! /sbin/ipf -y well that didnt work either. what a pain. :( tun0: Warning: /etc/ppp/ppp.linkup: ! /sbin/ipf -y: Invalid command perhaps its time to write a script and simply reference the script from ppp.linkup This is indeed, a good idea :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter on 6.1
I got a full load of 6.1p4 installed and all built. I have pppoe and ipfilter running almost perfect. Clients can use the machine (as a router) and get out perfectly! No issues with network performance at all. I am very pleased...until... I found out that the router itself cant get out 100%. My ipconfig is basically this: bge0 - 10.43.82.174 alias 10.43.82.171 - for bind9 views alias 10.43.82.51 - for bind9 views bge1 - connected to dsl modem well I cant even telnet from the machine to itself! 'destination unreachable' DNS requests from the server itself (to itself - it runs bind) are unanswered yet it is able to fully answer requests from internal or external clients...just not itself! If I use a public DNS server -or- use the IP of the machine I want to connect up to, the router is able to get out and uses the correct IP. I used the same configs from solaris on here (ipf.conf and ipnat.conf) and only needed to change sppp0 to tun0. this should take care of anything the machine itself needs: ipf.conf== # Pass LAN traffic to/from bge0 pass in quick on bge0 all keep state keep frags pass out quick on bge0 all keep state keep frags # Pass traffic to WAN and keep state pass out quick on tun0 proto tcp all flags S keep state keep frags pass out quick on tun0 proto udp all keep state keep frags pass out quick on tun0 proto icmp all keep state keep frags == I am totally baffled. Its like I am being blocked somehow but even with ipfilter WIDE open - traffic still wont pass. I am wondering if this is some quirk with the interface aliases...although running the basic same setup on solaris - it works perfectly. -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 15:02, J.D. Bronson [EMAIL PROTECTED] wrote: I got a full load of 6.1p4 installed and all built. I have pppoe and ipfilter running almost perfect. Clients can use the machine (as a router) and get out perfectly! No issues with network performance at all. I am very pleased...until... I found out that the router itself cant get out 100%. My ipconfig is basically this: bge0 - 10.43.82.174 alias 10.43.82.171 - for bind9 views alias 10.43.82.51 - for bind9 views bge1 - connected to dsl modem well I cant even telnet from the machine to itself! 'destination unreachable' DNS requests from the server itself (to itself - it runs bind) are unanswered yet it is able to fully answer requests from internal or external clients...just not itself! If I use a public DNS server -or- use the IP of the machine I want to connect up to, the router is able to get out and uses the correct IP. I used the same configs from solaris on here (ipf.conf and ipnat.conf) and only needed to change sppp0 to tun0. this should take care of anything the machine itself needs: ipf.conf== # Pass LAN traffic to/from bge0 pass in quick on bge0 all keep state keep frags pass out quick on bge0 all keep state keep frags # Pass traffic to WAN and keep state pass out quick on tun0 proto tcp all flags S keep state keep frags pass out quick on tun0 proto udp all keep state keep frags pass out quick on tun0 proto icmp all keep state keep frags == I am totally baffled. Its like I am being blocked somehow but even with ipfilter WIDE open - traffic still wont pass. I am wondering if this is some quirk with the interface aliases...although running the basic same setup on solaris - it works perfectly. Don't show us the ipf.conf file you are using, but the output of: % ipfstat -hni % ipfstat -hno Then we can really know what rules you have loaded in IP Filter. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 03:40 PM 8/26/2006, Giorgos Keramidas wrote: Don't show us the ipf.conf file you are using, but the output of: % ipfstat -hni % ipfstat -hno Then we can really know what rules you have loaded in IP Filter. # ipfstat -hni 2 @1 pass in quick on bge0 all keep state keep frags # ipfstat -hno 1 @1 pass out quick on bge0 all keep state keep frags 1 @2 pass out quick on tun0 proto tcp from any to any flags S/FSRPAU keep state keep frags 1 @3 pass out quick on tun0 proto udp from any to any keep state keep frags 0 @4 pass out quick on sppp0 proto icmp from any to any keep state keep frags ...they seem to match exactly. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 04:05 PM 8/26/2006, J.D. Bronson wrote: # ipfstat -hni 2 @1 pass in quick on bge0 all keep state keep frags # ipfstat -hno 1 @1 pass out quick on bge0 all keep state keep frags 1 @2 pass out quick on tun0 proto tcp from any to any flags S/FSRPAU keep state keep frags 1 @3 pass out quick on tun0 proto udp from any to any keep state keep frags 0 @4 pass out quick on sppp0 proto icmp from any to any keep state keep frags ...they seem to match exactly. ahh..so I saw a typo aboveso I changed that from 'sppp0' to 'tun0' but it make no differenceI thought I was onto something. -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 16:05, J.D. Bronson [EMAIL PROTECTED] wrote: At 03:40 PM 8/26/2006, Giorgos Keramidas wrote: Don't show us the ipf.conf file you are using, but the output of: % ipfstat -hni % ipfstat -hno Then we can really know what rules you have loaded in IP Filter. # ipfstat -hni 2 @1 pass in quick on bge0 all keep state keep frags # ipfstat -hno 1 @1 pass out quick on bge0 all keep state keep frags 1 @2 pass out quick on tun0 proto tcp from any to any flags S/FSRPAU keep state keep frags 1 @3 pass out quick on tun0 proto udp from any to any keep state keep frags 0 @4 pass out quick on sppp0 proto icmp from any to any keep state keep frags ...they seem to match exactly. Weird. This doesn't seem ot include *ANY* block rules at all. Is this a standard 6.1 installation, or do you have local IP Filter modifications (like, for instance, a modified 'default' rule which blocks everything, instead of allowing everything)? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 05:07 PM 8/26/2006, Giorgos Keramidas wrote: Weird. This doesn't seem ot include *ANY* block rules at all. Is this a standard 6.1 installation, or do you have local IP Filter modifications (like, for instance, a modified 'default' rule which blocks everything, instead of allowing everything)? Yes and no. I did build a kernel with BLOCK as a default... but my IPF rules are pass it all with no specific blocking... My next step was to try a kernel without the block, but I cant see how that should matter...since I 'am' allowing it out...? -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 17:10, J.D. Bronson [EMAIL PROTECTED] wrote: At 05:07 PM 8/26/2006, Giorgos Keramidas wrote: Weird. This doesn't seem ot include *ANY* block rules at all. Is this a standard 6.1 installation, or do you have local IP Filter modifications (like, for instance, a modified 'default' rule which blocks everything, instead of allowing everything)? Yes and no. I did build a kernel with BLOCK as a default... but my IPF rules are pass it all with no specific blocking... Well, there's your problem then. If you are using a modified kernel with block as the default action for IP Filter, hten you have to *EXPLICITLY* allow traffic to travese the loopback interface, which you haven't done. Your current ipf.conf includes: # Pass LAN traffic to/from bge0 pass in quick on bge0 all keep state keep frags pass out quick on bge0 all keep state keep frags # Pass traffic to WAN and keep state pass out quick on tun0 proto tcp all flags S keep state keep frags pass out quick on tun0 proto udp all keep state keep frags pass out quick on tun0 proto icmp all keep state keep frags Try reverting the local IP Filter changes that modify the default policy to block and use something like this instead: + # Block everything by default. + block in log from any to any + block out log from any to any + + # Allow everything on lo0. + pass in quick on lo0 from 127.0.0.1/32 to 127.0.0.1/32 + pass out quick on lo0 from 127.0.0.1/32 to 127.0.0.1/32 # Pass LAN traffic on bge0 interface. pass in quick on bge0 all keep state keep frags pass out quick on bge0 all keep state keep frags # Pass outgoing traffic to WAN and keep state pass out quick on tun0 proto tcp all flags S keep state keep frags pass out quick on tun0 proto udp all keep state keep frags pass out quick on tun0 proto icmp all keep state keep frags Please pay particular attention to the rules marked with '+' above. This may explain why in a previous post you wrote: On 2006-08-26 15:02, J.D. Bronson [EMAIL PROTECTED] wrote: Clients can use the machine (as a router) and get out perfectly! No issues with network performance at all. I am very pleased...until... I found out that the router itself cant get out 100%. My ipconfig is basically this: bge0 - 10.43.82.174 alias 10.43.82.171 - for bind9 views alias 10.43.82.51 - for bind9 views bge1 - connected to dsl modem well I cant even telnet from the machine to itself! 'destination unreachable' DNS requests from the server itself (to itself - it runs bind) are unanswered yet it is able to fully answer requests from internal or external clients...just not itself! If I use a public DNS server -or- use the IP of the machine I want to connect up to, the router is able to get out and uses the correct IP. You are implicitly blocking all traffic on the lo0 interface (by the modified default policy to block all traffic, and missing an explicit rule to allow lo0 traffic). When a system tries to connect to itself, it uses lo0/127.0.0.1 and this is not possible with your setup. I hope this helps a bit, -- Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 05:19 PM 8/26/2006, Giorgos Keramidas wrote: You are implicitly blocking all traffic on the lo0 interface (by the modified default policy to block all traffic, and missing an explicit rule to allow lo0 traffic). When a system tries to connect to itself, it uses lo0/127.0.0.1 and this is not possible with your setup. I hope this helps a bit, -- Giorgos Oh geezI cant believe I forgot lo0. HOW STUPID. I will edit this and take another look at it. once I have this working..I still want to figure out why pf was not happy. Thanks for pointing this out guys...I feel foolish, but glad someone told me. -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On Saturday, August 26, 2006 at 8:02:10 PM, J.D. confabulated: I got a full load of 6.1p4 installed and all built. I have pppoe and ipfilter running almost perfect. Clients can use the machine (as a router) and get out perfectly! No issues with network performance at all. I am very pleased...until... I found out that the router itself cant get out 100%. My ipconfig is basically this: bge0 - 10.43.82.174 alias 10.43.82.171 - for bind9 views alias 10.43.82.51 - for bind9 views bge1 - connected to dsl modem well I cant even telnet from the machine to itself! 'destination unreachable' DNS requests from the server itself (to itself - it runs bind) are unanswered yet it is able to fully answer requests from internal or external clients...just not itself! If I use a public DNS server -or- use the IP of the machine I want to connect up to, the router is able to get out and uses the correct IP. I used the same configs from solaris on here (ipf.conf and ipnat.conf) and only needed to change sppp0 to tun0. this should take care of anything the machine itself needs: ipf.conf== # Pass LAN traffic to/from bge0 pass in quick on bge0 all keep state keep frags pass out quick on bge0 all keep state keep frags # Pass traffic to WAN and keep state pass out quick on tun0 proto tcp all flags S keep state keep frags pass out quick on tun0 proto udp all keep state keep frags pass out quick on tun0 proto icmp all keep state keep frags == I am totally baffled. Its like I am being blocked somehow but even with ipfilter WIDE open - traffic still wont pass. I am wondering if this is some quirk with the interface aliases...although running the basic same setup on solaris - it works perfectly. Did you build the kernel with the 'IPFILTER_DEFAULT_BLOCK'? If so, you would have to have two allowances at the end for anything else that didn't match the other rules: pass in all pass out all Being you are using 'quick', the processing stops when a match is found. If no match is found and you have IPFILTER_DEFAULT_BLOCK enabled, everything else would be blocked. I made this mistake when I set IPFilter up the first time and it was in a colo facility over 800 miles away. -- This message was sent using 100% recycled electrons. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 17:48, J.D. Bronson [EMAIL PROTECTED] wrote: At 05:19 PM 8/26/2006, Giorgos Keramidas wrote: You are implicitly blocking all traffic on the lo0 interface (by the modified default policy to block all traffic, and missing an explicit rule to allow lo0 traffic). When a system tries to connect to itself, it uses lo0/127.0.0.1 and this is not possible with your setup. I hope this helps a bit, Oh geezI cant believe I forgot lo0. HOW STUPID. I will edit this and take another look at it. Cool! If this is indeed the fix, let us know :) If you also feel like it and you are not limited by contract or other things, I'd be interested to see how you modified IP Filter to make it use a block by default policy. Regards, Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 06:37 PM 8/26/2006, Giorgos Keramidas wrote: Cool! If this is indeed the fix, let us know :) If you also feel like it and you are not limited by contract or other things, I'd be interested to see how you modified IP Filter to make it use a block by default policy. Regards, Giorgos This fixed it. WHEW! Simply adding this to my own kernel: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK then: # ipf -V ipf: IP Filter: v4.1.8 (416) Kernel: IP Filter: v4.1.8 Running: yes Log Flags: 0 = none set Default: block all, Logging: available Active list: 0 Feature mask: 0xa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 18:52, J.D. Bronson [EMAIL PROTECTED] wrote: At 06:37 PM 8/26/2006, Giorgos Keramidas wrote: Cool! If this is indeed the fix, let us know :) If you also feel like it and you are not limited by contract or other things, I'd be interested to see how you modified IP Filter to make it use a block by default policy. Regards, Giorgos This fixed it. WHEW! Great :) Simply adding this to my own kernel: options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK Ok this was what I wanted to make sure :) then: # ipf -V ipf: IP Filter: v4.1.8 (416) Kernel: IP Filter: v4.1.8 Running: yes Log Flags: 0 = none set Default: block all, Logging: available Active list: 0 Feature mask: 0xa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
Ok guys...now that I have ipfilter working...I need to run a few commands in /etc/ppp/ppp;linkup and cant figure out the syntax... % cat /etc/ppp/ppp.linkup # It is no longer necessary to re-add the default route here as our MYADDR: ! sh -c /sbin/ipnat -CF -f /etc/ipnat.conf ! sh -c /sbin/ipf -F -f /etc/ipf.conf ! sh -c /sbin/ipf -Fa -f /etc/ipf.conf ! sh -c /sbin/ipf -y ...I also tried with !bg and that failed to. whats the best way to get these commands to run once my ppp link is up? thanks- -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
On 2006-08-26 19:46, J.D. Bronson [EMAIL PROTECTED] wrote: Ok guys...now that I have ipfilter working...I need to run a few commands in /etc/ppp/ppp;linkup and cant figure out the syntax... % cat /etc/ppp/ppp.linkup # It is no longer necessary to re-add the default route here as our MYADDR: ! sh -c /sbin/ipnat -CF -f /etc/ipnat.conf ! sh -c /sbin/ipf -F -f /etc/ipf.conf ! sh -c /sbin/ipf -Fa -f /etc/ipf.conf ! sh -c /sbin/ipf -y Watch out for that empty line, if it is *REALLY* part of your `ppp.linkup' script. Empty lines are section delimiters in ppp(8) config files. Thereis also no reason to run ipf _twice_! Please also note that I don't use sh -c to signal ntpd to start/stop from my ppp.linkup script and it all works fine: [EMAIL PROTECTED]:/root# cat -n /etc/ppp/ppp.linkup 1 MYADDR: 2 ! /etc/rc.d/ntpd start [EMAIL PROTECTED]:/root# Maybe the whole sh -c and quoting stuff you are using is not really passed down to sh(1) but is parsed by ppp(8) when `ppp.linkup' is read? I am also not sure if it is a good idea to run ``ipnat -CF'' of ``ipf -Fa''. What about states of existing connections? If you momentarily lose the PPP connection, but it then comes up pretty fast, you are effectively dropping all previous connection information here, even though it may still be valid and useful. I'd go for the simpler syntax of: MYADDR: ! /sbin/ipf -y ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter on 6.1
At 07:59 PM 8/26/2006, you wrote: I'd go for the simpler syntax of: MYADDR: ! /sbin/ipf -y well that didnt work either. what a pain. :( tun0: Warning: /etc/ppp/ppp.linkup: ! /sbin/ipf -y: Invalid command perhaps its time to write a script and simply reference the script from ppp.linkup -JD ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Ipfilter 4.1.13 and freebsd 6.1
I am currently running a couple of 6.1 and 5.4 servers as firewall / routers for my company. I am experiencing some problems on the 6.1 server with ipfilter where it blocks oow (out of window) packets. I have tried to update to the latest version of ipfilter but was unable to compile my kernel after running the kupgrade script in the ipf source folder. Does anyone have any hacks / patches that they have used to get ipfilter version 4.1.13 running on FreeBSD 6.1-Release? Regards, Nicholas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ipfilter 4.1.13 and freebsd 6.1
I run 6.1 with ipfilter and LAN full of window boxes NO PROBLEM. You need to provide a much greater level of details before making such unfounded statements as ipfilter is broken. Your rule set is most likely incorrect. Post description of your firewall/LAN setup along with your complete rule set for review by list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nicholas von Waltsleben Sent: Thursday, June 08, 2006 3:16 AM To: freebsd-questions@freebsd.org Subject: Ipfilter 4.1.13 and freebsd 6.1 I am currently running a couple of 6.1 and 5.4 servers as firewall / routers for my company. I am experiencing some problems on the 6.1 server with ipfilter where it blocks oow (out of window) packets. I have tried to update to the latest version of ipfilter but was unable to compile my kernel after running the kupgrade script in the ipf source folder. Does anyone have any hacks / patches that they have used to get ipfilter version 4.1.13 running on FreeBSD 6.1-Release? Regards, Nicholas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ipfilter 4.1.13 and freebsd 6.1
Nicholas wrote: I am currently running a couple of 6.1 and 5.4 servers as firewall / routers for my company. I am experiencing some problems on the 6.1 server with ipfilter where it blocks oow (out of window) packets. I have tried to update to the latest version of ipfilter but was unable to compile my kernel after running the kupgrade script in the ipf source folder. Does anyone have any hacks / patches that they have used to get ipfilter version 4.1.13 running on FreeBSD 6.1-Release? Regards, Nicholas Fbsd wrote: I run 6.1 with ipfilter and LAN full of window boxes NO PROBLEM. You need to provide a much greater level of details before making such unfounded statements as ipfilter is broken. I never said that ipfilter was in any way broken, just that I was experiencing problems running it since moving to a 6.1 server. My apologies for not making myself clearer. Your rule set is most likely incorrect. Post description of your firewall/LAN setup along with your complete rule set for review by list. Very well, here is some more information but I am not about to post my entire ruleset on a publicly searchable mailing list Extract from ipfstat -ni @2 block in quick on em0 all head 1 ... @9 pass in quick on em0 proto tcp from 196.31.10.14/32 to any port = http flags S/FSRPAU keep state group 1 ... @19 block in log quick on em0 all group 1 Ipmon output 08/06/2006 14:23:01.652653 STATE:NEW 165.165.192.80,53269 - 196.7.156.157,80 PR tcp ... 08/06/2006 14:23:31.221693 em0 @1:20 b 165.165.192.80,53269 - 196.7.156.157,80 PR tcp len 20 64 -S IN OOW 08/06/2006 14:23:31.674548 STATE:NEW 165.165.192.80,50949 - 196.7.156.157,80 PR tcp 08/06/2006 14:23:32.915562 STATE:NEW 165.165.192.80,53465 - 196.7.156.157,80 PR tcp 08/06/2006 14:23:34.219658 em0 @1:20 b 165.165.192.80,53269 - 196.7.156.157,80 PR tcp len 20 64 -S IN OOW The 165.x.x.x IP address is from an ADSL line I was using to troubleshoot the problem (I was the only person using the line so it made tcpdumps etc easier to read, less noise). In our environment the problem was easily resolved by disabling SACKS on the Windows 2003 servers behind my firewall (something I have just finished testing). But I would still like someone to please point me in the right direction insofar as updating IPFilter to 4.1.13 under FreeBSD 6.1 as this solution is not to my liking. Regards, Nicholas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
installing ports behind IPFILTER
Hi everyone, I am having some problems installing ports when I have IPFILTER running. I have put FTP_PASSIVE_MODE=YES in /etc/make.conf but the command 'make all install clean' yields; === Vulnerability check disabled, database not found = jce-aba-1.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/znerd/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/znerd/jce-aba-1.1.tar.gz: Network is unreachable *** Error code 1 This happens when I try to install ports or pakages. I have also tried to install with tcp/ip ports 20,21 and 22 open but to no avail. Could you please CC me if you can help, am not on the list due to this mailbox being from a University. My IPFILTER is set to block by default in my kernel, and I am running 6.1 RELEASE Thanks, Brett. -- If you are new to UNIX, you may be used to clicking something and seeing either an OK message, an error, nothing, or (all too often) a pretty blue screen with nifty high-tech letters explaining exactly where the system crashed - Michael Lucas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installing ports behind IPFILTER
Brett Wiggins wrote: Hi everyone, I am having some problems installing ports when I have IPFILTER running. I have put FTP_PASSIVE_MODE=YES in /etc/make.conf Try putting it in /etc/login.conf /etc #grep PASSIVE * login.conf: :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\ [snip] Hope this helps Duane Whitty -- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installing ports behind IPFILTER
Brett Wiggins wrote: Hi everyone, I am having some problems installing ports when I have IPFILTER running. I have put FTP_PASSIVE_MODE=YES in /etc/make.conf but the command 'make all install clean' yields; === Vulnerability check disabled, database not found = jce-aba-1.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/znerd/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/znerd/jce-aba-1.1.tar.gz: Network is unreachable *** Error code 1 This happens when I try to install ports or pakages. I have also tried to install with tcp/ip ports 20,21 and 22 open but to no avail. Could you please CC me if you can help, am not on the list due to this mailbox being from a University. My IPFILTER is set to block by default in my kernel, and I am running 6.1 RELEASE G'day, Probably this is what you're after: # Allow out gateway LAN users non-secure FTP ( both passive active modes) # This function uses the IPNAT built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state That one is from: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipf.html Cheers, Mikhail. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: http://www.webanoide.org PGP Key ID: 0x4E148A3B PGP Key Fingerprint: D96B 7C14 79A5 8824 B99D 9562 F50E 2F5D 4E14 8A3B ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter rule will not load
Hello I cannot get ipfilter to load any rules. When I type in the iptest command I receive the following output: [EMAIL PROTECTED]# ipftest no rules loaded I used the example found in the /usr/share/examples directory I am unable to load the firewall. I have tried to load the file though # ipf -Fa -f /etc/ipf.rules I have posted my configuration bellow Thank you Aaron Kernel #IPFILTER options IPFILTER options IPFILTER_LOG #optionsIPFILTER_DEFAULT_BLOCK /etc/rc.conf ipfilter_enable=YES ipfilter_rules=/etc/ipf.rules ipmon_enable=YES ipmon_flags=-Dsn ipnat_enable=YES ipnat_rules=/etc/ipnat.rules /etc/syslog.conf security.* /var/log/ipfilter.log security.info /var/log/firewall.info security.notice /var/log/firewall.notice security.warning/var/log/firewall.warning security.err/var/log/firewall.err /etc/ipf.rules (small excerpt)# Allow in standard www function because I have apache server pass in quick on dc0 proto tcp from any to any port = 80 flags S keep state pass in quick on dc0 proto udp from any to any port = 80 keep state # Allow access to the zope server 8080 pass in quick on dc0 proto tcp from any to any port = 8080 flags S keep state pass in quick on dc0 proto udp from any to any port = 8080 keep state # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID/PW passed over public Internet as clear text. # Delete this sample group if you do not have telnet server enabled. #pass in quick on dc0 proto tcp from any to any port = 23 flags S keep state #pass in quick on dc0 porto udp from any to any port = 23 keep state # Allow in secure FTP, Telnet, and SCP from public Internet # This function is using SSH (secure shell) pass in quick on dc0 proto tcp from any to any port = 22 flags S keep state pass in quick on dc0 proto udp from any to any port = 22 keep state # Block and log only first occurrence of all remaining traffic # coming into the firewall. The logging of only the first # occurrence stops a .denial of service. attack targeted # at filling up your log file space. # This rule enforces the block all by default logic. block in log first quick on dc0 all ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter rule will not load
On 4/25/2006 1:19 PM, Aaron Siegel wrote: Hello I cannot get ipfilter to load any rules. When I type in the iptest command I receive the following output: [EMAIL PROTECTED]# ipftest no rules loaded man ipftest says: At least one of -N, -P or -r must be specified. Sounds like you want: # ipftest -r /etc/ipf.rules Ron Wilhoite ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
re: Re: problem with ipfilter(ipnat)
Nikos, thank you. I appended mssclamp 1440 in ipf.rule, it works now! And I have tried not use it but add set link mtu 1440 in mpd.conf, and failed. Yes, the problem occurs when NATing, and mssclamp 1440 is the key. fbsd, thank you anyway. Arnold Lee 2006 -04-14 - How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with ipfilter(ipnat)
I am in a small lan and want to use fb 6.0 as a router to share internet access. I use mpd 3.18 to dial adsl on demand. I configured ipnat with : map rl0 10.0.0.0/8 - 0.0.0.0/32 portmap tcp/udp auto map rl0 10.0.0.0/8 - 0.0.0.0/32 And then I use my client compute(windows 2000 Pro) to access internet, it seems ok, but soon I realize that there are some websites I can not access! For example, www.chinaunix.net is unacessable! So are some ftp sites such as ftp.freebsd.org. It must be a problem of the FB6 box, because if i access internet directly from the win2000 box, all those sites above is ok ! what is wrong? By the way, I donot use ipfirewall and other firewall, and in rc.conf, I wrote ipfilter_enable = NO, ipnat_enable= YES. Can you help me? - 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: problem with ipfilter(ipnat)
There is nothing wrong with FreeBSD 6.0 It's the way you activated ipf that is wrong. Ipfilter's ipnat function is not an independent function. You have to code this in rc.conf ipfilter_enable = YES ipnat_enable = YES and make sure there is no default ipf.rules file Then ipf will use its default pass all rule which results in the ipnat function working with a firewall rule of pass all Also your nat rules are incorrect. The special alias 0.0.0.0/32 should be 0/32 The FreeBSD handbook has a good section on ipfilter. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Arnold Lee Sent: Wednesday, April 12, 2006 4:34 AM To: freebsd-questions@freebsd.org Subject: problem with ipfilter(ipnat) I am in a small lan and want to use fb 6.0 as a router to share internet access. I use mpd 3.18 to dial adsl on demand. I configured ipnat with : map rl0 10.0.0.0/8 - 0.0.0.0/32 portmap tcp/udp auto map rl0 10.0.0.0/8 - 0.0.0.0/32 And then I use my client compute(windows 2000 Pro) to access internet, it seems ok, but soon I realize that there are some websites I can not access! For example, www.chinaunix.net is unacessable! So are some ftp sites such as ftp.freebsd.org. It must be a problem of the FB6 box, because if i access internet directly from the win2000 box, all those sites above is ok ! what is wrong? By the way, I donot use ipfirewall and other firewall, and in rc.conf, I wrote ipfilter_enable = NO, ipnat_enable= YES. Can you help me? - 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem with ipfilter(ipnat)
On Wednesday 12 April 2006 11:34, Arnold Lee wrote: I am in a small lan and want to use fb 6.0 as a router to share internet access. I use mpd 3.18 to dial adsl on demand. I configured ipnat with : map rl0 10.0.0.0/8 - 0.0.0.0/32 portmap tcp/udp auto map rl0 10.0.0.0/8 - 0.0.0.0/32 And then I use my client compute(windows 2000 Pro) to access internet, it seems ok, but soon I realize that there are some websites I can not access! For example, www.chinaunix.net is unacessable! So are some ftp sites such as ftp.freebsd.org. It must be a problem of the FB6 box, because if i access internet directly from the win2000 box, all those sites above is ok ! what is wrong? By the way, I donot use ipfirewall and other firewall, and in rc.conf, I wrote ipfilter_enable = NO, ipnat_enable= YES. Can you help me? I can try. It might be a PMTU problem. A quick way testing PMTU related problems is setting a small (below 1400) MTU on your nic. If you have another Unix-like OS on your lan(besides your router) you can try a smaller MTU like this ifconfig nic mtu 1000 and see what's going on. If you don't have another Unix-like OS, go to step 2 (Windows can also change MTU size but the procedure is not that simple, google for it if you want it). 2) I recall that I have seen something relative in ipf. It's here: http://www.netbsd.org/Documentation/network/pppoe/#clamping a quick search in man 5 ipf.conf for clamp returned no results, but that's the case for NetBSD man aswell. I guess it is not documented in the manual. Try it. there is also ng_tcpmss(4), which does the job and is what I have used in the past with success there are other sollutions too(an mpd option, is it working? a daemon (tcpmssd)) but I am not familar with... HTH - 无限容量雅虎相册，原图等大下载，超快速度，赶快抢注！ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FBSD 6.0 ipfilter nat redirect not working.
in quick on rl0 proto tcp/udp from any to any port = 139 block in quick on rl0 proto tcp/udp from any to any port = 81 # Block all ftp attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 21 # Block all SSH attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 22 # Block all telnet attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 23 # Block all www attempts so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 80 # Block all secure www attempts so count will show in daily cron rpt block in quick on rl0 proto tcp from any to any port = 443 # Block all smtp email server attempts so count will show in daily cron rpt block in quick on rl0 proto tcp from any to any port = 25 # block range of Trojan udp ports 1021 thru 1039 # so count will show in daily cron rpt block in quick on rl0 proto udp from any to any port 1020 1040 # block Trojan scan port block in quick on rl0 proto tcp from any port = 6000 to any # Allow traffic in from ISP's DHCP server. pass in quick on rl0 proto udp from xx.173.0.1 port = 67 to any keep state pass in quick on rl0 proto udp from xx.39.64.1 port = 67 to any keep state # Allow traffic in from ISP's DNS server. pass in quick on rl0 proto udp from xx.168.240.5 port = 53 to any keep state pass in quick on rl0 proto udp from xx.168.240.2 port = 53 to any keep state # Allow in testing www function because I have apache server on lan pass in log quick on rl0 proto tcp from any to any port = 6188 flags S keep state pass in log quick on rl0 proto tcp from any to 10.0.10.4 port = 80 flags S keep state # Block all upd traffic block in log quick on rl0 proto udp all #block in quick on rl0 proto udp all # Block and log only first occurrence of all remaining traffic # coming into the firewall. # This rule enforces the block all by default logic. #block in quick on rl0 all block in log quick on rl0 all -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Norgaard Sent: Wednesday, March 29, 2006 2:54 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ORG Subject: Re: FBSD 6.0 ipfilter nat redirect not working. fbsd_user wrote: # /root ipnat -l List of active MAP/Redirect filters: map rl0 10.0.10.0/29 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 0.0.0.0/0 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 10.0.10.0/29 - 0.0.0.0/32 rdr rl0 0.0.0.0/0 port 6188 - 10.0.10.4 port 80 tcp List of active sessions: RDR 10.0.10.4 80- - 79.69.59.49 6188 [65.45.227.95 2698] MAP 10.0.10.6 1857 - - 79.69.59.49 1857 [216.155.193.144 5050] Nothing happens. No ipf.log records on gateway box and no ipf.log records on the LAN web server box. There is firewall rule to log pass from any to 10.0.10.4 port = 80 keep state And any packet that does not match a firewall rule get logged and dropped. Please post your filter ruleset also. Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 6.0 ipfilter nat redirect not working.
connections out from your LAN will then not be evaluated against this rule when response packets come back. # Block a bunch of different nasty things. # That I don't want to see in the log # Block frags #block in log quick on rl0 all with frags block in quick on rl0 all with frags # Block short tcp packets #block in log quick on rl0 proto tcp all with short block in quick on rl0 proto tcp all with short # block source routed packets #block in log quick on rl0 all with opt lsrr #block in log quick on rl0 all with opt ssrr block in quick on rl0 all with opt lsrr block in quick on rl0 all with opt ssrr # Block nmap OS fingerprint attempts block in quick on rl0 proto tcp from any to any flags FUP # Block anything with special options #block in log quick on rl0 all with ipopts block in quick on rl0 all with ipopts # Block public pings block in quick on rl0 proto icmp all icmp-type 8 # Block ident block in quick on rl0 proto tcp from any to any port = 113 # Block all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 block in quick on rl0 proto tcp/udp from any to any port = 137 block in quick on rl0 proto tcp/udp from any to any port = 138 block in quick on rl0 proto tcp/udp from any to any port = 139 block in quick on rl0 proto tcp/udp from any to any port = 81 # Block all ftp attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 21 # Block all SSH attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 22 # Block all telnet attempts to login so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 23 # Block all www attempts so count will show in daily cron rpt block in quick on rl0 proto tcp/udp from any to any port = 80 Here you go! You have the nat rule rdr rl0 0.0.0.0/0 port 6188 - 10.0.10.4 port 80 tcp for rdr, this takes place on the incoming interface before the packet traverses the in-rules for that interface. So the packets on rl0 you redirect to port 80 are blocked here. # Block all secure www attempts so count will show in daily cron rpt block in quick on rl0 proto tcp from any to any port = 443 # Block all smtp email server attempts so count will show in daily cron rpt block in quick on rl0 proto tcp from any to any port = 25 # block range of Trojan udp ports 1021 thru 1039 # so count will show in daily cron rpt block in quick on rl0 proto udp from any to any port 1020 1040 # block Trojan scan port block in quick on rl0 proto tcp from any port = 6000 to any # Allow traffic in from ISP's DHCP server. pass in quick on rl0 proto udp from xx.173.0.1 port = 67 to any keep state pass in quick on rl0 proto udp from xx.39.64.1 port = 67 to any keep state # Allow traffic in from ISP's DNS server. pass in quick on rl0 proto udp from xx.168.240.5 port = 53 to any keep state pass in quick on rl0 proto udp from xx.168.240.2 port = 53 to any keep state # Allow in testing www function because I have apache server on lan pass in log quick on rl0 proto tcp from any to any port = 6188 flags S keep state pass in log quick on rl0 proto tcp from any to 10.0.10.4 port = 80 flags S keep state These two rules never apply, the rdr takes place as mentioned before filtering, so the first won't ever match, and the second is blocked above. Remember with nat: if rules applies on the way in, the are applied _before_ the packet is filtered. If rules applies on the way out, they are applied _after_ the packet is filtered. And this is great, because when you write the filter rules, you can simply think of all your ip's being routeable. Cheers, Erik # Block all upd traffic block in log quick on rl0 proto udp all #block in quick on rl0 proto udp all # Block and log only first occurrence of all remaining traffic # coming into the firewall. # This rule enforces the block all by default logic. #block in quick on rl0 all block in log quick on rl0 all -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Norgaard Sent: Wednesday, March 29, 2006 2:54 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ORG Subject: Re: FBSD 6.0 ipfilter nat redirect not working. fbsd_user wrote: # /root ipnat -l List of active MAP/Redirect filters: map rl0 10.0.10.0/29 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 0.0.0.0/0 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 10.0.10.0/29 - 0.0.0.0/32 rdr rl0 0.0.0.0/0 port 6188 - 10.0.10.4 port 80 tcp List of active sessions: RDR 10.0.10.4 80- - 79.69.59.49 6188 [65.45.227.95 2698] MAP 10.0.10.6 1857 - - 79.69.59.49 1857 [216.155.193.144 5050] Nothing happens. No ipf.log records on gateway box and no ipf.log records on the LAN web server box. There is firewall rule to log pass from any to 10.0.10.4 port = 80 keep state
Re: FBSD 6.0 ipfilter nat redirect not working.
Just a quick question. How are you connecting to the Internet, by that I mean are you using aDSL? If you are, I can help you. Don ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FBSD 6.0 ipfilter nat redirect not working.
Been running ipfilter long time. Now with FBSD 6.0 having no joy at getting redirect to web server on LAN to work. This is first time trying this. rl0 is NIC facing the public internet. 10.0.10.4 is the LAN ip address of the web server. Have friend uses http://79.69.59.49:6188/index.htm to target me. The ip address is fake for this posting. # /root ipnat -l List of active MAP/Redirect filters: map rl0 10.0.10.0/29 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 0.0.0.0/0 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 10.0.10.0/29 - 0.0.0.0/32 rdr rl0 0.0.0.0/0 port 6188 - 10.0.10.4 port 80 tcp List of active sessions: RDR 10.0.10.4 80- - 79.69.59.49 6188 [65.45.227.95 2698] MAP 10.0.10.6 1857 - - 79.69.59.49 1857 [216.155.193.144 5050] Nothing happens. No ipf.log records on gateway box and no ipf.log records on the LAN web server box. There is firewall rule to log pass from any to 10.0.10.4 port = 80 keep state And any packet that does not match a firewall rule get logged and dropped. Gateway box has these sysctl nobs set net.inet.ip.forwarding=1 net.inet.ip.sourceroute=0 net.ip.accept_sourceroute=0 From the active session list, it looks like the rdr command was executed but no packet showed up at the firewall. My question is, does any one have ipfilter nat redirect working on Freebsd 6.0 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FBSD 6.0 ipfilter nat redirect not working.
fbsd_user wrote: # /root ipnat -l List of active MAP/Redirect filters: map rl0 10.0.10.0/29 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 0.0.0.0/0 - 0.0.0.0/32 proxy port ftp ftp/tcp map rl0 10.0.10.0/29 - 0.0.0.0/32 rdr rl0 0.0.0.0/0 port 6188 - 10.0.10.4 port 80 tcp List of active sessions: RDR 10.0.10.4 80- - 79.69.59.49 6188 [65.45.227.95 2698] MAP 10.0.10.6 1857 - - 79.69.59.49 1857 [216.155.193.144 5050] Nothing happens. No ipf.log records on gateway box and no ipf.log records on the LAN web server box. There is firewall rule to log pass from any to 10.0.10.4 port = 80 keep state And any packet that does not match a firewall rule get logged and dropped. Please post your filter ruleset also. Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter nat redirect
fbsd_user wrote: I have a web server on my private lan that I want to be accessible from the public internet. dc0 is the interface facing the public internet I added this rdr rule after the map rules at the end of my nat file. ordering is extremely important, nat rules are first match while filter rules are last match unless you add the quick keyword. So, if you have eg a binat rule, then the rdr never takes place. rdr dc0 0/0 port 80 - 10.0.10.4 port 8080 also tried this rule rdr dc0 0.0.0.0/0 port 80 - 10.0.10.4 port 8080 seems ok, but you may want to replace the 0/0 with your external ip/32 if it is fixed. My understanding of the documentation says the above rdr rule means, check all packets inbound on interface dc0, and no matter what the sending ip address of the packet may be, if the port number of the destination ip address of that packet matches port 80, then re-write the packet's destination ip address and port to 10.0.10.4 port 8080 and create the internal nat table to handle the translation of the outbound packets coming from 10.0.10.4. Then hand the re-written packet to the firewall to be processed against the firewall rules. My ipfilter firewall rules would need a pass rule like this pass in log quick on dc0 proto tcp from any to 10.0.10.4 port = 8080 flags S keep state to create the by-directional packet session. Problem is I cant get this to work. I see nothing in the log for the pass rule. Anybody have any idea what I am doing wrong or if my understanding of the re-direct process is in error. When using rdr, the rdr rule is applied _before_ the filtering, so filter rule above seems correct to me. Always, and in particular for debugging, create a rule that catches and logs anything you haven't thought of. Your log only catches successful passes, after that rule, add a log rule like: block in log quick on dc0 this should show you the packets that actually are filtered. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter nat redirect
John Murphy wrote: I think the filter action occurs before NAT so you would need this: pass in log quick on dc0 proto tcp from any to your live IP port = 80 For ip-filter, if nat is done when the packet comes IN on an interface, like with rdr, then this takes place BEFORE filtering. If nat is done when the packet goes OUT on an interface then this takes place AFTER filtering. If you use binat then you can think of it as the combination of rdr and nat. The reason that binat is not really rdr+nat is that rdr requires a specific port. But for understanding where the nat'ing takes place for binat, thinking rdr+nat on the same interface works. This means that when nat is configured correctly then you can completely forget about it when writing the firewall rules and just think of all networks to be routable. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter nat redirect
I have a web server on my private lan that I want to be accessible from the public internet. dc0 is the interface facing the public internet I added this rdr rule after the map rules at the end of my nat file. rdr dc0 0/0 port 80 - 10.0.10.4 port 8080 also tried this rule rdr dc0 0.0.0.0/0 port 80 - 10.0.10.4 port 8080 My understanding of the documentation says the above rdr rule means, check all packets inbound on interface dc0, and no matter what the sending ip address of the packet may be, if the port number of the destination ip address of that packet matches port 80, then re-write the packet's destination ip address and port to 10.0.10.4 port 8080 and create the internal nat table to handle the translation of the outbound packets coming from 10.0.10.4. Then hand the re-written packet to the firewall to be processed against the firewall rules. My ipfilter firewall rules would need a pass rule like this pass in log quick on dc0 proto tcp from any to 10.0.10.4 port = 8080 flags S keep state to create the by-directional packet session. Problem is I cant get this to work. I see nothing in the log for the pass rule. Anybody have any idea what I am doing wrong or if my understanding of the re-direct process is in error. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter nat redirect
fbsd_user [EMAIL PROTECTED] wrote: I have a web server on my private lan that I want to be accessible from the public internet. dc0 is the interface facing the public internet I added this rdr rule after the map rules at the end of my nat file. rdr dc0 0/0 port 80 - 10.0.10.4 port 8080 also tried this rule rdr dc0 0.0.0.0/0 port 80 - 10.0.10.4 port 8080 I have 'tcpudp' after the port in my rdr rules, but see below. My understanding of the documentation says the above rdr rule means, check all packets inbound on interface dc0, and no matter what the sending ip address of the packet may be, if the port number of the destination ip address of that packet matches port 80, then re-write the packet's destination ip address and port to 10.0.10.4 port 8080 and create the internal nat table to handle the translation of the outbound packets coming from 10.0.10.4. Then hand the re-written packet to the firewall to be processed against the firewall rules. My ipfilter firewall rules would need a pass rule like this pass in log quick on dc0 proto tcp from any to 10.0.10.4 port = 8080 flags S keep state I think the filter action occurs before NAT so you would need this: pass in log quick on dc0 proto tcp from any to your live IP port = 80 -- John. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Interaction between mpd and ipfilter/ipnat
I have a FreeBSD firewall which does packet filtering and NAT. The internal address range is 172.16.64.0/24. The only filtering is incoming on the external NIC, fxp0. The machine also runs mpd for remote access. By pure chance I was tailing ipf.log when I connected an XP laptop to the mpd service, and immediately I saw these: Mar 16 16:57:41 inchgower ipmon[61]: 16:57:40.923619 fxp0 @0:2 b 172.16.64.168,137 - 172.16.64.200,137 PR udp len 20 96 IN Mar 16 16:57:42 inchgower ipmon[61]: 16:57:42.425811 fxp0 @0:2 b 172.16.64.168,137 - 172.16.64.200,137 PR udp len 20 96 IN 172.16.64.168 is the address given out by mpd to the laptop. 172.16.64.200 is the Active Directory Domain Controller. I'm confused as to why ipf is seeing these packets coming in on fxp0. Surely what comes in is the GRE packet to the external NIC's address, this is then decapsulated and the embedded packet routed on. Why does ipf even see it, let alone block it? I would expect the source interface to be ng0, not fxp0. From the laptop I can ping and connect to internal machines, so most packets are not being blocked in this way. tcpdump also sees the packets coming in on fxp0, but I'm not convinced they are. I guess I can only really tell if I get the switch to copy packets to another port and monitor from there. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
[was Re: IPFILTER rule error]
Yes, that's it! Thanks! I've managed to miss somehow your message, Giorgos, and flooded a bit :-) Regards, Muxas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
Hi! Thahks for your attention! First of all you really need to read the ipfilter section of the FreeBSD handbook... [EMAIL PROTECTED] I've read the handbook. Good starting point! :-) Given that I just _TEST_ ipf config ported from 5.4 to 6.0 on local LAN, I do not violate theoretical background of firewalling. Grouping is used to differentiate inbound\outbound traffic, probably I will use it to diff interfaces. I don't know if you posted the whole ruleset or if you cut out what seemed irrelevant to keep the post short... Erik Norgaard Yes, I do not show you the whole story about ipf.rules, only the skeleton and the problematic lines. The reason for that is that ipfilter works with basic ipf.rules, and ipfstat confirms that. But no logs as expected (but eventually I've found where log info went: it appeared at /var/log/messages, and not in /var/log/security as configured!). By the way, I prefer to use syslogd because it allows for log rotation, which is god! :-) Problem with no such process appeared when I added to ipf.rules line pass out quick on rl0 \ proto udp from any to any port = sunrpc keep state group 20 It doesn't matter whether port parameter is expressed as a name or a number. I have other lines written both types and all of that works! Again, the error is presented only when I insert the above line in ipf.rules. This is an outbound rule; I've had the inbound rule in basic setup (you can see it in my previous post) and it ran just well! Ok, in the attachment there is the whole story about ipf.rules as it is. As I've found from the handbook this way of firewalling is called inclusive %-). Regards, Muxas P.S. I apologize for my message timing, it's the second question i'll ask after ipf :-) # External interface - ppp0 # #%% Block-and-log everything that is not allowed explicitly #block in log on ppp0 all head 10 #block out log on ppp0 all head 15 #%% Allow DNS requests % #pass out quick on ppp0 \ # proto tcp/udp from any to any port = domain keep state group 15 #%% Allow outbound HTTP packets #pass out quick on ppp0 \ # proto tcp from any to any port = 80 keep state keep frags group 15 #%% Allow outbound FTP packets % #pass out quick on ppp0 \ # proto tcp from any to any port = 21 keep state group 15 #%% Allow inbound FTP-data packets % #pass in quick on ppp0 \ # proto tcp/udp from any port = 20 to any port 1024 keep state group 10 #%% Allow outbound Jabber connections %% #pass out quick on ppp0 \ # proto tcp from any to any port = 5222 keep state group 15 #%% Allow POP3 outgoing connections #pass out quick on ppp0 \ # proto tcp/udp from any to any port = 110 keep state group 15 #%% Allow SMTP outgoing connections #pass out quick on ppp0 \ # proto tcp/udp from any to any port = 25 keep state group 15 #%% Allow outgoing CVS connections % #pass out quick on ppp0 \ # proto tcp/udp from any to any port = 5999 keep state group 15 # Internal interface #1 - rl0 (10.0.1.0/29) # #% Block-and-log everything that is not allowed explicitly % block in log on rl0 all head 20 block out log on rl0 all head 25 #pass in on rl0 from 10.0.1.1/29 to any group 20 #pass out on rl0 from any to 10.0.1.1/29 group 25 #% Allow ping %% pass in quick on rl0 \ proto icmp all keep state group 20 pass out quick on rl0 \ proto icmp all keep state group 25 #% Allow DNS requests %% pass in quick on rl0 \ proto tcp/udp from any to any port = domain keep state group 20 #% Allow DHCP requests % pass in quick on rl0 \ proto tcp/udp from any port = 68 to any port = 67 group 20 #% Allow HTTP requests from local network %% pass in quick on rl0 \ proto tcp from any to any port = 80 keep state keep frags group 20 #% Allow FTP requests from local network %%% pass in quick on rl0 proto tcp from any to any port = 21 keep state group 20 #% Allow inbound FTP-data packets
Re: IPFILTER rule error
Maxim Vetrov wrote: # Internal interface #1 - rl0 (10.0.1.0/29) # #% Block-and-log everything that is not allowed explicitly % block in log on rl0 all head 20 block out log on rl0 all head 25 #% Allow Sun RPC incoming calls pass in quick on rl0 \ proto tcp/udp from any to any port = sunrpc keep state group 20 pass in quick on rl0 \ proto tcp/udp from any to any port = 717 keep state group 20 # the next line raise the error when uncommented #pass out quick on rl0 \ # proto udp from any to any port = 111 keep state group 20 I think someone else already pointed at this: You try to add a rule for outbound traffic to the inbound group in the offending line. Try correct to group 25. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
On 2006-02-15 16:23, Erik Norgaard [EMAIL PROTECTED] wrote: Maxim Vetrov wrote: # Internal interface #1 - rl0 (10.0.1.0/29) # #% Block-and-log everything that is not allowed explicitly % block in log on rl0 all head 20 block out log on rl0 all head 25 #% Allow Sun RPC incoming calls pass in quick on rl0 \ proto tcp/udp from any to any port = sunrpc keep state group 20 pass in quick on rl0 \ proto tcp/udp from any to any port = 717 keep state group 20 # the next line raise the error when uncommented #pass out quick on rl0 \ # proto udp from any to any port = 111 keep state group 20 I think someone else already pointed at this: You try to add a rule for outbound traffic to the inbound group in the offending line. Try correct to group 25. That's true. I did post the relevant message: Date: Tue, 14 Feb 2006 17:13:33 +0200 From: Giorgos Keramidas [EMAIL PROTECTED] Subject: Re: IPFILTER rule error To: Maxim Vetrov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] [...] Note that you have only set up a group numbered '25' for outgoing traffic, but then attempt to add a rule to an outgoing group of '20'. This is the cause of the error you're seeing. This ruleset should work fine: # block in log on rl0 all head 20 # block out log on rl0 all head 25 # # pass in quick on rl0 \ # proto tcp/udp from any to any port = sunrpc keep state group 20 # pass in quick on rl0 \ # proto tcp/udp from any to any port = 717 keep state group 20 # pass out quick on rl0 \ # proto udp from any to any port = 111 keep state group 25 [...] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
Hi, Sorry, I really do not want you to guess! Here is what you asked: kernel conf: --- ... optionsIPFILTER optionsIPFILTER_LOG #optionsIPFILTER_DEFAULT_BLOCK #optionsIPSTEALTH ... --- rc.conf: --- ... ifconfig_rl0=inet 10.0.1.1 netmask 255.255.255.248 ... ipnat_enable=YES ipfilter_enable=YES ipmon_enable=YES ... --- services: --- ... sunrpc 111/tcprpcbind #SUN Remote Procedure Call sunrpc 111/udprpcbind #SUN Remote Procedure Call ... --- ipf.rules: --- block in log on rl0 all head 20 block out log on rl0 all head 25 pass in quick on rl0 \ proto tcp/udp from any to any port = sunrpc keep state group 20 pass in quick on rl0 \ proto tcp/udp from any to any port = 717 keep state group 20 pass out quick on rl0 \ proto udp from any to any port = 111 keep state group 20 Steps to load the rules: ipf -Fa ipf -f /etc/ipf.rules 1:ioctl (add/insert rule): No such process And there is one more problem - despite that I have packet logging enabled by default (-Ds) through syslogd, log is empty! syslog.conf: ... security.* /var/log/security ... That file exists and have root rw permissions. If this help: after I'd moved to 6.0 from 5.4 (backup-format-install-restore), this config stopped to work. I know that I'm doing something wrong but what exactly? Regards, Muxas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
Maxim Vetrov wrote: Hi, kernel conf: --- ... optionsIPFILTER optionsIPFILTER_LOG #optionsIPFILTER_DEFAULT_BLOCK #optionsIPSTEALTH ... --- The rc scripts should load these modules if they are not compiled with the kernel, in that case they would show up with kldstat. Try use kldstat and sysctl -a to see what's in your kernel, grep for ipf. services: --- ... sunrpc 111/tcprpcbind #SUN Remote Procedure Call sunrpc 111/udprpcbind #SUN Remote Procedure Call ... --- ipf.rules: --- block in log on rl0 all head 20 block out log on rl0 all head 25 pass in quick on rl0 \ proto tcp/udp from any to any port = sunrpc keep state group 20 pass in quick on rl0 \ proto tcp/udp from any to any port = 717 keep state group 20 pass out quick on rl0 \ proto udp from any to any port = 111 keep state group 20 Steps to load the rules: ipf -Fa ipf -f /etc/ipf.rules 1:ioctl (add/insert rule): No such process 1st: IIRC, the number in the error line indicates the line the error occurred in - not sure though. That would be your first rule. I don't know if you posted the whole ruleset or if you cut out what seemed irrelevant to keep the post short. 2nd: Reading the ipf-howto I see no examples where port names are used, try using the port number to eliminate that posibility. And there is one more problem - despite that I have packet logging enabled by default (-Ds) through syslogd, log is empty! syslog.conf: ... security.* /var/log/security ... That file exists and have root rw permissions. If you want to log to a separate file, why not let ipmon do that directly? # ipmon -D /var/log/security Secondly, the empty log may not be that surprising in the first place if your ruleset is not loaded correctly. Cheers, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: IPFILTER rule error
First of all you really need to read the ipfilter section of the FreeBSD handbook. The correct solution is exampled in the handbook. You do not need to compile ipfilter in to the kernel to work. From your rules I see no need for that head/group stuff so remove it. I see rl0 being assigned to private ip address which means that Nic is facing your LAN which is behind your gateway box. That ip address range is not routable on the public internet. You have something mess up big time. Your firewall rules is suppose to be on the Nic facing the public internet. You nat the public ip address to you private LAN ip address. The reason you have no log records is because your firewall rules have syntax error and are never loaded. Only rules with log keyword will generate log records. Only use rules with quick option. Do not mix quick and non quick rules. You need pass in rules for you ISP's dns and dhcp servers to access your box. Explain in detail your network layout. Do you have LAN? How are you connected to the public internet? Again I strongly recommend you read the ipfilter section of the handbook your answers are there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Maxim Vetrov Sent: Tuesday, February 14, 2006 7:57 PM To: freebsd-questions@FreeBSD.org Subject: Re: IPFILTER rule error Hi, Sorry, I really do not want you to guess! Here is what you asked: kernel conf: --- ... optionsIPFILTER optionsIPFILTER_LOG #optionsIPFILTER_DEFAULT_BLOCK #optionsIPSTEALTH ... --- rc.conf: --- ... ifconfig_rl0=inet 10.0.1.1 netmask 255.255.255.248 ... ipnat_enable=YES ipfilter_enable=YES ipmon_enable=YES ... --- services: --- ... sunrpc 111/tcprpcbind #SUN Remote Procedure Call sunrpc 111/udprpcbind #SUN Remote Procedure Call ... --- ipf.rules: --- block in log on rl0 all head 20 block out log on rl0 all head 25 pass in quick on rl0 \ proto tcp/udp from any to any port = sunrpc keep state group 20 pass in quick on rl0 \ proto tcp/udp from any to any port = 717 keep state group 20 pass out quick on rl0 \ proto udp from any to any port = 111 keep state group 20 Steps to load the rules: ipf -Fa ipf -f /etc/ipf.rules 1:ioctl (add/insert rule): No such process And there is one more problem - despite that I have packet logging enabled by default (-Ds) through syslogd, log is empty! syslog.conf: ... security.* /var/log/security ... That file exists and have root rw permissions. If this help: after I'd moved to 6.0 from 5.4 (backup-format-install-restore), this config stopped to work. I know that I'm doing something wrong but what exactly? Regards, Muxas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFILTER rule error
Hi, I'm running FreeBSD 6.0, IPFilter 4.1.8(416). Setting line for rpc outbound calls pass out quick on rl0 \ proto udp from any to any port = sunrpc keep state group 20 gives me this error: ioctl (add/insert rule): No such process What is the process i'm missing? Regards, muxas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
On 2006-02-14 10:09, Maxim Vetrov [EMAIL PROTECTED] wrote: Hi, I'm running FreeBSD 6.0, IPFilter 4.1.8(416). Setting line for rpc outbound calls pass out quick on rl0 \ proto udp from any to any port = sunrpc keep state group 20 gives me this error: ioctl (add/insert rule): No such process What is the process i'm missing? Don't copy/paste just one line. Show us the exact options you used in your `/etc/rc.conf' file, and be *very* specific about the steps you took to enable that rule. Otherwise, we can only guess what's wrong. You don't want us to guess wrong, do you? - Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
Maxim Vetrov wrote: Hi, I'm running FreeBSD 6.0, IPFilter 4.1.8(416). Setting line for rpc outbound calls pass out quick on rl0 \ proto udp from any to any port = sunrpc keep state group 20 gives me this error: ioctl (add/insert rule): No such process What is the process i'm missing? Do you have that group? or maybe sunrpc is not in /etc/services - better try to write the port number. It will help to show the whole ruleset. Cheers, Erik ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFILTER rule error
Hi, I'm running FreeBSD 6.0, IPFilter 4.1.8(416). Setting line for rpc outbound calls pass out quick on rl0 \ proto udp from any to any port = sunrpc keep state group 20 gives me this error: ioctl (add/insert rule): No such process What is the process i'm missing? Regards, muxas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Hello, By default freebsd doesn't have any firewall's compiled into the kernel or loaded as kernel mod's so you need to add ipfilter_enable=YES to rc.conf and type in kldload ipl so you dont have to reboot the machine and also make sure you add a simple rules to allow all or youll look yourself out as it defaults to deny all hope this help a bit. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Ipfilter upgrade
Has anybody tried to upgrade from the 3r branch of Ipfilter to 4th in FreeBSD 5.4? The procedure described in official document isn't correct - my kernel don't compile with ipfilter - couldn't create needed dependencies. Has anybody encountered such problem? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfilter question
hello, my freebsd box is already setup and followed some of the docs on setting up the firewall using ipfilter. question on logging. setup /var/log/ipfilter.log as my log file. modified syslog.conf. its working now unfortunately, its loggin on that file AND to my messages log file. is it possible to log ipfilter log only to my log file? thanks -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter question
On 12/13/05, Elmer Rivera [EMAIL PROTECTED] wrote: hello, Hello, my freebsd box is already setup and followed some of the docs on setting up the firewall using ipfilter. question on logging. setup /var/log/ipfilter.log as my log file. How/where did you set this up? modified syslog.conf. How did you modified this? its working now unfortunately, its loggin on that file AND to my messages log file. is it possible to log ipfilter log only to my log file? Yes, it is possible. Here's my setup: /etc/rc.conf ipmon_enable=YES ipmon_flags=-Dns /etc/syslog.conf security.* /var/log/ipfilter.log Make sure you don't have any other security.* facility specified in /etc/syslog.conf thanks -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph Hope this helps, -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ipfilter question
In FBSD 4.11 and older, ipfilter logged to local0. Then in 5.4 it was changed to security. Now in 6.0 it has reverted back to logging to local0. The /etc/syslog.conf file is where you define the log files. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pietro Cerutti Sent: Tuesday, December 13, 2005 7:39 AM To: Elmer Rivera; FreeBSD Subject: Re: ipfilter question On 12/13/05, Elmer Rivera [EMAIL PROTECTED] wrote: hello, Hello, my freebsd box is already setup and followed some of the docs on setting up the firewall using ipfilter. question on logging. setup /var/log/ipfilter.log as my log file. How/where did you set this up? modified syslog.conf. How did you modified this? its working now unfortunately, its loggin on that file AND to my messages log file. is it possible to log ipfilter log only to my log file? Yes, it is possible. Here's my setup: /etc/rc.conf ipmon_enable=YES ipmon_flags=-Dns /etc/syslog.conf security.* /var/log/ipfilter.log Make sure you don't have any other security.* facility specified in /etc/syslog.conf thanks -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph Hope this helps, -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter question
#uname -a FreeBSD hcggw1.hcg.com.ph 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #0: Sat Dec 10 09:49:16 PHT 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HCGGW1 i386 setup /var/log/ipfilter.log as my log file. How/where did you set this up? # touch /var/log/ipfilter.log modified syslog.conf. How did you modified this? # vi /etc/syslog.conf commented out old security.* and inserted a new line pointing to the file above. -- # Consult the syslog.conf(5) manpage. *.err;kern.warning;auth.notice;mail.crit/dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages security.* /var/log/ipfilter.log #security.* /var/log/security auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog -- its working now unfortunately, its loggin on that file AND to my messages log file. is it possible to log ipfilter log only to my log file? Yes, it is possible. # cat /etc/rc.conf -- ipfilter_enable=YES ipnat_enable=YES ipmon_enable=YES ipmon_flags=-Dsn -- Here's my setup: /etc/rc.conf ipmon_enable=YES ipmon_flags=-Dns /etc/syslog.conf security.* /var/log/ipfilter.log Make sure you don't have any other security.* facility specified in /etc/syslog.conf yes, there is no other security.* facility, actually i got it working to log on my file (/var/log/ipfilter.log) but it also logs on /var/log/messages. I only want to log on my file. thanks -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph Hope this helps, -- Pietro Cerutti [EMAIL PROTECTED] Beansidhe - SwiSS Death / Thrash Metal www.beansidhe.ch Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? regards -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter question
Here's my setup: /etc/rc.conf ipmon_enable=YES ipmon_flags=-Dns /etc/syslog.conf security.* /var/log/ipfilter.log Make sure you don't have any other security.* facility specified in /etc/syslog.conf yes, there is no other security.* facility, actually i got it working to log on my file (/var/log/ipfilter.log) but it also logs on /var/log/messages. I only want to log on my file. thanks -- Elmer Rivera, http://www.vizcayano.com, http://youand.i.ph I have the problem that ipmon logs to /var/log/messages and nothing goes to /var/log/ipf.log. Even after using the info in this thread. I am using local0 as was suggested for FreeBSD 6.0. Earlier I was using security.* which didn't work either. I suppose that at the least, I need to remove something from the /var/log/messages line. Here is my syslog.conf: *.err;kern.warning;auth.notice;mail.crit/dev/console *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages local0.*/var/log/ipf.log auth.info;authpriv.info /var/log/auth.log mail.info /var/log/maillog lpr.info/var/log/lpd-errs ftp.info/var/log/xferlog cron.* /var/log/cron *.=debug/var/log/debug.log Thanks, Rob. -- -- http://home.comcast.net/~europa100 A SETI-like Search for Intelligent Life in Central Pa. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter question
in message [EMAIL PROTECTED], wrote Rob Lytle thusly... Here's my setup: ... in /etc/syslog.conf yes, there is no other security.* facility, actually i got it working Please keep the attribution attribute the respective authors. I have the problem that ipmon logs to /var/log/messages and nothing goes to /var/log/ipf.log. Even after using the info in this thread. I am using local0 as was suggested for FreeBSD 6.0. Earlier I was using security.* which didn't work either. I suppose that at the least, I need to remove something from the /var/log/messages line. ... *.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err /var/log/messages local0.* /var/log/ipf.log Like authpriv.none to stop auth messages going into /var/log/messages, you will need to add local0.none (or replace local0 w/ whatever the actual facility is used) after *.notice;. According to ipmon(8) on 5.4, passed logged packets are logged w/ level of 'notice'. So you should be seeing only the passed packets in '/var/log/messages'. Rest of the messages, will go wherever (local0|security|*).(info|warn|err) messages go. Or, you could ... - give a file name to ipmon(8) to log messages in - remove the -s option to not to log via syslogd(8) - put the ipmon facility.none, in /etc/syslog.cong, to avoid other files receiving ipf messages. - adjust /etc/newsyslog.conf to properly rotate the ipmon log files. Don't forget to read up on syslog.conf(5), newsyslog.conf(5), and ipmon(8) in any case. - Parv -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
