Re: panics when authpf is used under -current
On Sun, Dec 15, 2002 at 09:50:44PM -0800, Ben Lovett wrote: Anyone else noticed panics with authpf and -current as of around 16:00 on 12/14? The system in question is a Soekris net4501, which was previously running -current from around November 26th fine, with the same configuration. If you've made sure userland was built with the same pfvar.h as the kernel (either cp /usr/src/sys/net/pfvar.h /usr/include/net before rebuilding authpf, or make build of the entire userland), I can debug this if you mail me your pf.conf and authpf.conf. I assume that the panic happens as soon as a user logs in through authpf. There's a larger rework of the ioctl interface going to be commited soon, which will also require a rewrite of authpf's ioctl interface. So we either need to debug this quickly or wait until the ioctl changes are in and test authpf again then. Daniel
Re: passive ftp rules
On Mon, 2002-12-16 at 11:47, Duncan Matthew Stirling wrote: Please show me any example of a passive firewall rule set. Let's nip this in the bud before it gets out of hand. http://www.holland-consulting.net/tech/OBSDCommProbs.html#unfriendly -J.
Re: passive ftp rules
On Mon, Dec 16, 2002 at 09:47:41AM -0700, Duncan Matthew Stirling wrote: Please show me any example of a passive firewall rule set. block in on $ext_if all pass out on $ext_if all keep state Passive mode ftp means that the ftp data connections are opened from the clients to the servers (as compared to active mode, which is the other way around). The rule set depends on where the clients and the servers are, relative to the firewall, and in which directions you want to allow passive ftp, and whether you're running NAT. Take a look at ftp-proxy(8), which contains further explanations of ftp modes and example rules. And if you want a more specific answer, we'll need more specific questions :) Daniel
Very Annoying problem... blocks everything...
Ok, I'm new to OpenBSD and pf, but I'm quickly getting the hang of it. Here's my setup: AMD 2300 w/ 512mb DDR ram 512mb flash drive 5 10/100 network cards I have 4 networks right now, one of them is the internet. So let's call them, Inet, A, B,and C. Network C is the network with all mail/web/dns/etc servers on it. A and B are networks, I could really care less what traffic goes to them, and from them, going to/from the internet and each other. I want networks A and B to be able to only access the mail servers on ports 25/110/80/443, dns servers on port 53, webservers on ports 80/443, and a couple of other servers via ftp. Should be very simple, I setup some rules to allow all traffic from Inet going to A and B. I then allowed all traffic from A and B going to Inet to pass through. I then setup some holes on C, to allow those ports to those servers that I want open. I also allowed network C to access http/https/ftp/dns/mail outside of it's network. I have a catch all in the bottom of my script, to just block everything that doesn't fit into anything else. I enable it.. what happens.. I loose connectivity to all the networks. Nothing can see anything outside of their network. do a ping from the firewall, and you get: ping: sendto: No route to host ping: wrote 192.168.3.250 64 chars, ret=-1 Anyone have any ideas?
Re: Very Annoying problem... blocks everything...
Shawn, Multi-interface packet filtering can be tricky. Could you post your rules? Without that, all we can probably say is that you have a misconfiguration somewhere. IIRC, creating stateful inspection on one interface does not allow the packets to go through other interfaces. This is my first guess as to your problem. ==ml On Mon, Dec 16, 2002 at 03:03:53PM -0600, [EMAIL PROTECTED] wrote: Ok, I'm new to OpenBSD and pf, but I'm quickly getting the hang of it. Here's my setup: AMD 2300 w/ 512mb DDR ram 512mb flash drive 5 10/100 network cards I have 4 networks right now, one of them is the internet. So let's call them, Inet, A, B,and C. Network C is the network with all mail/web/dns/etc servers on it. A and B are networks, I could really care less what traffic goes to them, and from them, going to/from the internet and each other. I want networks A and B to be able to only access the mail servers on ports 25/110/80/443, dns servers on port 53, webservers on ports 80/443, and a couple of other servers via ftp. Should be very simple, I setup some rules to allow all traffic from Inet going to A and B. I then allowed all traffic from A and B going to Inet to pass through. I then setup some holes on C, to allow those ports to those servers that I want open. I also allowed network C to access http/https/ftp/dns/mail outside of it's network. I have a catch all in the bottom of my script, to just block everything that doesn't fit into anything else. I enable it.. what happens.. I loose connectivity to all the networks. Nothing can see anything outside of their network. do a ping from the firewall, and you get: ping: sendto: No route to host ping: wrote 192.168.3.250 64 chars, ret=-1 Anyone have any ideas? -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.oreillynet.com/pub/q/Big_Scary_Daemons Absolute BSD: http://www.AbsoluteBSD.com/
RE: Very Annoying problem... blocks everything...
Only on the dc0 interface. the 192.168.3.0/24 block is on the dc1 interface.
The dc0 interface goes to the internet... I don't want/need to send anything from
192.168/16 to the internet
since their 1918 addys...
-Shawn
Do you have all routing set up correctly? Is the network that
192.168.3.250 is on in the same subnet as one of the firewall
interfaces? Or is it a separate network?
You'd need to add a route for it if it's separate.
I had something funky happen with my routes at one point and had to
re-add.
Good luck
I enable it.. what happens.. I loose connectivity to all the
networks. Nothing can see anything outside
of their network.
do a ping from the firewall, and you get:
ping: sendto: No route to host
ping: wrote 192.168.3.250 64 chars, ret=-1
Anyone have any ideas?
block in log quick on dc0 inet from { 172.16.0.0/12 , 192.168.0.0/16
the 192.168.3.250 is included in this rules ?
Re: Very Annoying problem... blocks everything...
[EMAIL PROTECTED] wrote: http://www.iodamedia.net/pf.conf Go grab it.. and tell me what I'm doing wrong! -Shawn Your ruleset is quite large to debug it just by looking at it. But one error quickly sprang to my eyes: You're blocking the loopback interface, which is certainly a bad idea. Clemens
RE: Very Annoying problem... blocks everything...
On Mon, 2002-12-16 at 19:50, Shawn Mitchell wrote: Dosn't matter what IP address on any interface you ping. All comes back with the same thing. I turned on logging to see what wasn't making and such. I'm seeing DNS requests getting blocked... Routing is not an issue. The packets (ICMP, et al) are getting blocked. I do a pfctl -f /etc/pf.conf -e and I can't ping anything... I do a pfctl -d to turn it off... and everything goes back to working just fine. Sure sounds to me like you're blocking traffic to/from your gateway. I assume you've studied your logs? All of your block rules appear to be logging, so I'm not sure why we haven't seen any mention of what might be (or might not be) appearing in your log. Run tcpdump -nettti pflog0 as you run your ping tests. That will tell you which rule is causing your headache. Then run pfctl -s rules | grep rule # to find out which one it is. Honestly, your ruleset is giving *me* headaches just looking at it. Your background with Linux (that's not a rip; hell, I'm an rhce) certainly shows. Try to avoid the default behavior towards quick unless you're really sure that's what you want. You don't need to worry about performance... skip steps really avoids the extra processing overhead. -J.
RE: Very Annoying problem... blocks everything...
on the tcpdump -nettti pflog0 command, should everything match the last two rules, which are: pass in log quick inet from any to any pass out log quick inet from any to any They were block, but I changed them to pass so I could better see what's going on with live traffic... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dixon Sent: Monday, December 16, 2002 8:42 PM To: PF Mailing List Subject: RE: Very Annoying problem... blocks everything... On Mon, 2002-12-16 at 19:50, Shawn Mitchell wrote: Dosn't matter what IP address on any interface you ping. All comes back with the same thing. I turned on logging to see what wasn't making and such. I'm seeing DNS requests getting blocked... Routing is not an issue. The packets (ICMP, et al) are getting blocked. I do a pfctl -f /etc/pf.conf -e and I can't ping anything... I do a pfctl -d to turn it off... and everything goes back to working just fine. Sure sounds to me like you're blocking traffic to/from your gateway. I assume you've studied your logs? All of your block rules appear to be logging, so I'm not sure why we haven't seen any mention of what might be (or might not be) appearing in your log. Run tcpdump -nettti pflog0 as you run your ping tests. That will tell you which rule is causing your headache. Then run pfctl -s rules | grep rule # to find out which one it is. Honestly, your ruleset is giving *me* headaches just looking at it. Your background with Linux (that's not a rip; hell, I'm an rhce) certainly shows. Try to avoid the default behavior towards quick unless you're really sure that's what you want. You don't need to worry about performance... skip steps really avoids the extra processing overhead. -J.
RE: Very Annoying problem... blocks everything...
On Mon, 2002-12-16 at 22:46, Shawn Mitchell wrote: on the tcpdump -nettti pflog0 command, should everything match the last two rules, which are: pass in log quick inet from any to any pass out log quick inet from any to any No. You have a gazillion other quick rules in front of these. The first one that matches is going to force the action. That's why quick should be used very conservatively. Otherwise, last match wins. They were block, but I changed them to pass so I could better see what's going on with live traffic... Don't start changing your rules without monitoring your traffic. What kind of logged traffic are you seeing? We can't help you if you don't work with us. -J.
RE: Very Annoying problem... blocks everything...
I know it's long.. but several want to see this... I used the quick commands just because they stop there and exit... I figured it would be faster to write it that way and get exactly what I want. I can just state what I want to pass, then kill everything else. btw, I have 4 /22's going through this box. You can see how many NetBIOS scans I get. tcpdump -nei pflog0 output Keep in mind, this is only about 0.3 seconds... Dec 16 22:08:16.628541 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.628550 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.668056 rule 449/0(match): pass in on dc0: 159.153.255.253.18501 65.172.62.141.2717: . ack 30 win 24656 (DF) Dec 16 22:08:16.668073 rule 450/0(match): pass out on dc1: 159.153.255.253.18501 65.172.62.141.2717: . ack 30 win 24656 (DF) Dec 16 22:08:16.674948 rule 449/0(match): pass in on dc0: 137.104.75.93.1214 65.172.62.55.4764: . ack 1 win 64223 (DF) Dec 16 22:08:16.674959 rule 450/0(match): pass out on dc1: 137.104.75.93.1214 65.172.62.55.4764: . ack 1 win 64223 (DF) Dec 16 22:08:16.679436 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.679459 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.703918 rule 449/0(match): pass in on dc0: 66.218.70.32.5000 65.172.62.168.5000: udp 112 Dec 16 22:08:16.703929 rule 450/0(match): pass out on dc1: 66.218.70.32.5000 65.172.62.168.5000: udp 112 Dec 16 22:08:16.704832 rule 449/0(match): pass in on dc0: 159.153.254.193.16101 65.172.62.61.1851: . ack 125 win 9112 (DF) Dec 16 22:08:16.704845 rule 450/0(match): pass out on dc1: 159.153.254.193.16101 65.172.62.61.1851: . ack 125 win 9112 (DF) Dec 16 22:08:16.709064 rule 449/0(match): pass in on dc1: 65.172.62.55.4763 66.27.97.83.2528: . ack 1461 win 8760 (DF) Dec 16 22:08:16.709075 rule 450/0(match): pass out on dc0: 65.172.62.55.4763 66.27.97.83.2528: . ack 1461 win 8760 (DF) Dec 16 22:08:16.717121 rule 449/0(match): pass in on dc1: 65.172.62.143.1044 63.241.83.184.4000: . ack 1744 win 8898 (DF) Dec 16 22:08:16.717136 rule 450/0(match): pass out on dc0: 65.172.62.143.1044 63.241.83.184.4000: . ack 1744 win 8898 (DF) Dec 16 22:08:16.728991 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.729019 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.745427 rule 449/0(match): pass in on dc0: 208.254.16.84.34313 65.172.62.176.1115: udp 66 (DF) Dec 16 22:08:16.745444 rule 450/0(match): pass out on dc1: 208.254.16.84.34313 65.172.62.176.1115: udp 66 (DF) Dec 16 22:08:16.768261 rule 449/0(match): pass in on dc0: 159.153.255.253.18501 65.172.62.141.2717: . ack 31 win 24656 (DF) Dec 16 22:08:16.768273 rule 450/0(match): pass out on dc1: 159.153.255.253.18501 65.172.62.141.2717: . ack 31 win 24656 (DF) Dec 16 22:08:16.769133 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.769145 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.772831 rule 449/0(match): pass in on dc0: 63.241.83.184.4000 65.172.62.143.1044: P 1744:1755(11) ack 67 win 65263 Dec 16 22:08:16.772843 rule 450/0(match): pass out on dc1: 63.241.83.184.4000 65.172.62.143.1044: P 1744:1755(11) ack 67 win 65263 Dec 16 22:08:16.787941 rule 449/0(match): pass in on dc1: 65.172.62.143.1044 63.241.83.184.4000: P 67:72(5) ack 1744 win 8898 (DF) Dec 16 22:08:16.787968 rule 450/0(match): pass out on dc0: 65.172.62.143.1044 63.241.83.184.4000: P 67:72(5) ack 1744 win 8898 (DF) Dec 16 22:08:16.800304 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.800326 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.803162 rule 449/0(match): pass in on dc0: 66.218.70.32.5000 65.172.62.168.5000: udp 112 Dec 16 22:08:16.803175 rule 450/0(match): pass out on dc1: 66.218.70.32.5000 65.172.62.168.5000: udp 112 Dec 16 22:08:16.807216 rule 449/0(match): pass in on dc0: 66.27.97.83.2528 65.172.62.55.4763: . 8761:10221(1460) ack 0 win 63844 (DF) Dec 16 22:08:16.807234 rule 450/0(match): pass out on dc1: 66.27.97.83.2528 65.172.62.55.4763: . 8761:10221(1460) ack 0 win 63844 (DF) Dec 16 22:08:16.817426 rule 449/0(match): pass in on dc1: 65.172.62.143.1044 63.241.83.184.4000: . ack 1744 win 8898 (DF) Dec 16 22:08:16.817438 rule 450/0(match): pass out on dc0: 65.172.62.143.1044 63.241.83.184.4000: . ack 1744 win 8898 (DF) Dec 16 22:08:16.820702 rule 449/0(match): pass in on dc1: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.820729 rule 450/0(match): pass out on dc0: 65.172.62.47. 205.177.62.71.: udp 40 Dec 16 22:08:16.836857 rule 449/0(match): pass in on dc1:
RE: Very Annoying problem... blocks everything...
Ok... I said screw it and completly re-did the config. I've got most of it working, but I'm still showing just a few weird things that's getting blocked now... 6 is my block in, 7 is my block out. All of the other DNS is working just fine... I just see port 53 in here a couple of times... 07:23:24.345466 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.31.108.206.3379: udp 12 07:23:24.502276 rule 6/0(match): block in on dc1: 65.172.62.140.1214 65.168.173.82.2805: udp 12 07:23:24.783620 rule 6/0(match): block in on dc1: 65.172.62.152.1024 198.77.116.8.53: 15534+ A? KRLK.direcpc.com. (46) 07:23:25.354632 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.25.23.239.1873: udp 12 07:23:25.404610 rule 7/0(match): block out on dc0: 213.67.113.237.3342 65.172.61.201.6346: S 3848218851:3848218851(0) win 16384 mss 1460,nop,nop,sackOK (DF) 07:23:25.413441 rule 6/0(match): block in on dc1: 65.172.62.140.1214 134.129.63.205.2672: udp 12 07:23:26.105551 rule 6/0(match): block in on dc1: 65.172.62.58.3777 62.195.38.112.2064: S 2594810045:2594810045(0) win 8760 mss 1460,nop,nop,sackOK (DF) 07:23:26.282313 rule 6/0(match): block in on dc1: 65.172.62.152.1024 198.77.116.8.53: 15534+ A? KRLK.direcpc.com. (46) 07:23:26.365464 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.27.244.188.1261: udp 12 07:23:26.522323 rule 6/0(match): block in on dc1: 65.172.62.140.1214 65.166.158.173.2239: udp 12 07:23:27.374891 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.30.166.133.2571: udp 12 07:23:27.482349 rule 6/0(match): block in on dc1: 65.172.62.140.1214 65.31.25.21.2886: udp 12 07:23:27.553453 rule 6/0(match): block in on dc1: 65.172.62.134.1709 172.145.107.136.3014: P 451548289:451548691(402) ack 14364311 win 9112 (DF) 07:23:28.374805 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.35.72.29.1519: udp 12 07:23:28.513473 rule 6/0(match): block in on dc1: 65.172.62.140.1214 65.171.14.29.1795: udp 12 07:23:28.602579 rule 6/0(match): block in on dc1: 65.172.62.134.1706 207.69.113.152.3607: P 450659155:450659527(372) ack 852793283 win 9112 (DF) 07:23:28.793476 rule 6/0(match): block in on dc1: 65.172.62.147.3086 205.188.179.233.5190: S 3584173258:3584173258(0) win 16384 mss 1460,nop,nop,sackOK (DF) 07:23:29.042444 rule 6/0(match): block in on dc1: 65.172.62.145.1145 64.12.161.153.5190: S 36704427:36704427(0) win 8192 mss 536,nop,nop,sackOK (DF) 07:23:29.365514 rule 6/0(match): block in on dc1: 65.172.62.58.3973 65.35.65.139.2063: udp 12 07:23:29.453323 rule 6/0(match): block in on dc1: 65.172.62.140.1214 216.98.72.126.1826: udp 12 == -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dixon Sent: Monday, December 16, 2002 9:52 PM To: PF Mailing List Subject: RE: Very Annoying problem... blocks everything... On Mon, 2002-12-16 at 22:46, Shawn Mitchell wrote: on the tcpdump -nettti pflog0 command, should everything match the last two rules, which are: pass in log quick inet from any to any pass out log quick inet from any to any No. You have a gazillion other quick rules in front of these. The first one that matches is going to force the action. That's why quick should be used very conservatively. Otherwise, last match wins. They were block, but I changed them to pass so I could better see what's going on with live traffic... Don't start changing your rules without monitoring your traffic. What kind of logged traffic are you seeing? We can't help you if you don't work with us. -J.
Re: Very Annoying problem... blocks everything...
Do you have all routing set up correctly? Is the network that 192.168.3.250 is on in the same subnet as one of the firewall interfaces? Or is it a separate network? You'd need to add a route for it if it's separate. I had something funky happen with my routes at one point and had to re-add. Good luck I enable it.. what happens.. I loose connectivity to all the networks. Nothing can see anything outside of their network. do a ping from the firewall, and you get: ping: sendto: No route to host ping: wrote 192.168.3.250 64 chars, ret=-1 Anyone have any ideas?
