Re: IPFW Questions.
"Grant Peel" <[EMAIL PROTECTED]> writes: > I was wondering what the concensus is on using dynamic rules in IPFW. Every > once in a while, I suppose there is a DoS attaclk that causes me to see > hundreds of: > > +ipfw: install_state: Too many dynamic rules > > in my security log. > > I am sure i read somewhere that many people are skipping the dynamic rules > and just relying on the line by line rules. > > You thoughts please. You shouldn't allow people outside the network to invoke a dynamic rule; that's a limited resource that they can overwhelm, as you see. Usual practice is to set up state only on already-confirmed connections; in my case, that means only outbound packets that didn't match any previous state. > Any while your up, does anyone really know what this means? > > ipfw: pullup failed > > I dont see that often maybe 1 or 2 times a month. A "pullup" is just advancing deeper into the packet. If it failed, that probably means the packet was too short. Truncated packets can happen for a number of benign reasons, but if they happen frequently they're probably a sign of a problem in your network equipment. By "frequently" I mean several orders of magnitude more than you're seeing them. Don't worry about it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: IPFW Questions.
I have same problem related to ipfw pullup. I couldn't find any documentation or solution on it. Narek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Peel Sent: Monday, August 20, 2007 6:07 PM To: freebsd-questions@freebsd.org Subject: IPFW Questions. Hi all, I was wondering what the concensus is on using dynamic rules in IPFW. Every once in a while, I suppose there is a DoS attaclk that causes me to see hundreds of: +ipfw: install_state: Too many dynamic rules in my security log. I am sure i read somewhere that many people are skipping the dynamic rules and just relying on the line by line rules. You thoughts please. Any while your up, does anyone really know what this means? ipfw: pullup failed I dont see that often maybe 1 or 2 times a month. -Grant ___ 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]"
IPFW Questions.
Hi all, I was wondering what the concensus is on using dynamic rules in IPFW. Every once in a while, I suppose there is a DoS attaclk that causes me to see hundreds of: +ipfw: install_state: Too many dynamic rules in my security log. I am sure i read somewhere that many people are skipping the dynamic rules and just relying on the line by line rules. You thoughts please. Any while your up, does anyone really know what this means? ipfw: pullup failed I dont see that often maybe 1 or 2 times a month. -Grant ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw questions
Thanks for the replies! On 2/25/07, Andrew Pantyukhin <[EMAIL PROTECTED]> wrote: On 2/25/07, Curby <[EMAIL PROTECTED]> wrote: If you don't forward packets, then it's not very different, packets for "not me" are gonna get dropped anyway right after the firewall. Thanks! I think I found a case where to all is preferable over to me. Since SMB seems to like broadcasting things, I'm allowing like the following instead of to me: allow udp from any 137,138 to any in keep-state I guess I could write a rule with "to me" and another with the broadcast address of my subnet, but this is simpler. =) There are a lot of complicated/illegal configurations when verrevpath shoots you in the foot. Keeping rules simple and stupid will save you a lot of headache in the end. I'll keep that in mind as I go forward. I'm interested in trying to do traffic control and NAT via hand-written configurations. =) On 2/26/07, Nikos Vassiliadis <[EMAIL PROTECTED]> wrote: Most ready-to-use rulesets will have such generalizations. It's not much of a difference, you can't say they are wrong and since you know exactly what you want to achieve, it's up to you to change them to fit perfectly your situation... Yeah, I wasn't really asking about the default/policy rule so much as asking for opinions on "to me" vs "to all" for service-related rules, like: allow tcp from any to me 22 in keep-state As I found out, troublesome UDP protocols sometimes send to multicast/broadcast addresses so that might be a reason for "to all". I don't know about Mac but on FreeBSD they are redundant anyway. The TCP/IP stack denies packets from/to 127/8 coming from a wire, and it also denies sending packets to/from 127/8 down to a wire. Thanks for the notes about the multicast address space. I guess I'll just try to keep the ruleset simple and compact, then tweak as I go. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw questions
On Sunday 25 February 2007 13:33, Curby wrote: > I'm using IPFW2 on a Mac, but hopefully these questions are general > enough for this list. > > First, is there any reason not to prefer "from any to any" over "from > any to me" when adding rules to allow access to local services? Some > ipfw configurations I've found use "from any to any," which doesn't > seem bad except that it's unnecessarily general. > Firewalls also protect networks and not just single computers. These rules are quite generic. A "deny ip from any to any" would be a good default for a firewall and so it is by default: from ipfw man: An ipfw ruleset always includes a default rule (numbered 65535) which cannot be modified or deleted, and matches all packets. The action asso- ciated with the default rule can be either deny or allow depending on how the kernel is configured. Most ready-to-use rulesets will have such generalizations. It's not much of a difference, you can't say they are wrong and since you know exactly what you want to achieve, it's up to you to change them to fit perfectly your situation... > Also, there's a verrevpath option but Apple's default ruleset still > uses the following: > > deny log ip from 127.0.0.0/8 to any in > deny log ip from any to 127.0.0.0/8 in > deny log ip from 224.0.0.0/3 to any in > deny log tcp from any to 224.0.0.0/3 in > > Is it correct that verrevpath should make these redundant/obsolete? > deny log ip from 127.0.0.0/8 to any in > deny log ip from any to 127.0.0.0/8 in I don't know about Mac but on FreeBSD they are redundant anyway. The TCP/IP stack denies packets from/to 127/8 coming from a wire, and it also denies sending packets to/from 127/8 down to a wire. > deny log ip from 224.0.0.0/3 to any in A 224/4 source address is just not valid. The rest (240/4) is reserved for future use. > deny log tcp from any to 224.0.0.0/3 in Also, it's not possible to multicast TCP(224/4). Since 240/4 is reserved for future I would say they are invalid too. So, these rules protect weak TCP/IP stacks. They are filtering what is already invalid. > It'd be nice to have one rule instead of 4, but I'm wondering why > Apple isn't using its own supported features. Thanks! I would feel safe without such firewall rules on a personal FreeBSD box. Also if you don't feel safe, remember that ipfw comes with a "deny ip from any to any" rule by default. HTH, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw questions
On 2/25/07, Curby <[EMAIL PROTECTED]> wrote: I'm using IPFW2 on a Mac, but hopefully these questions are general enough for this list. ipfw@ might be more appropriate First, is there any reason not to prefer "from any to any" over "from any to me" when adding rules to allow access to local services? Some ipfw configurations I've found use "from any to any," which doesn't seem bad except that it's unnecessarily general. If you don't forward packets, then it's not very different, packets for "not me" are gonna get dropped anyway right after the firewall. Also, there's a verrevpath option but Apple's default ruleset still uses the following: deny log ip from 127.0.0.0/8 to any in deny log ip from any to 127.0.0.0/8 in deny log ip from 224.0.0.0/3 to any in deny log tcp from any to 224.0.0.0/3 in Is it correct that verrevpath should make these redundant/obsolete? It'd be nice to have one rule instead of 4, but I'm wondering why Apple isn't using its own supported features. Thanks! There are a lot of complicated/illegal configurations when verrevpath shoots you in the foot. Keeping rules simple and stupid will save you a lot of headache in the end. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw questions
I'm using IPFW2 on a Mac, but hopefully these questions are general enough for this list. First, is there any reason not to prefer "from any to any" over "from any to me" when adding rules to allow access to local services? Some ipfw configurations I've found use "from any to any," which doesn't seem bad except that it's unnecessarily general. Also, there's a verrevpath option but Apple's default ruleset still uses the following: deny log ip from 127.0.0.0/8 to any in deny log ip from any to 127.0.0.0/8 in deny log ip from 224.0.0.0/3 to any in deny log tcp from any to 224.0.0.0/3 in Is it correct that verrevpath should make these redundant/obsolete? It'd be nice to have one rule instead of 4, but I'm wondering why Apple isn't using its own supported features. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Newbie IPFW Questions
Dave McCammon wrote: --- Jim Campbell <[EMAIL PROTECTED]> wrote: Glenn Dawson wrote: At 08:18 PM 7/17/2005, Jim Campbell wrote: I have a machine set up as a classroom to learn about FreeBSD. It is running 4.11 primarily because anything later can't see my hard drive. As background, my FBSD machine has an address of 192.168.1.110. It is situated behind a hardware firewall (a Linksys router). $pif is vr0. I'm having problems setting up IPFW to communicate with an Onion router. The puzzling part is that I am able to use the Onion router but my /var/log/security file says that some of the packets are being dropped. Following is what I hope are the pertinent lines from my /etc/ipfw.rules file: $cmd 00225 allow tcp from me to any 9001-9033 out via $pif setup keep-state $cmd 00299 deny log all from me to any out via $pif $cmd 00332 deny log tcp from any to me established in via $pif Next is an excerpt from the /var/log/security file: Jul 17 21:49:58 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:2218 128.148.34.133:9001 out via vr0 Jul 17 21:49:59 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:4959 131.175.189.134:9001 out via vr0 Jul 17 21:50:18 JimsP1G /kernel: ipfw: 332 Deny TCP 128.148.34.133:9001 192.168.1.110:2218 in via vr0 Jul 17 21:50:29 JimsP1G /kernel: ipfw: 332 Deny TCP 131.175.189.134:9030 192.168.1.110:4566 in via vr0 Now my questions. First, why isn't rule 225 allowing all the packets out to the Onion router? It seems to me that ipfw should allow all packets in the port range 9001-9033 out or none. Rule 225 will only match packets used to setup the tcp session, once it's established you need another rule that will allow the established session to function. Rule 299 is denying everything from leaving your machine except for the packets allowed by rule 225. It appears that I didn't include enough of the ipfw.rules file. Following is another abstract: # # Allow the packet through if it has previous been added to the # the "dynamic" rules table by a allow keep-state statement. # $cmd 00015 check-state It's my understanding that this rule allows through any returning packets that match the dynamic rule established by Rule 225. Next, the two inbound packets should be returning in response to an outbound packet. Why are they being dropped? Are they exceeding some timeout? Rule 332 is denying all established traffic from entering your machine. So, while rule 225 allows you to establish a tcp session with another system on ports 9001-9033, once the session is established, rule 225 no longer applies and rule 332 is then throwing all those packets away. -Glenn Part of my problem is that I don't understand the protocols being used by the Onion routers. It appears that Tor (the application on my machine that sets up the communication with the Onion routers) begins to communicate with the Onion routers as soon as it starts. This communication continues as long as the FBSD machine is alive. Really shook me up when I first started using Tor and Privoxy. I thought someone was hacking my machine :-) The really puzzling thing about this situation is that at least some of the messages concerning the Onion protocol are getting through. I can ask for www.google.com and sometimes it resolves to Google in Europe, sometimes to Google in Asia, and sometines to Google here in the US. Ipfw appears to be only dropping some of the packets. Perhaps I should set up another machine to sniff the packets that occur. Maybe that would give me an idea of what is happening with the Onion protocol. In any event, thanks for your input to my problem, and if you have any other ideas I would appreciate them very much. I've been chewing on this problem the better part of a week. Thanks, Jim check the output of #ipfw show and make sure the check-state line is there. Your config says- $cmd 00015 check-state and I think..(at least on a 5.4 machine) it should say $cmd 00015 add check-state Dave, #ipfw show does show that check-state is there I am using a 4.11 machine and $cmd = "ipfw -q add" The command "#ipfw -a list" shows that there are many replies for each outbound packet to port 9001. I suppose that I should just let things be since the Tor service is working satisfactorily and I sure have learned a lot about firewalls while chasing
Re: Newbie IPFW Questions
--- Jim Campbell <[EMAIL PROTECTED]> wrote: > Glenn Dawson wrote: > > > At 08:18 PM 7/17/2005, Jim Campbell wrote: > > > >> I have a machine set up as a classroom to learn > about FreeBSD. It is > >> running 4.11 primarily because anything later > can't see my hard drive. > >> > >> As background, my FBSD machine has an address of > 192.168.1.110. It is > >> situated behind a hardware firewall (a Linksys > router). $pif is vr0. > >> > >> I'm having problems setting up IPFW to > communicate with an Onion router. > >> The puzzling part is that I am able to use the > Onion router but my > >> /var/log/security file says that some of the > packets are being dropped. > >> > >> Following is what I hope are the pertinent lines > from my /etc/ipfw.rules > >> file: > >> > >> $cmd 00225 allow tcp from me to any 9001-9033 out > via $pif setup > >> keep-state > >> $cmd 00299 deny log all from me to any out via > $pif > >> $cmd 00332 deny log tcp from any to me > established in via $pif > >> > >> Next is an excerpt from the /var/log/security > file: > >> > >> Jul 17 21:49:58 JimsP1G /kernel: ipfw: 299 Deny > TCP 192.168.1.110:2218 > >> 128.148.34.133:9001 out via vr0 > >> Jul 17 21:49:59 JimsP1G /kernel: ipfw: 299 Deny > TCP 192.168.1.110:4959 > >> 131.175.189.134:9001 out via vr0 > >> Jul 17 21:50:18 JimsP1G /kernel: ipfw: 332 Deny > TCP 128.148.34.133:9001 > >> 192.168.1.110:2218 in via vr0 > >> Jul 17 21:50:29 JimsP1G /kernel: ipfw: 332 Deny > TCP 131.175.189.134:9030 > >> 192.168.1.110:4566 in via vr0 > >> > >> Now my questions. First, why isn't rule 225 > allowing all the packets > >> out > >> to the Onion router? It seems to me that ipfw > should allow all packets > >> in the port range 9001-9033 out or none. > > > > > > Rule 225 will only match packets used to setup the > tcp session, once > > it's established you need another rule that will > allow the established > > session to function. > > > > Rule 299 is denying everything from leaving your > machine except for > > the packets allowed by rule 225. > > > > > It appears that I didn't include enough of the > ipfw.rules file. > Following is another abstract: > > # > # Allow the packet through if it has previous been > added to the > # the "dynamic" rules table by a allow keep-state > statement. > # > $cmd 00015 check-state > > It's my understanding that this rule allows through > any returning > packets that match the dynamic rule established by > Rule 225. > > > >> Next, the two inbound packets should be returning > in response to an > >> outbound packet. Why are they being dropped? > Are they exceeding some > >> timeout? > > > > > > Rule 332 is denying all established traffic from > entering your > > machine. So, while rule 225 allows you to > establish a tcp session > > with another system on ports 9001-9033, once the > session is > > established, rule 225 no longer applies and rule > 332 is then throwing > > all those packets away. > > > > -Glenn > > > > > Part of my problem is that I don't understand the > protocols being used > by the Onion routers. It > appears that Tor (the application on my machine that > sets up the > communication with the > Onion routers) begins to communicate with the Onion > routers as soon as > it starts. This > communication continues as long as the FBSD machine > is alive. Really > shook me up > when I first started using Tor and Privoxy. I > thought someone was > hacking my machine :-) > > The really puzzling thing about this situation is > that at least some of > the messages concerning > the Onion protocol are getting through. I can ask > for www.google.com > and sometimes it > resolves to Google in Europe, sometimes to Google in > Asia, and sometines > to Google here > in the US. Ipfw appears to be only dropping some of > the packets. > > Perhaps I should set up another machine to sniff the > packets that > occur. Maybe that would > give me an idea of what is happening with the Onion > protocol. > > In any event, thanks for your input to my problem, > and if you have any > other ideas I would > appreciate them very much. I've been chewing on > this problem the better > part of a week. > > Thanks, > > Jim check the output of #ipfw show and make sure the check-state line is there. Your config says- $cmd 00015 check-state and I think..(at least on a 5.4 machine) it should say $cmd 00015 add check-state Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Newbie IPFW Questions
Glenn Dawson wrote: At 08:18 PM 7/17/2005, Jim Campbell wrote: I have a machine set up as a classroom to learn about FreeBSD. It is running 4.11 primarily because anything later can't see my hard drive. As background, my FBSD machine has an address of 192.168.1.110. It is situated behind a hardware firewall (a Linksys router). $pif is vr0. I'm having problems setting up IPFW to communicate with an Onion router. The puzzling part is that I am able to use the Onion router but my /var/log/security file says that some of the packets are being dropped. Following is what I hope are the pertinent lines from my /etc/ipfw.rules file: $cmd 00225 allow tcp from me to any 9001-9033 out via $pif setup keep-state $cmd 00299 deny log all from me to any out via $pif $cmd 00332 deny log tcp from any to me established in via $pif Next is an excerpt from the /var/log/security file: Jul 17 21:49:58 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:2218 128.148.34.133:9001 out via vr0 Jul 17 21:49:59 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:4959 131.175.189.134:9001 out via vr0 Jul 17 21:50:18 JimsP1G /kernel: ipfw: 332 Deny TCP 128.148.34.133:9001 192.168.1.110:2218 in via vr0 Jul 17 21:50:29 JimsP1G /kernel: ipfw: 332 Deny TCP 131.175.189.134:9030 192.168.1.110:4566 in via vr0 Now my questions. First, why isn't rule 225 allowing all the packets out to the Onion router? It seems to me that ipfw should allow all packets in the port range 9001-9033 out or none. Rule 225 will only match packets used to setup the tcp session, once it's established you need another rule that will allow the established session to function. Rule 299 is denying everything from leaving your machine except for the packets allowed by rule 225. It appears that I didn't include enough of the ipfw.rules file. Following is another abstract: # # Allow the packet through if it has previous been added to the # the "dynamic" rules table by a allow keep-state statement. # $cmd 00015 check-state It's my understanding that this rule allows through any returning packets that match the dynamic rule established by Rule 225. Next, the two inbound packets should be returning in response to an outbound packet. Why are they being dropped? Are they exceeding some timeout? Rule 332 is denying all established traffic from entering your machine. So, while rule 225 allows you to establish a tcp session with another system on ports 9001-9033, once the session is established, rule 225 no longer applies and rule 332 is then throwing all those packets away. -Glenn Part of my problem is that I don't understand the protocols being used by the Onion routers. It appears that Tor (the application on my machine that sets up the communication with the Onion routers) begins to communicate with the Onion routers as soon as it starts. This communication continues as long as the FBSD machine is alive. Really shook me up when I first started using Tor and Privoxy. I thought someone was hacking my machine :-) The really puzzling thing about this situation is that at least some of the messages concerning the Onion protocol are getting through. I can ask for www.google.com and sometimes it resolves to Google in Europe, sometimes to Google in Asia, and sometines to Google here in the US. Ipfw appears to be only dropping some of the packets. Perhaps I should set up another machine to sniff the packets that occur. Maybe that would give me an idea of what is happening with the Onion protocol. In any event, thanks for your input to my problem, and if you have any other ideas I would appreciate them very much. I've been chewing on this problem the better part of a week. Thanks, Jim ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Newbie IPFW Questions
At 08:18 PM 7/17/2005, Jim Campbell wrote: I have a machine set up as a classroom to learn about FreeBSD. It is running 4.11 primarily because anything later can't see my hard drive. As background, my FBSD machine has an address of 192.168.1.110. It is situated behind a hardware firewall (a Linksys router). $pif is vr0. I'm having problems setting up IPFW to communicate with an Onion router. The puzzling part is that I am able to use the Onion router but my /var/log/security file says that some of the packets are being dropped. Following is what I hope are the pertinent lines from my /etc/ipfw.rules file: $cmd 00225 allow tcp from me to any 9001-9033 out via $pif setup keep-state $cmd 00299 deny log all from me to any out via $pif $cmd 00332 deny log tcp from any to me established in via $pif Next is an excerpt from the /var/log/security file: Jul 17 21:49:58 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:2218 128.148.34.133:9001 out via vr0 Jul 17 21:49:59 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:4959 131.175.189.134:9001 out via vr0 Jul 17 21:50:18 JimsP1G /kernel: ipfw: 332 Deny TCP 128.148.34.133:9001 192.168.1.110:2218 in via vr0 Jul 17 21:50:29 JimsP1G /kernel: ipfw: 332 Deny TCP 131.175.189.134:9030 192.168.1.110:4566 in via vr0 Now my questions. First, why isn't rule 225 allowing all the packets out to the Onion router? It seems to me that ipfw should allow all packets in the port range 9001-9033 out or none. Rule 225 will only match packets used to setup the tcp session, once it's established you need another rule that will allow the established session to function. Rule 299 is denying everything from leaving your machine except for the packets allowed by rule 225. Next, the two inbound packets should be returning in response to an outbound packet. Why are they being dropped? Are they exceeding some timeout? Rule 332 is denying all established traffic from entering your machine. So, while rule 225 allows you to establish a tcp session with another system on ports 9001-9033, once the session is established, rule 225 no longer applies and rule 332 is then throwing all those packets away. -Glenn Thanks in advance. Jim Campbell ___ 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]"
Newbie IPFW Questions
I have a machine set up as a classroom to learn about FreeBSD. It is running 4.11 primarily because anything later can't see my hard drive. As background, my FBSD machine has an address of 192.168.1.110. It is situated behind a hardware firewall (a Linksys router). $pif is vr0. I'm having problems setting up IPFW to communicate with an Onion router. The puzzling part is that I am able to use the Onion router but my /var/log/security file says that some of the packets are being dropped. Following is what I hope are the pertinent lines from my /etc/ipfw.rules file: $cmd 00225 allow tcp from me to any 9001-9033 out via $pif setup keep-state $cmd 00299 deny log all from me to any out via $pif $cmd 00332 deny log tcp from any to me established in via $pif Next is an excerpt from the /var/log/security file: Jul 17 21:49:58 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:2218 128.148.34.133:9001 out via vr0 Jul 17 21:49:59 JimsP1G /kernel: ipfw: 299 Deny TCP 192.168.1.110:4959 131.175.189.134:9001 out via vr0 Jul 17 21:50:18 JimsP1G /kernel: ipfw: 332 Deny TCP 128.148.34.133:9001 192.168.1.110:2218 in via vr0 Jul 17 21:50:29 JimsP1G /kernel: ipfw: 332 Deny TCP 131.175.189.134:9030 192.168.1.110:4566 in via vr0 Now my questions. First, why isn't rule 225 allowing all the packets out to the Onion router? It seems to me that ipfw should allow all packets in the port range 9001-9033 out or none. Next, the two inbound packets should be returning in response to an outbound packet. Why are they being dropped? Are they exceeding some timeout? Thanks in advance. Jim Campbell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSec+VPN+ipfw questions
1. I'm using FreeBSD as a gateway+firewall which uses NAT (natd) to connect internal LAN to the Internet. So, gateway_enable=YES is set because it is required to use natd. 2. I prefer to use IPSec, and not a PPTP. As I can configure it on W2K using AD policies, so I don't have to setup it manually using wizards or suchlike. 3. I have a LAN where some machines have to use FreeBSD as gateway to the Internet, and some - no. All machines are in a common subnet, so physical route cannot be disabled for those machines. I think there is no problem here as I can set a VPN transport for some IP/MAC addresses and block all traffic from others. Note there is no tunnel for subnet - W2K-to-FreeBSD peer-to-peer only. The real problem is that I need to look into each IPSec-transported packet on the gateway machine after it is decrypted to divert it to natd. Also, I'm using some of counters such as 'count tcp from me 3128 to peer' (Squid traffic), etc. When all packets from local Squid are tunneled using IPSec the rule above always shows 0 as packets are encapsulated into esp protocol before captured by ipfw. And working rule will be 'count esp from me to peer' which does not give any information about properties of packet (source IP/port and so on). So, the question was: how to look into and count (using ipfw) those packets before they are encrypted by IPSec? 4. racoon is working, and, of course, I don't need the gif interface as I don't create a tunnel for subnet. The problem I mentioned is that when traffic flow stops for some time, and then it resumes, racoon or W2K machine want rekeying, and sometimes there is a long time delay before the rekeying takes place. I read this in FAQs and in fact I see the effect in my setup. I agree that some FAQs are not very accurate. All of them recommend to use only MD5 hash with W2K machines but I really see the SHA1 hash which works. Can you give some working example of racoon configuration which works fine with W2K? Thanks for the answers! OS - Original Message - From: "Brent Wiese" <[EMAIL PROTECTED]> To: "'Oleg Semyonov'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 24, 2003 4:26 AM Subject: RE: IPSec+VPN+ipfw questions A few things come quickly to mind... First, you need "gateway_enable=YES" in your rc.conf... I think. I know you need it for MPD (pptp tunneling). Second, you cannot have physical routes to the remote side "private" network. > 1) Is it possible to use ipfw rules to count different kinds > of traffic from legitimate computers, divert it to natd and > block all other packets across the LAN? There are ESP > protocol packets which I can filter, but it seems they are > not processed after decryption by ipwf rules. So, no > counters, no divert, etc. You should use ipfw to, at the very least, only allow legit tunnel traffic to pass to/from the "public" and "private" NICs/ > 2) What is the best solution for IKE daemon? I've tried > racoon (it works but there are some strange situations with > Windows 2000 machines which are mentioned somewhere), and > isakmpd (it has not very obvious syntax for their policy and > conf files - how to create a minimal working configuration > for a number of peer machines which use different preshared > keys for IKE exchange)? Racoon works fine if set up correctly. Most of the FAQ's are wrong, espcially when they discuss setting up gif() and then racoon. You don't need gif(). I seem to remember something about using MD5 as the hash, but its been a while... Maybe it was that my router only supported MD5 for its vpn-passthru stuff... > 3) In fact, it is not required for me to use VPN solutions. > All I need is to authenticate each legitimate machine (or > user - that is better). IP+MAC addresses may be forged. I can > use socks proxy, but there is no standard secured > authentication which is suported by number of different > internet tools. And I don't wish to have a complicated setup > of each client machine. So, VPN seems to be the best solution > as their policies for W2K clients may be specified via Active > Directory. IPSEC is probably the best way. Since the other side is Windows, you may consider using MPD and use PPTP instead of IPSEC. It's a little easier to deal with on the Windows side since setup is all gui-wizards. Cheers, Brent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: IPSec+VPN+ipfw questions
A few things come quickly to mind... First, you need "gateway_enable=YES" in your rc.conf... I think. I know you need it for MPD (pptp tunneling). Second, you cannot have physical routes to the remote side "private" network. > 1) Is it possible to use ipfw rules to count different kinds > of traffic from legitimate computers, divert it to natd and > block all other packets across the LAN? There are ESP > protocol packets which I can filter, but it seems they are > not processed after decryption by ipwf rules. So, no > counters, no divert, etc. You should use ipfw to, at the very least, only allow legit tunnel traffic to pass to/from the "public" and "private" NICs/ > 2) What is the best solution for IKE daemon? I've tried > racoon (it works but there are some strange situations with > Windows 2000 machines which are mentioned somewhere), and > isakmpd (it has not very obvious syntax for their policy and > conf files - how to create a minimal working configuration > for a number of peer machines which use different preshared > keys for IKE exchange)? Racoon works fine if set up correctly. Most of the FAQ's are wrong, espcially when they discuss setting up gif() and then racoon. You don't need gif(). I seem to remember something about using MD5 as the hash, but its been a while... Maybe it was that my router only supported MD5 for its vpn-passthru stuff... > 3) In fact, it is not required for me to use VPN solutions. > All I need is to authenticate each legitimate machine (or > user - that is better). IP+MAC addresses may be forged. I can > use socks proxy, but there is no standard secured > authentication which is suported by number of different > internet tools. And I don't wish to have a complicated setup > of each client machine. So, VPN seems to be the best solution > as their policies for W2K clients may be specified via Active > Directory. IPSEC is probably the best way. Since the other side is Windows, you may consider using MPD and use PPTP instead of IPSEC. It's a little easier to deal with on the Windows side since setup is all gui-wizards. Cheers, Brent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPSec+VPN+ipfw questions
Hi! I wish to use IPSec to provide secure channels between some LAN machines (Windows 2000) and a FreeBSD gateway which acts as a NAT router to the Internet upstream provider. Each channel works in IPSec transport mode (no tunnel, host-to-host only). FreeBSD runs racoon to provide IKE services for IPSec. FreeBSD 4.8, ipfw2. The questions are: 1) Is it possible to use ipfw rules to count different kinds of traffic from legitimate computers, divert it to natd and block all other packets across the LAN? There are ESP protocol packets which I can filter, but it seems they are not processed after decryption by ipwf rules. So, no counters, no divert, etc. 2) What is the best solution for IKE daemon? I've tried racoon (it works but there are some strange situations with Windows 2000 machines which are mentioned somewhere), and isakmpd (it has not very obvious syntax for their policy and conf files - how to create a minimal working configuration for a number of peer machines which use different preshared keys for IKE exchange)? 3) In fact, it is not required for me to use VPN solutions. All I need is to authenticate each legitimate machine (or user - that is better). IP+MAC addresses may be forged. I can use socks proxy, but there is no standard secured authentication which is suported by number of different internet tools. And I don't wish to have a complicated setup of each client machine. So, VPN seems to be the best solution as their policies for W2K clients may be specified via Active Directory. Thanks! OS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
