Re: ipfw confusion
On 08/20/13 12:41, Dan Lists wrote: You might turn on logging and post the logs of what is being blocked. Sometimes things are being blocked by rules you do not expect. Thanks for the suggestion. I was seeing refusals from named and mistakenly interpreting them as ipfw issues. On Mon, Aug 19, 2013 at 4:18 PM, Gary Aitken vagab...@blackfoot.net wrote: On 08/19/13 00:36, Jason Cox wrote: Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. There are identical rules included for udp: 21149 allow udp from any to 12.32.44.142 dst-port 53 in via tun0 keep-state 21169 allow udp from any to 12.32.36.65 dst-port 53 in via tun0 keep-state One of the requests which is being refused is a zone transfer request from a secondary which is a tcp request. Others are probably udp. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken vagab...@blackfoot.net wrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? ___ 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: ipfw confusion
You might turn on logging and post the logs of what is being blocked. Sometimes things are being blocked by rules you do not expect. On Mon, Aug 19, 2013 at 4:18 PM, Gary Aitken vagab...@blackfoot.net wrote: On 08/19/13 00:36, Jason Cox wrote: Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. There are identical rules included for udp: 21149 allow udp from any to 12.32.44.142 dst-port 53 in via tun0 keep-state 21169 allow udp from any to 12.32.36.65 dst-port 53 in via tun0 keep-state One of the requests which is being refused is a zone transfer request from a secondary which is a tcp request. Others are probably udp. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken vagab...@blackfoot.net wrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? ___ 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 ___ 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 ___ 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: ipfw confusion
Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken vagab...@blackfoot.netwrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? ___ 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 -- Jason Cox ___ 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: ipfw confusion
On Sun, Aug 18, 2013 at 8:06 PM, Gary Aitken vagab...@blackfoot.net wrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? I think you need explict rules like n allow tcp from 12.32.44.142 to any dst-port 53 out via tun0 setup keep-state careful I'm just winging the syntax, better check the docsa for sure. -- Gary Dunn Open Slate Project http://openslate.org/ ___ 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: ipfw confusion
On Mon, Aug 19, 2013 at 1:06 AM, Gary Aitken vagab...@blackfoot.net wrote: ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any What am I missing? Do you have a check-state rule earlier in your rules? 1000 check-state Dan ___ 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: ipfw confusion
On 08/19/13 11:53, OpenSlate ChalkDust wrote: On Sun, Aug 18, 2013 at 8:06 PM, Gary Aitken vagab...@blackfoot.net wrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? I think you need explict rules like n allow tcp from 12.32.44.142 to any dst-port 53 out via tun0 setup keep-state Why would rules like that be necessary, given the conversation is initiated from the outside? Shouldn't setup keep-state let the whole conversation, both directions, through? On 08/19/13 13:36, Dan Lists wrote: Do you have a check-state rule earlier in your rules? 1000 check-state Yes: 00500 check-state ___ 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: ipfw confusion
On 08/19/13 00:36, Jason Cox wrote: Are you sure that your DNS requests are over TCP? DNS primarily uses UDP to serve requests. TCP is used when the response data size exceeds 512 bytes (I think), or for tasks such as zone transfers. I know a few resolver implementations use TCP for all queries, but most I have used not. You might want to add rules to allow UDP as well. There are identical rules included for udp: 21149 allow udp from any to 12.32.44.142 dst-port 53 in via tun0 keep-state 21169 allow udp from any to 12.32.36.65 dst-port 53 in via tun0 keep-state One of the requests which is being refused is a zone transfer request from a secondary which is a tcp request. Others are probably udp. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken vagab...@blackfoot.netwrote: I'm having some weird ipfw behavior, or it seems weird to me, and am looking for an explaination and then a way out. ipfw list ... 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup keep-state 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup keep-state ... 65534 deny log logamount 5 ip from any to any tail -f messages Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error sending response: permission denied 12.32.36.65 is the addr of the internal interface (xl0) on the firewall and is the public dns server. 12.32.44.142 is the addr of the external interface (tun0) which is bridged on a dsl line. It appears that a dns request was allowed in, but the response was not allowed back out. It seems to me the above rules 21109 and 21129 should have allowed the request in and the response back out. It's possible a request could come in on 12.32.44.142, which is why 21109 is present; although I know I am getting failures to reply to refresh requests from a secondary addressed to 12.32.36.65 What am I missing? Is there a problem if the incoming rule is for tun0, which gets passed to named since 12.32.44.142 is on the physical machine running named, but named pumps its response out on 12.32.36.65, relying on routing to get it to the right place, and that fails to match the state tracking mechanism which started with 12.32.44.142? ___ 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 ___ 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: IPFW confusion
Hi, However, I can't get the config to work. I've commented out all the deny rules. In this instance, I can browse the web via SQUID that's installed on the IPFW box. I can't browse the web directly, though. That is the only external access I get. I can't ping any sites, DNS lookups fail (I've set the DNS servers on the client workstation to be that my ISP's. I also tried setting it to look at the IPFW box first, with no luck) Can anyone offer help on this one? I'm getting stuck in a muddle of mis-understanding At work so I don't have time to debug a whole policy or anything but Firstly, I agree with the comments about logging a deny all at the end of your policy. If you start logging too much rubbish insert specific deny rules that do NOT log just above the deny all to filter out things you don't want to see. To be honest, it's good practice to keep this approach permantently. Secondly, a handy tool is at fwbuilder.org . This provides a GUI interface for generating your policy. It's not perfect and theres the whole thing of sacrificing all the command line options for a GUI interface but I've found it more than useful on my own gateway device. Unfortunately, the NAT part is not working so you need to script how the rules are installed once compiled to ensure you get a NAT rule in place. I have posted a script to do this in previous emails but feel free to drop me a reply in future if you need to. Thanks, Phil. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW confusion
Hi Subhro, Thanks for your reply The reason I want the server to route between the internal network and the router is because I only want to allow specific clients out onto the internet, and I can't see how to do this with the router I've got. Plus, it's a good excuse to try to learn something new :-) You say it's expected that I can't ping. It's things like this that confuse me, due to lack of understanding on my part, I've allowed all traffic through. Of so I thought... I've had a quick skim of the HOWTO, and it seems informative. But, it's still the IPFW rules that get me all confused Ben Subhro wrote: Hi Ben, First of all I must say you explained your requirements very well. Not many people can precisely say what they need. Bravo! Let's get to the point now. First of all I d don't find a good reason why you would like to introduce your system (192.168.0.10) (Lets call it server) to work as a router although you have a dedicated router. You can be well off adding routes in the D-Link and be off with it. If you really want to live with your current setup, then you must decide whether you want to go with NAT or with transparent proxy. With your current setup, it is perfectly all right that you can't ping any external hosts. I would recommend that you go with NAT guarded by ipfw at the server. But you may also go with transparent proxy as it has its own advantages. Refer to the following page: http://www.erudition.net/freebsd/NAT-HOWTO This has a really good tutorial on setting up NAT Regards Subhro Subhro Sankha Kar Indian Institute of Information Technology Block AQ-13/1, Sector V Salt Lake City PIN 700091 India -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Quick Sent: Wednesday, January 07, 2004 11:05 PM To: [EMAIL PROTECTED] Subject: IPFW confusion Hello all, I've been hunting around for information on IPFW, and how to set up the rules I require. I found a tutorial that seemed to fit my needs: http://www.mostgraveconcern.com/freebsd/ipfw.html However, I can't get the config to work. I've commented out all the deny rules. In this instance, I can browse the web via SQUID that's installed on the IPFW box. I can't browse the web directly, though. That is the only external access I get. I can't ping any sites, DNS lookups fail (I've set the DNS servers on the client workstation to be that my ISP's. I also tried setting it to look at the IPFW box first, with no luck) Can anyone offer help on this one? I'm getting stuck in a muddle of mis-understanding My setup is as follows Internal LAN is 192.168.0.x IPFW machine has 2 NIC's: rl0: 192.168.0.10 rl1: 172.16.200.10 rl1 connects directly to my DSL router (D-Link 504) which has an internal IP of 172.16.200.1 along with it's public IP on the DSL port The ruleset I'd like is as follows For client IP's of 192.168.0.1 - 192.168.0.20 allow the following HTTP \ HTTPS - But not directly, force them to use SQUID (Listening on port 8080, and using squidGuard for content filtering) POP3 - But, only so far as pop.myisp.com IMAP - But, only so far as imap.myisp.com SMTP - But, only so far as smtp.myisp.com DNS lookups - But, only with ns1.myisp.com and ns2.myisp.com NNTP - But, only so far as news.myisp.com FTP - To anywhere For client IP's of 192.168.0.21 - 192.168.0.254 no access to anything external to the 192.168.0.x network should be granted I'd like the IPFW box and 192.168.0.1 to be able to SSH out to anywhere. I'd like to allow SSH inbound from a specific IP to be directed at the IPFW box (The port forwarding can be done with the DSL router) - SSH isn't currently listening on that interface, I'll get to that later :) Does this sound like a reasonable ruleset? Is anyone willing to help me generate it? Thanks Ben ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW confusion
Ben Quick wrote: Hello all, I've been hunting around for information on IPFW, and how to set up the rules I require. I found a tutorial that seemed to fit my needs: http://www.mostgraveconcern.com/freebsd/ipfw.html However, I can't get the config to work. I've commented out all the deny rules. In this instance, I can browse the web via SQUID that's installed on the IPFW box. I can't browse the web directly, though. That is the only external access I get. I can't ping any sites, DNS lookups fail (I've set the DNS servers on the client workstation to be that my ISP's. I also tried setting it to look at the IPFW box first, with no luck) Can anyone offer help on this one? I'm getting stuck in a muddle of mis-understanding My setup is as follows Internal LAN is 192.168.0.x IPFW machine has 2 NIC's: rl0: 192.168.0.10 rl1: 172.16.200.10 rl1 connects directly to my DSL router (D-Link 504) which has an internal IP of 172.16.200.1 along with it's public IP on the DSL port The ruleset I'd like is as follows For client IP's of 192.168.0.1 - 192.168.0.20 allow the following HTTP \ HTTPS - But not directly, force them to use SQUID (Listening on port 8080, and using squidGuard for content filtering) POP3 - But, only so far as pop.myisp.com IMAP - But, only so far as imap.myisp.com SMTP - But, only so far as smtp.myisp.com DNS lookups - But, only with ns1.myisp.com and ns2.myisp.com NNTP - But, only so far as news.myisp.com FTP - To anywhere For client IP's of 192.168.0.21 - 192.168.0.254 no access to anything external to the 192.168.0.x network should be granted I'd like the IPFW box and 192.168.0.1 to be able to SSH out to anywhere. I'd like to allow SSH inbound from a specific IP to be directed at the IPFW box (The port forwarding can be done with the DSL router) - SSH isn't currently listening on that interface, I'll get to that later :) Does this sound like a reasonable ruleset? Is anyone willing to help me generate it? Thanks Ben Hello, Your best coarse of action is to add: 'ipfw add 65000 deny log all from any to any'. Then watch #/var/log/security for the hits as you attempt to access the internet. Build your firewall rules above the 65000 rule to eliminate the traffic from the log. The log will give you all the correct addresses and ports. -Ryan Merrick [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
