From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 22 09:13:59 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C59F416A400 for ; Sun, 22 Apr 2007 09:13:59 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 8520713C44C for ; Sun, 22 Apr 2007 09:13:59 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1505341ana for ; Sun, 22 Apr 2007 02:13:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=H4B3JXh7L9M/nwvwFp9jCtkZSIaqfD8AJsEppGA6/eJ78AQpCTmwhA756e5dYW3SSXNYaQcq6C7S/mH+VwdbEiIgXR2jYSgZHGJiFWbBa7+vK/fVNKSuFQRkg2LvRCBwbk8vcI6UBmfjH+JRFVXEty++jT4ffbf3Wb2R55OJSlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=dd//jxFGuxo7eWShMOMpNN2Oz4axjEk6CUj5c0x9gRnhHZTTGiS3DDu8D++tLuexZPG7p0FYe6idZmuxLe2JgRJkZHM5PYM/vaMqDqwLORMSJ5q+XvGp8KsV4W0N+J7S/7XdrAVLbU7XSL0+LCVkjoePXy8tDBANltb0gagBVyE= Received: by 10.100.201.11 with SMTP id y11mr2866856anf.1177233238837; Sun, 22 Apr 2007 02:13:58 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Sun, 22 Apr 2007 02:13:58 -0700 (PDT) Message-ID: <937e203f0704220213p13e559b7nd576788ae5dcc7@mail.gmail.com> Date: Sun, 22 Apr 2007 12:13:58 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 09:13:59 -0000 As a side note - I had found "sysctl net.link.ether.ipfw=1" and it was enabled during my endless futile attempts. I believe that my problem lies in my rules but I can't figure out what's wrong with them.... So someone please help. -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 22 10:09:55 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A794716A403 for ; Sun, 22 Apr 2007 10:09:55 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 31B2213C465 for ; Sun, 22 Apr 2007 10:09:54 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from [192.168.1.24] (200-206-137-212.speedyterra.com.br [200.206.137.212] (may be forged)) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3MA9nRO025086; Sun, 22 Apr 2007 07:09:49 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Sun, 22 Apr 2007 07:09:10 -0300 User-Agent: KMail/1.9.4 References: <937e203f0704220213p13e559b7nd576788ae5dcc7@mail.gmail.com> In-Reply-To: <937e203f0704220213p13e559b7nd576788ae5dcc7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704220709.11494.asstec@matik.com.br> X-Spam-Status: No, score=1.1 required=5.0 tests=MR_DIFF_MID, TW_PF autolearn=no version=3.1.8 X-Spam-Level: * X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 10:09:55 -0000 On Sunday 22 April 2007 06:13, Lubomir Georgiev wrote: > As a side note - I had found "sysctl net.link.ether.ipfw=3D1" and it was > enabled during my endless futile attempts. > I believe that my problem lies in my rules but I can't figure out what's > wrong with them.... So someone please help. you do not read with attention ... on a router (natd) you do not have layer2 traffic, obviously then you can n= ot=20 analise it, even loading if_bridge makes no sense since there is no such=20 traffic so you're wasting your time if you need to block MACs you need to do it on switch level or put a freebs= d=20 bridge between the stations and your natd gateway Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 22 10:59:29 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FF7116A400 for ; Sun, 22 Apr 2007 10:59:29 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 225F713C44C for ; Sun, 22 Apr 2007 10:59:29 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so1520861ana for ; Sun, 22 Apr 2007 03:59:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=TG/8+4yjGrQFFINWjxURlqrCZHd5rPiwz86IbBtle2hD5Qvbk9pEuKYJvzULvXiiIKobSsLZHFNhpEL2hSnZj1D5ChCRGbDeinghqYp/2ytcbhFVXeSNI45xh0tjOa+wi169jLEQeJQ9izxdaG1pOMWYitx0jCGCq9VebbhWHco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=q8xZRw3XGkJ9MEfnSvUV/rHdTTXofyCQM/iBXb9kYccPIlT6wxmvW69PD9C0ICtbpFWoik3VDPkBp1hDGGlSGceHKmqUSghWFm/QQuTWcFwtxSSaUG4SnM0oypgUDdOREW0et5cbzxhtbrZ6TKo0C3cHXXGCFMk4pggKG/POrQU= Received: by 10.100.241.20 with SMTP id o20mr156992anh.1177239567968; Sun, 22 Apr 2007 03:59:27 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Sun, 22 Apr 2007 03:59:27 -0700 (PDT) Message-ID: <937e203f0704220359y657f46b1y5401a10197d5bffa@mail.gmail.com> Date: Sun, 22 Apr 2007 13:59:27 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 10:59:29 -0000 Thanks for the response but I have to disagree with you - I have read the responses time and time again with great attention, but to no avail. From what you said I understand that in order to utilize MAC address filtering I would need a managed switch or another box aside from the one that will be performing the NATing - is that right? Are you sure that there's no way to combine MAC filtering with NAT in a single box? Just to make things clear I'll give an example of what I want to do - I want a machine with say MAC-a to have internet connectivity regardless of its IP address - that is I can assign to it any of the 192.168.1.Xaddresses. But if a machine with say MAC-b comes into the network and tries any IP I want it to be excluded from the NATd rule but still have connectivity with the FreeBSD box - so that I can open up a terminal and add it to the rulelist if I want Inet connectivity on that machine. P.S. I have heard of another way of filtering which uses the ARP tables - any comments on that? The thing that I don't think I'll be able to accomplish with the ARP tables is to use any of the 192.168.1.X IP addresses. Once again thanks for all your help and I hope we can reach the final conclusion of this problem. -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Sun Apr 22 12:49:21 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4B8E16A400 for ; Sun, 22 Apr 2007 12:49:21 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4DB9513C46E for ; Sun, 22 Apr 2007 12:49:21 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from [192.168.1.24] (200-206-137-212.speedyterra.com.br [200.206.137.212] (may be forged)) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l3MCnHFQ034627; Sun, 22 Apr 2007 09:49:18 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Sun, 22 Apr 2007 09:48:39 -0300 User-Agent: KMail/1.9.4 References: <937e203f0704220359y657f46b1y5401a10197d5bffa@mail.gmail.com> In-Reply-To: <937e203f0704220359y657f46b1y5401a10197d5bffa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704220948.40641.asstec@matik.com.br> X-Spam-Status: No, score=3.1 required=5.0 tests=MONOTONE_WORDS_15_2, MONOTONE_WORDS_30_2,MR_DIFF_MID,TW_PF autolearn=no version=3.1.8 X-Spam-Level: *** X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 12:49:21 -0000 On Sunday 22 April 2007 07:59, Lubomir Georgiev wrote: > Thanks for the response but I have to disagree with you - I have read t= he > responses time and time again with great attention, but to no avail. From > what you said I understand that in order to utilize MAC address filtering= I > would need a managed switch or another box aside from the one that will be > performing the NATing - is that right? Are you sure that there's no way to > combine MAC filtering with NAT in a single box? > man, you can control layer2 traffic only if you have some and this is not t= he=20 case on a natd router > P.S. I have heard of another way of filtering which uses the ARP tables - > any comments on that? The thing that I don't think I'll be able to > accomplish with the ARP tables is to use any of the 192.168.1.X IP > addresses. arptables on a router do not have anything to do with layer2 traffic you can fake the mac address and make it permanent in the arptable on the n= at=20 router which then certainly blocks the correct mac as well as you can open = a=20 door with an ax or check your blood pressure with a knife, what I am trying= =20 to say is that this are "last resource methods" Jo=E3o > Once again thanks for all your help and I hope we can reach the final > conclusion of this problem. A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 00:31:34 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE90D16A407 for ; Mon, 23 Apr 2007 00:31:34 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 97F6713C457 for ; Mon, 23 Apr 2007 00:31:33 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 81660 invoked by uid 0); 22 Apr 2007 21:11:22 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.17.233.44):. Processed in 0.952362 secs); 23 Apr 2007 00:11:22 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.233.44) by capeta.freebsdbrasil.com.br with SMTP; 22 Apr 2007 21:11:21 -0300 Message-ID: <462BF7D9.5010300@freebsdbrasil.com.br> Date: Sun, 22 Apr 2007 21:03:37 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704220359y657f46b1y5401a10197d5bffa@mail.gmail.com> In-Reply-To: <937e203f0704220359y657f46b1y5401a10197d5bffa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 00:31:34 -0000 I could not understand Joao's statement, so I tend to disagree that there is no layer2 traffic flowing on a NAT box. Makes no sense to me. I am sure it is possible to do all 2 sub-layer layer 2 filtering (MAC and LLC). So I have just tried what you are willing to get working Lubomir, right now in the network I am. My current enviroment is the simplest the possible: [ 10.69.0.0/16 network ] <=> [ switch ] <=> [FreeBSD] <=> [Internet] My external interface is vr0 My internal one is xl0 I have just allowed two stations to go to the DIVERT (natd) rules by using skipto approach, and all other machines are not skipped, so they tend to match an intermediary rule which does deny all traffic based on layer2. I kept only the relevant rules so it gets very clear to understand: # ipfw show 00300 688 62538 skipto 1000 ip from any to any { MAC any 08:00:46:bd:da:a3 or MAC any 00:17:31:df:bc:ab } layer2 00310 637 84252 skipto 1000 ip from any to any { MAC 08:00:46:bd:da:a3 any or MAC 00:17:31:df:bc:ab any } layer2 00500 468 30071 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 01000 527 50710 divert 8668 ip from 10.69.0.0/16 to any out via vr0 01100 556 68585 divert 8668 ip from any to me in via vr0 65535 14642 1214437 allow ip from any to any In case ipfw list may be clearer: # ipfw list 00300 skipto 1000 ip from any to any { MAC any 08:00:46:bd:da:a3 or MAC any 00:17:31:df:bc:ab } layer2 00310 skipto 1000 ip from any to any { MAC 08:00:46:bd:da:a3 any or MAC 00:17:31:df:bc:ab any } layer2 00500 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 01000 divert 8668 ip from 10.69.0.0/16 to any out via vr0 01100 divert 8668 ip from any to me in via vr0 65535 allow ip from any to any Some relevant information: I am doing selective divert based on my network, on vr0 (external interface) while explicitly denying all layer2 traffic based on mac, on rule 500, only on xl0 (internal network), because if I do it on all networks or on vr0, I will certainy deny my own outgoing packets. So it worked perfectly, and right now while I send this message only the two MAC addresses are allowed to get diverted to natd (and go to internet). As you can see, some traficc is still hitting rule # 500, so I want to know what it is: # grep 500 /var/log/security | tail -5 Apr 22 19:54:32 HomerSimpson kernel: ipfw: 500 Deny UDP 208.239.76.163:5060 10.69.69.39:5060 out via xl0 Apr 22 19:54:33 HomerSimpson kernel: ipfw: 500 Deny MAC in via xl0 Apr 22 19:54:36 HomerSimpson kernel: ipfw: 500 Deny UDP 208.239.76.163:5060 10.69.69.39:5060 out via xl0 Apr 22 19:54:37 HomerSimpson kernel: ipfw: 500 Deny MAC in via xl0 Apr 22 19:54:50 HomerSimpson kernel: ipfw: limit 100 reached on entry 500 So, it is IP 10.69.69.39, which for sure has a different MAC address: # arp 10.69.69.39 ? (10.69.69.39) at 00:12:17:fb:ee:e7 on xl0 [ethernet] You also said you wanted allow other stations to talk to the gateway, what in the above examples, I am not allowing, so for example if I add rule 400 like this: # ipfw add 400 allow all from 10.69.0.0/16 to me via xl0 not layer2 keep-state 00400 allow ip from 10.69.0.0/16 to me via xl0 not layer2 keep-state I am certainly allowing any station on 10.69/16 network, regardless of its IP address (unless it is on 10.69/16 network) or MAC address (since I am not filtering on layer2): # ipfw show 00300 2544 519800 skipto 1000 ip from any to any { MAC any 08:00:46:bd:da:a3 or MAC any 00:17:31:df:bc:ab } layer2 00310 2415 601710 skipto 1000 ip from any to any { MAC 08:00:46:bd:da:a3 any or MAC 00:17:31:df:bc:ab any } layer2 00400 29 2548 allow ip from 10.69.0.0/16 to me via xl0 not layer2 keep-state 00500 1236 65813 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 01000 1904 469946 divert 8668 ip from 10.69.0.0/16 to any out via vr0 01100 2049 525859 divert 8668 ip from any to me in via vr0 65535 42049 5911000 allow ip from any to any Since ipfw is a first-match-based firewall you don't need to worry about this "allow from any to any" rule, because the hosts which get to this rule certainly were not skipped on the later rules, so they simply never get diverted, because they match on this "allow" and divert rules happens AFTER the allow. Lets see who is matching rule # 400 (which is a keep-state rule, so it is generating dynamic state rules): ## Dynamic rules (2): 00400 1 100 (1s) STATE tcp 10.69.2.40 59235 <-> 10.69.2.1 22 00400 0 0 (0s) STATE udp 10.69.69.13 59577 <-> 10.69.69.1 53 Both 10.69.2.1 and 10.69.69.1 are "me" (the firewall itself). So just perfect, anyone can freely go through the private network, in the above dynamic we see an ssh session and an expired DNS query to the firewall which for sure is also the DNS server for the network). Last thing, remember to enabled ethernet filtering on IPFW: sysctl -w net.link.ether.ipfw=1 If not, no layer2 filtering will be processed at all. Also, when doing layer2 filtering, remember that the default IPFW behavior is to filter layer3 and above layers, but when you set net.link.ether.ipfw to true, it does layer2 and above, so all traffic going via ether_demux() and ether_output_frame() gets filtered. But the thing is that on the IP stack - /sys/net/if_ethersubr.c (where ether_demux() and ether_output_frame() happen) - layer2 traffic happen before the upper layers. So when doing ipfw layer firewall remember: - layer2 rules will get processed first - non layer specified rules will get processed two times, on layer2 and upper layers - not layer2 (meaning all upper layers) will get processed only later Hope this working example is a good start poing for your setup. Lubomir Georgiev escreveu: > Thanks for the response but I have to disagree with you - I have read the > responses time and time again with great attention, but to no avail. From > what you said I understand that in order to utilize MAC address filtering I > would need a managed switch or another box aside from the one that will be > performing the NATing - is that right? Are you sure that there's no way to > combine MAC filtering with NAT in a single box? > > Just to make things clear I'll give an example of what I want to do - I > want a machine with say MAC-a to have internet connectivity regardless of > its IP address - that is I can assign to it any of the > 192.168.1.Xaddresses. But if a machine with say MAC-b comes into the > network and tries > any IP I want it to be excluded from the NATd rule but still have > connectivity with the FreeBSD box - so that I can open up a terminal and > add > it to the rulelist if I want Inet connectivity on that machine. > > > > P.S. I have heard of another way of filtering which uses the ARP tables - > any comments on that? The thing that I don't think I'll be able to > accomplish with the ARP tables is to use any of the 192.168.1.X IP > addresses. > > Once again thanks for all your help and I hope we can reach the final > conclusion of this problem. > -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 05:38:37 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6400616A401 for ; Mon, 23 Apr 2007 05:38:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4F33613C4B7 for ; Mon, 23 Apr 2007 05:38:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sun, 22 Apr 2007 22:06:15 -0700 Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 51859125AF9; Sun, 22 Apr 2007 22:38:36 -0700 (PDT) Message-ID: <462C4667.1080800@elischer.org> Date: Sun, 22 Apr 2007 22:38:47 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: AT Matik References: <937e203f0704220213p13e559b7nd576788ae5dcc7@mail.gmail.com> <200704220709.11494.asstec@matik.com.br> In-Reply-To: <200704220709.11494.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org, Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 05:38:37 -0000 AT Matik wrote: > On Sunday 22 April 2007 06:13, Lubomir Georgiev wrote: >> As a side note - I had found "sysctl net.link.ether.ipfw=1" and it was >> enabled during my endless futile attempts. >> I believe that my problem lies in my rules but I can't figure out what's >> wrong with them.... So someone please help. > > you do not read with attention ... > > on a router (natd) you do not have layer2 traffic, obviously then you can not > analise it, even loading if_bridge makes no sense since there is no such > traffic so you're wasting your time > > if you need to block MACs you need to do it on switch level or put a freebsd > bridge between the stations and your natd gateway you are incorrect. The data will pass through the firewall as it enters and exits the system via the ethernet interfaces. The trick is that it will also pass through the firewall when it is routing in and out of the system at the IP level. What I always do is something like: ipfw add 10 skipto 1000 ip from any to any not layer2 # now we are only processing packets from the ethernet layer. keep track of sessions with MAC addresses we don't want to NAT ipfw add 100 skipto 3000 {mac spec} keep_state [...] # now we do layer 3 processing. # divide up according to interface and direction. ipfw add 100 skipto 1000 ip from any to any in recv ${inside_interface} ipfw add 101 skipto 1100 ip from any to any out xmit ${inside_interface} ipfw add 102 skipto 1200 ip from any to any in recv ${outside_interface} ipfw add 103 skipto 1300 ip from any to any out xmit ${outside_interface} # effectively we are not filtering anything else ipfw add 104 accept ip from any to any ipfw add 1000 allow ip from any to any ipfw add 1100 allow ip from any to any # Now the outside interface where NAT happens. # first incoming packets are always sent to NAT of they are to us. # unless the layer2 code exempted the session in question. They will go to 3000 ipfw add 1200 check-state ipfw add 1201 divert natd ip from any to ${outside_address} # The same number.. drop anything not diverted. ipfw add 1201 drop ip from any to any # nat/divert will reinject the packet here. ipfw add 1202 accept ip from any to any # now the outgoing packets. ipfw add 1300 check-state ifpw add 1301 accept ip from ${outside_address} to any ipfw add 1302 divert natd ip from any to any. # anything NATD allows through will be reinjected here. ipfw add 1303 accept ip from any to any # when the layer2 packets come here, just let them go on.. ipfw add 3000 accept ip from any to any layer2 # but when the layer 3 packets come here.. do something completely different. [....] > > Joćo > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 11:08:36 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56E6316A403 for ; Mon, 23 Apr 2007 11:08:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 2E87613C45A for ; Mon, 23 Apr 2007 11:08:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3NB8aB7093146 for ; Mon, 23 Apr 2007 11:08:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3NB8Yfi093142 for freebsd-ipfw@FreeBSD.org; Mon, 23 Apr 2007 11:08:34 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Apr 2007 11:08:34 GMT Message-Id: <200704231108.l3NB8Yfi093142@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 11:08:36 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp p conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/111713 ipfw [dummynet] Too few dummynet queue slots 21 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 19:13:40 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23E2C16A40B for ; Mon, 23 Apr 2007 19:13:40 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id D939A13C4AD for ; Mon, 23 Apr 2007 19:13:39 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2024424ana for ; Mon, 23 Apr 2007 12:13:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=i8HtP9nPvFQkizlH1wiPThIvaIl/kQ8NGhf314qUfIFg3SjrhHTVQ1KNoyzKl10fM7isrLr1OokjhUxQ4U1GqWRefaReYP7Mw4ARYQ161Ft0zJXd9xcf9LFb0R2wvFglJRknxWMbxdzkKFjYFl0g4TAwCyj/YErBpxBAiCLVrog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cJJuC21PMhIsYqTPPkTMBjgYB8l2WUE7jq1r35zKzf8RguJZ60qgd2uScdbnrSfkoDpYgjoScfpG5ncoMJn1JI8qcHmk2JugkMJLVYfWf7WAEbG+LeYCT2bogaUSvhyBd9b4yI7QcdE6dZTAUKNfuRxpmXMoGCL97D8Jnwm7C8I= Received: by 10.100.109.13 with SMTP id h13mr3967882anc.1177355618852; Mon, 23 Apr 2007 12:13:38 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Mon, 23 Apr 2007 12:13:38 -0700 (PDT) Message-ID: <937e203f0704231213l374167c8kbd8efd3e1fee4c45@mail.gmail.com> Date: Mon, 23 Apr 2007 22:13:38 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 19:13:40 -0000 I'd like to thank all the people who replied to the thread I started. Your help has been invaluable. The reason I didn't immediately respond to Jao is that I wanted to make sure I wasn't mistaking - I was sure that IPFW + NAT + MAC address filtering in a single box was possible because I had seen it with my own two eyes. I just didn't take the time to see the ruleset then. I was going there in a couple of days and was going to shed some light on the subject but it turns out I don't need to - Patrick and Julian have backed me up. I am going to try out what you've recommended and post the results. Once again thanks for all your efforts and Jao please do try not to go all "high and mighty" over other seeking help when what we really want is one and the same thing - to help each other, and that I think is the purpose of this list. So, I'll keep you posted. -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 19:59:38 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 613FD16A406 for ; Mon, 23 Apr 2007 19:59:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 4F38613C45A for ; Mon, 23 Apr 2007 19:59:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 23 Apr 2007 12:27:08 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 8E6E2125ADB; Mon, 23 Apr 2007 12:59:33 -0700 (PDT) Message-ID: <462D1033.8030309@elischer.org> Date: Mon, 23 Apr 2007 12:59:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704231213l374167c8kbd8efd3e1fee4c45@mail.gmail.com> In-Reply-To: <937e203f0704231213l374167c8kbd8efd3e1fee4c45@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 19:59:38 -0000 Lubomir Georgiev wrote: > I'd like to thank all the people who replied to the thread I started. Your > help has been invaluable. The reason I didn't immediately respond to Jao is > that I wanted to make sure I wasn't mistaking - I was sure that IPFW + > NAT + > MAC address filtering in a single box was possible because I had seen it > with my own two eyes. I just didn't take the time to see the ruleset > then. I > was going there in a couple of days and was going to shed some light on the > subject but it turns out I don't need to - Patrick and Julian have > backed me > up. > > I am going to try out what you've recommended and post the results. Once > again thanks for all your efforts and Jao please do try not to go all "high > and mighty" over other seeking help when what we really want is one and the > same thing - to help each other, and that I think is the purpose of this > list. > > So, I'll keep you posted. > As I posted, I think you can use keep-state to pass state between layer 2 and layer 3 instances of the firewall. the trick is to remmeber that "check-state" just re-runs the rule that had the orginal keep-state, and that that rule can be almost anything, including a skipto. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 20:57:25 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 05D9C16A400 for ; Mon, 23 Apr 2007 20:57:25 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 1999E13C43E for ; Mon, 23 Apr 2007 20:57:23 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 74605 invoked by uid 0); 23 Apr 2007 17:37:27 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.58.85.51):. Processed in 0.71849 secs); 23 Apr 2007 20:37:27 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.58.85.51) by capeta.freebsdbrasil.com.br with SMTP; 23 Apr 2007 17:37:26 -0300 Message-ID: <462D1770.1040504@freebsdbrasil.com.br> Date: Mon, 23 Apr 2007 17:30:40 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: ipfw@freebsd.org References: <937e203f0704231213l374167c8kbd8efd3e1fee4c45@mail.gmail.com> <462D1033.8030309@elischer.org> In-Reply-To: <462D1033.8030309@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 20:57:25 -0000 > the trick is to remmeber that "check-state" just re-runs the rule that > had the orginal keep-state, and that that rule can be almost anything, > including > a skipto. What if it is a FWD? -- Patrick Tracanelli From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 21:24:41 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0A9816A400 for ; Mon, 23 Apr 2007 21:24:41 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id B2EA613C458 for ; Mon, 23 Apr 2007 21:24:41 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2074813ana for ; Mon, 23 Apr 2007 14:24:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=EReQxWK0gCRM/8OBV5ShmoI+mrEqlYrS7oqztE2CRxGlDPMYMHQGkbXOGoCUkYiZm9UsiMbsucRAmQDkycXnKNtcKNYq01FicBYWZS6STmWlUbElyR/icFX3Mx/gmGtlOwoZckP5OPpsvD2mW1sf1BOUdFRsf9C3Y/ePF90GQtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cZB5yl3RjeZsFadihZW7uLJHKAZNcwzuoIjVgtj4Dz2OFYe8h56eZ5k6xVP7M7oh5JojuE5yHzdq3Feo70lqaJ/v1KrXr4ELjgft/Ex/tXL71cg1F7/LMSZpo9S/xnVW7D3xMqC4OX48/8nI6CkOTauaDnHmRxVKHpm6hDoaa2M= Received: by 10.100.199.12 with SMTP id w12mr1900326anf.1177363480642; Mon, 23 Apr 2007 14:24:40 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Mon, 23 Apr 2007 14:24:40 -0700 (PDT) Message-ID: <937e203f0704231424q28306d67n8c476e113f95441e@mail.gmail.com> Date: Tue, 24 Apr 2007 00:24:40 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 21:24:42 -0000 OK people - here's the deal. I have tried the setup as described by *Patrick Tracanelli at *click but the shitty thing still doesn't want to just let it be! Since I don't want to 00500 468 30071 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 I'm trying to integrate a rule that just skips the natd but still allows normal client -> freebsd box communication. The problem is - I can manipulate layer2 any way I like e.g. use skipto with MAC as described and everything but as soon as I add a rule like this ipfw add 500 skipto 1400 /after the divert natd/ all from any to any not layer2 I lose worldwide connectivity. And if I don't add this rule my whole 192.168.1.0/24 segment in enabled because of the 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 01205 divert 8668 ip from any to me in via fxp0 Can someone please explain this? And just give the word and I'll send a more substantial part of the ruleset and the different strategies /of rulesets :)/ that I've tried. The bottom line - Patrick's setup doesn't work, at least here. I'm certain that I've written the rules they're supposed to be /just change ip ranges, if names etc./ 10x in advance and please do bare with me... -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 23:01:07 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B37116A409 for ; Mon, 23 Apr 2007 23:01:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id 198D813C45E for ; Mon, 23 Apr 2007 23:01:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 23 Apr 2007 15:28:40 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 75024125AF9; Mon, 23 Apr 2007 16:01:06 -0700 (PDT) Message-ID: <462D3ABF.3020506@elischer.org> Date: Mon, 23 Apr 2007 16:01:19 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Patrick Tracanelli References: <937e203f0704231213l374167c8kbd8efd3e1fee4c45@mail.gmail.com> <462D1033.8030309@elischer.org> <462D1770.1040504@freebsdbrasil.com.br> In-Reply-To: <462D1770.1040504@freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 23:01:07 -0000 Patrick Tracanelli wrote: >> the trick is to remmeber that "check-state" just re-runs the rule that >> had the orginal keep-state, and that that rule can be almost anything, >> including >> a skipto. > > What if it is a FWD? true too.. though fwd will do nothing in Layer2 use skipto to simulate what you want to do. From owner-freebsd-ipfw@FreeBSD.ORG Mon Apr 23 23:04:17 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4EC3F16A401 for ; Mon, 23 Apr 2007 23:04:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3D26B13C458 for ; Mon, 23 Apr 2007 23:04:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 23 Apr 2007 15:31:50 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 9D5F7125AE1; Mon, 23 Apr 2007 16:04:16 -0700 (PDT) Message-ID: <462D3B7E.6020006@elischer.org> Date: Mon, 23 Apr 2007 16:04:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704231424q28306d67n8c476e113f95441e@mail.gmail.com> In-Reply-To: <937e203f0704231424q28306d67n8c476e113f95441e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 23:04:17 -0000 ok so I just emailed how I would do this.. Did you not receive it? Lubomir Georgiev wrote: > OK people - here's the deal. I have tried the setup as described by > *Patrick > Tracanelli at *click > > but the shitty thing still doesn't want to just let it be! Since I don't > want to > > 00500 468 30071 deny log logamount 100 ip from any to any MAC any > any layer2 via xl0 > > > I'm trying to integrate a rule that just skips the natd but still allows > normal client -> freebsd box communication. The problem is - I can > manipulate layer2 any way I like e.g. use skipto with MAC as described and > everything but as soon as I add a rule like this > > ipfw add 500 skipto 1400 /after the divert natd/ all from any to any not > layer2 > > I lose worldwide connectivity. And if I don't add this rule my whole > 192.168.1.0/24 segment in enabled because of the > > 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 > 01205 divert 8668 ip from any to me in via fxp0 > > Can someone please explain this? And just give the word and I'll send a > more substantial part of the ruleset and the different strategies /of > rulesets :)/ that I've tried. > The bottom line - Patrick's setup doesn't work, at least here. I'm certain > that I've written the rules they're supposed to be /just change ip ranges, > if names etc./ > > 10x in advance and please do bare with me... > From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 08:11:07 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28BDA16A406 for ; Tue, 24 Apr 2007 08:11:07 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id D9F8613C458 for ; Tue, 24 Apr 2007 08:11:06 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so2245590ana for ; Tue, 24 Apr 2007 01:11:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Po9vDDQL8Sxfp69YzY3gt3BDkCFWygENF8fOvOlewSqaa6LbZxV+RfSRgjwt9J3Z4e0Jx0SDsHW38EWIai3LNuV4hFKl+gVijGxN9lgAxI0Db3zxPUgy9HeOX8QMb4uHyObPWHm93vHhpHgLR6Om1U0lP9+Ge0nEbfe1KXzmDEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JYgsTaWVLYBUaemWcmNdEOFSh3esbmt9JIMGBLfhxRFbBUYTyjR6aSfI4B4QkhcscXJZ0MQxMXhwGyNZyOVuW7LCkbUp6KZE10uva28+Z3JYy5NY3UE2IMEcoc1sKBlkoWf2C/8Kut6ZFy9UOpMXYTq0raTjkpiA0RSO0myI4iw= Received: by 10.100.107.2 with SMTP id f2mr179544anc.1177402266202; Tue, 24 Apr 2007 01:11:06 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Tue, 24 Apr 2007 01:11:06 -0700 (PDT) Message-ID: <937e203f0704240111s303ddd5dt16a6587f06bba471@mail.gmail.com> Date: Tue, 24 Apr 2007 11:11:06 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 08:11:07 -0000 Julian if you mean this Then I did received it but Patrick's setup seemed much easier and he claimed that it worked. This is why I decided to try his first. But now that I've re-examined it I see that it's not that much more complicated. I will try it tonight, but it the mean time if you have time you can have a look at Patrick's ruleset. 10x everyone for your efforts. -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 10:04:12 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 360E516A400; Tue, 24 Apr 2007 10:04:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0F63113C44C; Tue, 24 Apr 2007 10:04:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3OA4B7f002776; Tue, 24 Apr 2007 10:04:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3OA4BXE002772; Tue, 24 Apr 2007 10:04:11 GMT (envelope-from linimon) Date: Tue, 24 Apr 2007 10:04:11 GMT From: Mark Linimon Message-Id: <200704241004.l3OA4BXE002772@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Cc: Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 10:04:12 -0000 Synopsis: [ipfw] ipfw fwd doesn't seem to work Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 24 10:04:06 UTC 2007 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=107305 From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 13:29:59 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BF1016A400 for ; Tue, 24 Apr 2007 13:29:59 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 767E613C45B for ; Tue, 24 Apr 2007 13:29:57 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 38366 invoked by uid 0); 24 Apr 2007 10:36:42 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.58.85.51):. Processed in 1.507077 secs); 24 Apr 2007 13:36:42 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.58.85.51) by capeta.freebsdbrasil.com.br with SMTP; 24 Apr 2007 10:36:41 -0300 Message-ID: <462E0650.50607@freebsdbrasil.com.br> Date: Tue, 24 Apr 2007 10:29:52 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: ipfw@freebsd.org References: <937e203f0704240111s303ddd5dt16a6587f06bba471@mail.gmail.com> In-Reply-To: <937e203f0704240111s303ddd5dt16a6587f06bba471@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 13:29:59 -0000 Lubomir Georgiev escreveu: > Julian if you mean > this > > > Then I did received it but Patrick's setup seemed much easier and he > claimed that it worked. This is why I decided to try his first. > But now that I've re-examined it I see that it's not that much more > complicated. I will try it tonight, but it the mean time if you have time > you can have a look at Patrick's ruleset. > > 10x everyone for your efforts. > The rules I sent you are still working right now ;) Just tested it again. If you could give us the pleasure to see your loaded rules when it does not work, as well as uname -a and sysctl -a | egrep "one_pass\|ether", this would help to. Try to minimize your setup only to the rules you are working in, since if existing, other rules unrelated to layer2 or upper layers may be matching first. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 17:00:46 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52ED116A403 for ; Tue, 24 Apr 2007 17:00:46 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.231]) by mx1.freebsd.org (Postfix) with ESMTP id 05F3813C4AE for ; Tue, 24 Apr 2007 17:00:45 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2201850wxc for ; Tue, 24 Apr 2007 10:00:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Ti/pKLu4L3C8d0LKelEY+535DgwCJsw0fEx2lDnspRtnlS5UVkHkHBkgcz2DAaOjj5vVgKINuVdcmi3NFnFuKK62/84PQmRDWJOXJQE/JQs8vwggkPkuq4Kyz5qXbHw8oZDIJ8ODIHgb+mtnduUvttvMGYbyOmTbN7JH4CQL8d8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=L2Xo6qN/A7G0zAEGdZQiErbgoW6cgM93sdMByyuCVifTW8CKVq3TEVa7G+EkgrTFu3mgcOWsno8nImy7nomXevxSV0bcjZHKnImpefUh1CAXyZVz6hFPsCNClEt3BFbLI+pRb+3VD4Slh/Qeq7eK0JI6UCAl0X4gc37LLRy5qMU= Received: by 10.90.73.7 with SMTP id v7mr2633937aga.1177434044204; Tue, 24 Apr 2007 10:00:44 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Tue, 24 Apr 2007 10:00:44 -0700 (PDT) Message-ID: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> Date: Tue, 24 Apr 2007 20:00:44 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 17:00:46 -0000 OK, so let's get started. Here's my ruleset - 00300 131732 19262748 skipto 1200 ip from any to any { MAC any 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 00500 4723 1941536 skipto 1400 ip from any to any layer2 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 *01250 410160 534966441 queue 1 ip from any to any src-port 80 via fxp0 *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via fxp0 *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via fxp0 01400 12581325 6691776490 allow ip from any to any I've marked the dummynet rules with an asterisk. I'm using Patrick's ruleset - since I'm only allowing internet access for a single machine I've combined his first two rules into one. My internal network is 192.168.1.0/24 and my external iface is fxp0. What I'm experiencing right now as I'm using this set is this - I have internet on this machine I desired /OK/ and on all others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For me, the rules that concern layer2 don't do what they're supposed to and thusly the traffic reaches rule 1203 and 1205 and onward. Interestingly enough traffic does hit the first and second rule. Here's my uname - FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 10:54:10 EEST 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 And my sysctl - bogoqho# sysctl -a | egrep "one_pass\|ether" bogoqho# which as you can see returns nothing using the command you instructed me to use. If there's anything that would help you - just say the word... Let's brainstorm :) -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 18:27:55 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54D1116A409 for ; Tue, 24 Apr 2007 18:27:55 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 3A88D13C4BD for ; Tue, 24 Apr 2007 18:27:52 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 20578 invoked by uid 0); 24 Apr 2007 15:37:23 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(201.58.85.51):. Processed in 5.722783 secs); 24 Apr 2007 18:37:23 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.58.85.51) by capeta.freebsdbrasil.com.br with SMTP; 24 Apr 2007 15:37:17 -0300 Message-ID: <462E4C17.3090109@freebsdbrasil.com.br> Date: Tue, 24 Apr 2007 15:27:35 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Thunderbird 1.5.0.9 (X11/20070131) MIME-Version: 1.0 To: ipfw@freebsd.org References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> In-Reply-To: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 18:27:55 -0000 Lubomir Georgiev escreveu: > OK, so let's get started. Here's my ruleset - > > 00300 131732 19262748 skipto 1200 ip from any to any { MAC any > 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 Good. I have never used it this way and I am not sure if it will work. First, try to use two rules, one per flow. ipfw add 300 skipto 1200 ip from any to any MAC 00:19:d2:36:b8:48 any layer2 ipfw add 301 skipto 1200 ip from any to any MAC any 00:19:d2:36:b8:48 layer2 Later, you try to put both flows all in a single rule. I am not sure if both flows aren't checked together and the rule will match once, since layer2 MAC filter happens as it happens on the wire. > 00500 4723 1941536 skipto 1400 ip from any to any layer2 > 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out via > fxp0 > 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 > *01250 410160 534966441 queue 1 ip from any to any src-port 80 via fxp0 > *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via fxp0 > *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via > fxp0 > 01400 12581325 6691776490 allow ip from any to any Seems almost ok here; please, add "not layer2" to dummynet rules, if not you will have your bw controlled twice. > I've marked the dummynet rules with an asterisk. I'm using Patrick's > ruleset > - since I'm only allowing internet access for a single machine I've > combined > his first two rules into one. My internal network is 192.168.1.0/24 and my > external iface is fxp0. What I'm experiencing right now as I'm using this > set is this - I have internet on this machine I desired /OK/ and on all > others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For > me, > the rules that concern layer2 don't do what they're supposed to and thusly > the traffic reaches rule 1203 and 1205 and onward. Interestingly enough > traffic does hit the first and second rule. Here's my uname - > > FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 10:54:10 > EEST > 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 > > And my sysctl - > > bogoqho# sysctl -a | egrep "one_pass\|ether" > If there's anything that would help you - just say the word... Let's > brainstorm :) > sysctl -a | egrep "one_pass|ether"; my fault, \| is only need for grep, not egrep. Just to be sure net.link.ether.ipfw=1 and net.inet.ip.fw.one_pass=1. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 19:06:25 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55ED516A401 for ; Tue, 24 Apr 2007 19:06:25 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by mx1.freebsd.org (Postfix) with ESMTP id F118313C48A for ; Tue, 24 Apr 2007 19:06:24 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2256287wxc for ; Tue, 24 Apr 2007 12:06:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=CYJ+lw5uHgjYqeSoF4hbYfvWFWukTXvaTiQ3pgrRcZVGD3e+Px/JopU7hXffybqi8kMWpnlWVvbp+4dNo0G9gogoAlIL2TkVIVQtvObQ4DPt3mKyBvFQ06QorJLA24GWy2oIpADPtm3p8ZPCU5IWZxrs75goxQJa68h5cLuSZ74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=n3/JK9UMqzBx2oibV/F3bGI/cxGdDzRI/PXVQs5m7AV2DMUJjk0zwbOWmdI8kK5CBk9LqG85VHrf9q8jOFpjMBObiMA5jUkqUKIfl8r7HsUE6l9DKVOoXo8a9jDDjRSEeRTA2jEwJuDwitiXfuVjobvhEEWTaAW4M2+ZbVylYtI= Received: by 10.90.90.16 with SMTP id n16mr2553467agb.1177441583927; Tue, 24 Apr 2007 12:06:23 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Tue, 24 Apr 2007 12:06:23 -0700 (PDT) Message-ID: <937e203f0704241206k1d2e3bd5s9f21e290a93f0738@mail.gmail.com> Date: Tue, 24 Apr 2007 22:06:23 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 19:06:25 -0000 H1 again. So I did try dividing the first rule up into two. But the problem still remains - all the machines on the 192.168.1.X get diverted through natd regardless of their MAC address. I don't think that the problem lies with the rule that allows the traffic rather with the ones that denies /skips/ natd traffic from the MAC not specified. Please share your thoughts on how your setup work and mine doesn't. P.S. Thanks from the dummynet heads-up! -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 20:00:13 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1C6D16A404 for ; Tue, 24 Apr 2007 20:00:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outC.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id BE46913C45A for ; Tue, 24 Apr 2007 20:00:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 24 Apr 2007 12:27:39 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 92D9E125B31; Tue, 24 Apr 2007 13:00:12 -0700 (PDT) Message-ID: <462E61DB.8090900@elischer.org> Date: Tue, 24 Apr 2007 13:00:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> In-Reply-To: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 20:00:13 -0000 Lubomir Georgiev wrote: > OK, so let's get started. Here's my ruleset - > > 00300 131732 19262748 skipto 1200 ip from any to any { MAC any > 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 for a packet from a client through this machine to the internet: on the first pass (packet in ethernet receive) this skips to 1203,1205 where nothing happens because divert does not work on layer 2. on the second pass (packet entering IP stack) it goes to 500 then 1203 where it doesn'r match (not output for 1203 and not to "me" for 1205. on the third pass (packet leaving IP stack, it goes to 500 then 1203 where it diverts (is outgoing and from 192.x.x.x.), returning just in time for 1205. on the 4th pass it (packet being transmitted on an ethernet) it goes to 500 and thus 1400 because it now has different MAC > 00500 4723 1941536 skipto 1400 ip from any to any layer2 > 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out via > fxp0 > 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 > *01250 410160 534966441 queue 1 ip from any to any src-port 80 via fxp0 > *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via fxp0 > *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via > fxp0 > 01400 12581325 6691776490 allow ip from any to any > > I've marked the dummynet rules with an asterisk. I'm using Patrick's > ruleset > - since I'm only allowing internet access for a single machine I've > combined > his first two rules into one. My internal network is 192.168.1.0/24 and my > external iface is fxp0. What I'm experiencing right now as I'm using this > set is this - I have internet on this machine I desired /OK/ and on all > others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For > me, > the rules that concern layer2 don't do what they're supposed to and thusly > the traffic reaches rule 1203 and 1205 and onward. Interestingly enough > traffic does hit the first and second rule. Here's my uname - > > FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 10:54:10 > EEST > 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 > > And my sysctl - > > bogoqho# sysctl -a | egrep "one_pass\|ether" > bogoqho# > > which as you can see returns nothing using the command you instructed me to > use. > > If there's anything that would help you - just say the word... Let's > brainstorm :) > From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 24 20:15:07 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58D4416A402 for ; Tue, 24 Apr 2007 20:15:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 44E3913C44B for ; Tue, 24 Apr 2007 20:15:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 24 Apr 2007 12:42:33 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7718E125ADD; Tue, 24 Apr 2007 13:15:06 -0700 (PDT) Message-ID: <462E6559.5090109@elischer.org> Date: Tue, 24 Apr 2007 13:15:21 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <462E61DB.8090900@elischer.org> In-Reply-To: <462E61DB.8090900@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 20:15:07 -0000 Julian Elischer wrote: > Lubomir Georgiev wrote: >> OK, so let's get started. Here's my ruleset - >> >> 00300 131732 19262748 skipto 1200 ip from any to any { MAC any >> 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 > > for a packet from a client through this machine to the internet: > on the first pass (packet in ethernet receive) this skips to 1203,1205 > where nothing happens > because divert does not work on layer 2. > > on the second pass (packet entering IP stack) it goes to 500 then 1203 > where it doesn'r match (not output for 1203 and not to "me" for 1205. > on the third pass (packet leaving IP stack, it goes to 500 then 1203 > where it diverts (is outgoing and from 192.x.x.x.), returning just in > time for 1205. > on the 4th pass it (packet being transmitted on an ethernet) it goes to > 500 and thus 1400 because it now has different MAC > What I meant to say is that keeping all this sort of thing in mind all the time makes it hard to debug this, which is why in my example I alwyays send the different passes to separate rules as quickly as possible. >> 00500 4723 1941536 skipto 1400 ip from any to any layer2 >> 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any >> out via >> fxp0 >> 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 >> *01250 410160 534966441 queue 1 ip from any to any src-port 80 via >> fxp0 >> *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via >> fxp0 >> *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via >> fxp0 >> 01400 12581325 6691776490 allow ip from any to any >> >> I've marked the dummynet rules with an asterisk. I'm using Patrick's >> ruleset >> - since I'm only allowing internet access for a single machine I've >> combined >> his first two rules into one. My internal network is 192.168.1.0/24 >> and my >> external iface is fxp0. What I'm experiencing right now as I'm using this >> set is this - I have internet on this machine I desired /OK/ and on all >> others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. >> For me, >> the rules that concern layer2 don't do what they're supposed to and >> thusly >> the traffic reaches rule 1203 and 1205 and onward. Interestingly enough >> traffic does hit the first and second rule. Here's my uname - >> >> FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 >> 10:54:10 >> EEST >> 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 >> >> And my sysctl - >> >> bogoqho# sysctl -a | egrep "one_pass\|ether" >> bogoqho# >> >> which as you can see returns nothing using the command you instructed >> me to >> use. >> >> If there's anything that would help you - just say the word... Let's >> brainstorm :) >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 02:16:25 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C63716A401 for ; Thu, 26 Apr 2007 02:16:25 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 5B8B513C44B for ; Thu, 26 Apr 2007 02:16:21 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 67839 invoked by uid 0); 25 Apr 2007 23:25:53 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 1.824982 secs); 26 Apr 2007 02:25:53 -0000 Received: from unknown (HELO webmail.freebsdbrasil.com.br) (127.0.0.1) by capeta.freebsdbrasil.com.br with SMTP; 25 Apr 2007 23:25:51 -0300 X-Squirrel-UserHash: AxkWAwQS X-Squirrel-FromHash: BUtUVAdKVgE= Message-ID: <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> Date: Wed, 25 Apr 2007 23:25:51 -0300 (BRT) From: eksffa@freebsdbrasil.com.br To: "Lubomir Georgiev" <0shady0recs0@gmail.com> User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 02:16:25 -0000 Ok, I got home (when I have some time) and tried exactly your rule set. The main deal why it worked on my example and not your approach is: - once packets get dropped (denied) on layer2, it will never reach upper layers Thus, NO OTHER action besides deny will avoid the packet getting into ip_input or ip_output. This is crystal-clear on man page, on PACKET FLOW session, and yes, sometimes we just ignore the man pages, this si why I found very strange when I tried your setup and it showed the exact behavior you described (as I didnt expect). What was happening: When you skipped packets on layer2 to somewhere-else, it was ONLY skipped for layer2. Since the packet was still in the network stack, when it hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. In your set, the DIVERT rule matched the packet, and it obviously got diverted. What I did to find it out was: tail -f /var/log/security | grep 1203 Among other "debug funs", using the ruleset present in the body of this message. So, we can be sure that SKIPTO, ALLOW or anything else on Layer2 will NEVER avoid a packet getting filtered on upper layers. So, what we needed? A way to identify packets the we dont want to divert. Which packets we dont want to divert? That ones that, while were flowing on Layer, DID NOT match the ruleset comparing MAC address. We need to point the finger and say: - Hey, you dont have the allowed MAC address, so you wont get diverted Or we could finger: - Hey, you have the allowed MAC, so you will be diverted. Doesnt matter for the system, matters for who is making the rulesets. But how to do this? My approach was tagging the ones that did not have the allowed MAC. Please, read rule 501. Its action is skipto. Why? Because I was lazy and did not want to rewrite it as a "count" rule, because in fact, it does NOTHING to the current ruleset. It skips to somewhere were there is no layer2 rules. So it skips to nowhere and the packet reaches the "allow from any to any" while on layer2 flow. Meaning, it only tags. That is enough. Later, on rule 203 and 205 (selective divert) we only divert the packets that was not tagged (the allowed MAC). Please note that rule 501 is about the internal interface. If we make a mistake and do it for all interfaces, our own (as "our own" pleas read: "the firewall, "me") packets will get tagged 1. This is not what we want. Please keep reading: --------------------------------------------------------------------- # MY TESTING RULESET my_mac="00:17:31:df:bc:ab/48" my_net="10.69.0.0/16" ife="vr0" # external if ifi="xl0" #internal /sbin/sysctl net.link.ether.ipfw=1 ipfw -f f ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC $my_mac any } layer2 // try lubomir_s approach #ipfw add 301 skipto 1200 ip from any to any MAC $my_mac any layer2 // not needed since lubomir_s approach worked fine #ipfw add 500 deny all from any to any layer2 ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 via $ifi // skipto only on L2 and tag for further ch ipfw add 1200 count log all from any to any layer2 // somebody passed here - check the logs ipfw add 1203 divert 8668 log logamount 0 ip from $my_net to any out via $ife not tagged 1 ipfw add 1205 divert 8668 log logamount 0 ip from any to me in via $ife not tagged 1 ipfw add 1240 count log logamount 0 all from any to any diverted not layer2 // lets see whos got here diverted ipfw add 1250 queue 1 ip from any to any src-port 80 via $ife not layer2 ipfw add 1251 queue 1 ip from any to any dst-port 80 via $ife not layer2 ipfw add 1300 queue 2 ip from any to any not src-port 80 via $ife not layer2 ipfw add 1398 count log logamount 0 all from any to any diverted not layer2 // lets see whos got here diverted - since one_pa ipfw add 1399 count log logamount 0 all from any to any not diverted not layer2 // lets see whos got here undiverted ipfw add 1440 allow ip from any to any ipfw queue 1 config weight 10 mask src-ip 0x000000ff pipe 1 ipfw queue 2 config weight 2 mask src-ip 0x000000ff pipe 1 ipfw pipe 1 config bw 4Mbit/s queue 30 --------------------------------------------------------------------- Maybe the better and more clear (to read and understand) approach would be: - tag on laye2 packets with the ALLOWED MAC - on upper layers, only divert packets tagged 1 - be sure no other rule will tag packets with tag 1 - be sure ng_tag wont tag packets with tag 1 Anything else on FreeBSD besides ipfw and netgraph are able to tag packets? Probably not right now. Maybe a geom class one day (hehe, just kidding..). PF tags are not compatible with ipfw/netgraph ones so, no special attention is required. Hope I could help you better this turn. > OK, so let's get started. Here's my ruleset - > > 00300 131732 19262748 skipto 1200 ip from any to any { MAC any > 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 > 00500 4723 1941536 skipto 1400 ip from any to any layer2 > 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out > via > fxp0 > 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 > *01250 410160 534966441 queue 1 ip from any to any src-port 80 via fxp0 > *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via fxp0 > *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via > fxp0 > 01400 12581325 6691776490 allow ip from any to any > > I've marked the dummynet rules with an asterisk. I'm using Patrick's > ruleset > - since I'm only allowing internet access for a single machine I've > combined > his first two rules into one. My internal network is 192.168.1.0/24 and my > external iface is fxp0. What I'm experiencing right now as I'm using this > set is this - I have internet on this machine I desired /OK/ and on all > others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For > me, > the rules that concern layer2 don't do what they're supposed to and thusly > the traffic reaches rule 1203 and 1205 and onward. Interestingly enough > traffic does hit the first and second rule. Here's my uname - > > FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 > 10:54:10 > EEST > 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 > > And my sysctl - > > bogoqho# sysctl -a | egrep "one_pass\|ether" > bogoqho# > > which as you can see returns nothing using the command you instructed me > to > use. > > If there's anything that would help you - just say the word... Let's > brainstorm :) > > -- > mEsS wItH tHe bEsT > dIE liKe tHe rESt > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 05:05:32 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 146BC16A404 for ; Thu, 26 Apr 2007 05:05:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outX.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id F2EBB13C45D for ; Thu, 26 Apr 2007 05:05:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Wed, 25 Apr 2007 21:32:46 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 808CA125AFB; Wed, 25 Apr 2007 22:05:29 -0700 (PDT) Message-ID: <4630332A.6000508@elischer.org> Date: Wed, 25 Apr 2007 22:05:46 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: eksffa@freebsdbrasil.com.br References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org, Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 05:05:32 -0000 eksffa@freebsdbrasil.com.br wrote: > Ok, I got home (when I have some time) and tried exactly your rule set. > The main deal why it worked on my example and not your approach is: > > - once packets get dropped (denied) on layer2, it will never reach upper > layers > > Thus, NO OTHER action besides deny will avoid the packet getting into > ip_input or ip_output. > > This is crystal-clear on man page, on PACKET FLOW session, and yes, > sometimes we just ignore the man pages, this si why I found very strange > when I tried your setup and it showed the exact behavior you described (as > I didnt expect). > > What was happening: > > When you skipped packets on layer2 to somewhere-else, it was ONLY skipped > for layer2. Since the packet was still in the network stack, when it > hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. > In your set, the DIVERT rule matched the packet, and it obviously got > diverted. > I'm adding code to make divert work at layer 2 too. (We have that at work). so be careful. > What I did to find it out was: > > tail -f /var/log/security | grep 1203 > > Among other "debug funs", using the ruleset present in the body of this > message. > > So, we can be sure that SKIPTO, ALLOW or anything else on Layer2 will > NEVER avoid a packet getting filtered on upper layers. > > So, what we needed? A way to identify packets the we dont want to divert. > Which packets we dont want to divert? That ones that, while were flowing > on Layer, DID NOT match the ruleset comparing MAC address. We need to > point the finger and say: > > - Hey, you dont have the allowed MAC address, so you wont get diverted > > Or we could finger: > > - Hey, you have the allowed MAC, so you will be diverted. > > Doesnt matter for the system, matters for who is making the rulesets. But > how to do this? > > My approach was tagging the ones that did not have the allowed MAC. > > Please, read rule 501. > > Its action is skipto. Why? Because I was lazy and did not want to rewrite > it as a "count" rule, because in fact, it does NOTHING to the current > ruleset. It skips to somewhere were there is no layer2 rules. So it skips > to nowhere and the packet reaches the "allow from any to any" while on > layer2 flow. Meaning, it only tags. That is enough. > > Later, on rule 203 and 205 (selective divert) we only divert the packets > that was not tagged (the allowed MAC). Please note that rule 501 is about > the internal interface. If we make a mistake and do it for all interfaces, > our own (as "our own" pleas read: "the firewall, "me") packets will get > tagged 1. This is not what we want. > > Please keep reading: > > --------------------------------------------------------------------- > > # MY TESTING RULESET > > my_mac="00:17:31:df:bc:ab/48" > my_net="10.69.0.0/16" > ife="vr0" # external if > ifi="xl0" #internal > > /sbin/sysctl net.link.ether.ipfw=1 > > ipfw -f f > > ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC > $my_mac any } layer2 // try lubomir_s approach > #ipfw add 301 skipto 1200 ip from any to any MAC $my_mac any layer2 // not > needed since lubomir_s approach worked fine > #ipfw add 500 deny all from any to any layer2 > ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 > via $ifi // skipto only on L2 and tag for further ch > ipfw add 1200 count log all from any to any layer2 // somebody passed here > - check the logs > ipfw add 1203 divert 8668 log logamount 0 ip from $my_net to any out via > $ife not tagged 1 > ipfw add 1205 divert 8668 log logamount 0 ip from any to me in via $ife > not tagged 1 > ipfw add 1240 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted > ipfw add 1250 queue 1 ip from any to any src-port 80 via $ife not layer2 > ipfw add 1251 queue 1 ip from any to any dst-port 80 via $ife not layer2 > ipfw add 1300 queue 2 ip from any to any not src-port 80 via $ife not layer2 > ipfw add 1398 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted - since one_pa > ipfw add 1399 count log logamount 0 all from any to any not diverted not > layer2 // lets see whos got here undiverted > ipfw add 1440 allow ip from any to any > > ipfw queue 1 config weight 10 mask src-ip 0x000000ff pipe 1 > ipfw queue 2 config weight 2 mask src-ip 0x000000ff pipe 1 > ipfw pipe 1 config bw 4Mbit/s queue 30 > > --------------------------------------------------------------------- > > Maybe the better and more clear (to read and understand) approach would be: > > - tag on laye2 packets with the ALLOWED MAC > - on upper layers, only divert packets tagged 1 > - be sure no other rule will tag packets with tag 1 > - be sure ng_tag wont tag packets with tag 1 > > Anything else on FreeBSD besides ipfw and netgraph are able to tag > packets? Probably not right now. Maybe a geom class one day (hehe, just > kidding..). PF tags are not compatible with ipfw/netgraph ones so, no > special attention is required. > > Hope I could help you better this turn. > > > > >> OK, so let's get started. Here's my ruleset - >> >> 00300 131732 19262748 skipto 1200 ip from any to any { MAC any >> 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 >> 00500 4723 1941536 skipto 1400 ip from any to any layer2 >> 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out >> via >> fxp0 >> 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 >> *01250 410160 534966441 queue 1 ip from any to any src-port 80 via fxp0 >> *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via fxp0 >> *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 via >> fxp0 >> 01400 12581325 6691776490 allow ip from any to any >> >> I've marked the dummynet rules with an asterisk. I'm using Patrick's >> ruleset >> - since I'm only allowing internet access for a single machine I've >> combined >> his first two rules into one. My internal network is 192.168.1.0/24 and my >> external iface is fxp0. What I'm experiencing right now as I'm using this >> set is this - I have internet on this machine I desired /OK/ and on all >> others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For >> me, >> the rules that concern layer2 don't do what they're supposed to and thusly >> the traffic reaches rule 1203 and 1205 and onward. Interestingly enough >> traffic does hit the first and second rule. Here's my uname - >> >> FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 >> 10:54:10 >> EEST >> 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 >> >> And my sysctl - >> >> bogoqho# sysctl -a | egrep "one_pass\|ether" >> bogoqho# >> >> which as you can see returns nothing using the command you instructed me >> to >> use. >> >> If there's anything that would help you - just say the word... Let's >> brainstorm :) >> >> -- >> mEsS wItH tHe bEsT >> dIE liKe tHe rESt >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 12:00:35 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9530F16A404 for ; Thu, 26 Apr 2007 12:00:35 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id BEEEF13C484 for ; Thu, 26 Apr 2007 12:00:34 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 10368 invoked by uid 0); 26 Apr 2007 09:10:10 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 8.524101 secs); 26 Apr 2007 12:10:10 -0000 Received: from unknown (HELO webmail.freebsdbrasil.com.br) (127.0.0.1) by capeta.freebsdbrasil.com.br with SMTP; 26 Apr 2007 09:10:02 -0300 X-Squirrel-UserHash: AxkWAwQS X-Squirrel-FromHash: BUtUVAdKVgE= Message-ID: <50005.BUtUVAdKVgE=.1177589402.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <4630332A.6000508@elischer.org> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> <4630332A.6000508@elischer.org> Date: Thu, 26 Apr 2007 09:10:02 -0300 (BRT) From: eksffa@freebsdbrasil.com.br To: "Julian Elischer" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: eksffa@freebsdbrasil.com.br, ipfw@freebsd.org, Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 12:00:35 -0000 > eksffa@freebsdbrasil.com.br wrote: >> Ok, I got home (when I have some time) and tried exactly your rule set. >> The main deal why it worked on my example and not your approach is: >> >> - once packets get dropped (denied) on layer2, it will never reach upper >> layers >> >> Thus, NO OTHER action besides deny will avoid the packet getting into >> ip_input or ip_output. >> >> This is crystal-clear on man page, on PACKET FLOW session, and yes, >> sometimes we just ignore the man pages, this si why I found very strange >> when I tried your setup and it showed the exact behavior you described >> (as >> I didnt expect). >> >> What was happening: >> >> When you skipped packets on layer2 to somewhere-else, it was ONLY >> skipped >> for layer2. Since the packet was still in the network stack, when it >> hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. >> In your set, the DIVERT rule matched the packet, and it obviously got >> diverted. >> > > I'm adding code to make divert work at layer 2 too. > (We have that at work). > so be careful. Good news Elischer. I didnt know it was possible, as I thought L2 flow had no L3 or upper layers information. Any chances it will also work with IPFIREWALL_NAT? From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 18:57:01 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7641B16A403 for ; Thu, 26 Apr 2007 18:57:01 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 22E0013C43E for ; Thu, 26 Apr 2007 18:57:01 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so359672ana for ; Thu, 26 Apr 2007 11:57:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XB3nzNcf4wpG6NmqYkuBs1h6mb0bznCQSjoCo6HGcwUjBEdowvT1a1137mObrmEoetDNEO2iDlhCROwTdrqeoPzzOjSMzMR6MTWopiRjU6RN9EPXJOa/0gndcjk9w9n4Q3+kNK8y+Rfdgu0N08XuiHaJLlCfz2NXMk62feOw3NA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PtrzGmzGa0oW3EneTN6boWWv2wDgSxigEV58US2E8pClAXCWoyFYVGdTkaCbdp1HPtuevnV1uMEIO+ucKyBxdAVHpjsphYOKSLgi9ruIAewlWEQruDNanKdhiOQa227+wnwUnO0llR8ciV1J7dCUNuVxrqRhQW8d4ota7JiKy0c= Received: by 10.100.33.14 with SMTP id g14mr1376603ang.1177613819126; Thu, 26 Apr 2007 11:56:59 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 11:56:58 -0700 (PDT) Message-ID: <937e203f0704261156ia80fad3v80d12d9e09adeb07@mail.gmail.com> Date: Thu, 26 Apr 2007 21:56:58 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> MIME-Version: 1.0 References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 18:57:01 -0000 Thanks for everyone's continuing attempts to help! OK so I tried putting in the ruleset which you provided - and I hit a rock very early in the run. IPFW returns that it doesn't understand the tag option. ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 via $ifi Does this sound familiar? What should I do? On 4/26/07, eksffa@freebsdbrasil.com.br wrote: > > > Ok, I got home (when I have some time) and tried exactly your rule set. > The main deal why it worked on my example and not your approach is: > > - once packets get dropped (denied) on layer2, it will never reach upper > layers > > Thus, NO OTHER action besides deny will avoid the packet getting into > ip_input or ip_output. > > This is crystal-clear on man page, on PACKET FLOW session, and yes, > sometimes we just ignore the man pages, this si why I found very strange > when I tried your setup and it showed the exact behavior you described (as > I didnt expect). > > What was happening: > > When you skipped packets on layer2 to somewhere-else, it was ONLY skipped > for layer2. Since the packet was still in the network stack, when it > hitted upper layers (ip_input or ip_output) the rule MATCHED the packet. > In your set, the DIVERT rule matched the packet, and it obviously got > diverted. > > What I did to find it out was: > > tail -f /var/log/security | grep 1203 > > Among other "debug funs", using the ruleset present in the body of this > message. > > So, we can be sure that SKIPTO, ALLOW or anything else on Layer2 will > NEVER avoid a packet getting filtered on upper layers. > > So, what we needed? A way to identify packets the we dont want to divert. > Which packets we dont want to divert? That ones that, while were flowing > on Layer, DID NOT match the ruleset comparing MAC address. We need to > point the finger and say: > > - Hey, you dont have the allowed MAC address, so you wont get diverted > > Or we could finger: > > - Hey, you have the allowed MAC, so you will be diverted. > > Doesnt matter for the system, matters for who is making the rulesets. But > how to do this? > > My approach was tagging the ones that did not have the allowed MAC. > > Please, read rule 501. > > Its action is skipto. Why? Because I was lazy and did not want to rewrite > it as a "count" rule, because in fact, it does NOTHING to the current > ruleset. It skips to somewhere were there is no layer2 rules. So it skips > to nowhere and the packet reaches the "allow from any to any" while on > layer2 flow. Meaning, it only tags. That is enough. > > Later, on rule 203 and 205 (selective divert) we only divert the packets > that was not tagged (the allowed MAC). Please note that rule 501 is about > the internal interface. If we make a mistake and do it for all interfaces, > our own (as "our own" pleas read: "the firewall, "me") packets will get > tagged 1. This is not what we want. > > Please keep reading: > > --------------------------------------------------------------------- > > # MY TESTING RULESET > > my_mac="00:17:31:df:bc:ab/48" > my_net="10.69.0.0/16" > ife="vr0" # external if > ifi="xl0" #internal > > /sbin/sysctl net.link.ether.ipfw=1 > > ipfw -f f > > ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC > $my_mac any } layer2 // try lubomir_s approach > #ipfw add 301 skipto 1200 ip from any to any MAC $my_mac any layer2 // not > needed since lubomir_s approach worked fine > #ipfw add 500 deny all from any to any layer2 > ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 > via $ifi // skipto only on L2 and tag for further ch > ipfw add 1200 count log all from any to any layer2 // somebody passed here > - check the logs > ipfw add 1203 divert 8668 log logamount 0 ip from $my_net to any out via > $ife not tagged 1 > ipfw add 1205 divert 8668 log logamount 0 ip from any to me in via $ife > not tagged 1 > ipfw add 1240 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted > ipfw add 1250 queue 1 ip from any to any src-port 80 via $ife not layer2 > ipfw add 1251 queue 1 ip from any to any dst-port 80 via $ife not layer2 > ipfw add 1300 queue 2 ip from any to any not src-port 80 via $ife not > layer2 > ipfw add 1398 count log logamount 0 all from any to any diverted not > layer2 // lets see whos got here diverted - since one_pa > ipfw add 1399 count log logamount 0 all from any to any not diverted not > layer2 // lets see whos got here undiverted > ipfw add 1440 allow ip from any to any > > ipfw queue 1 config weight 10 mask src-ip 0x000000ff pipe 1 > ipfw queue 2 config weight 2 mask src-ip 0x000000ff pipe 1 > ipfw pipe 1 config bw 4Mbit/s queue 30 > > --------------------------------------------------------------------- > > Maybe the better and more clear (to read and understand) approach would > be: > > - tag on laye2 packets with the ALLOWED MAC > - on upper layers, only divert packets tagged 1 > - be sure no other rule will tag packets with tag 1 > - be sure ng_tag wont tag packets with tag 1 > > Anything else on FreeBSD besides ipfw and netgraph are able to tag > packets? Probably not right now. Maybe a geom class one day (hehe, just > kidding..). PF tags are not compatible with ipfw/netgraph ones so, no > special attention is required. > > Hope I could help you better this turn. > > > > > > OK, so let's get started. Here's my ruleset - > > > > 00300 131732 19262748 skipto 1200 ip from any to any { MAC any > > 00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2 > > 00500 4723 1941536 skipto 1400 ip from any to any layer2 > > 01203 68479 8449298 divert 8668 ip from 192.168.1.0/24 to any out > > via > > fxp0 > > 01205 71215 16745674 divert 8668 ip from any to me in via fxp0 > > *01250 410160 534966441 queue 1 ip from any to any src-port 80 via > fxp0 > > *01251 143290 14139299 queue 1 ip from any to any dst-port 80 via > fxp0 > > *01300 2711668 1462734503 queue 2 ip from any to any not src-port 80 > via > > fxp0 > > 01400 12581325 6691776490 allow ip from any to any > > > > I've marked the dummynet rules with an asterisk. I'm using Patrick's > > ruleset > > - since I'm only allowing internet access for a single machine I've > > combined > > his first two rules into one. My internal network is 192.168.1.0/24 and > my > > external iface is fxp0. What I'm experiencing right now as I'm using > this > > set is this - I have internet on this machine I desired /OK/ and on all > > others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For > > me, > > the rules that concern layer2 don't do what they're supposed to and > thusly > > the traffic reaches rule 1203 and 1205 and onward. Interestingly enough > > traffic does hit the first and second rule. Here's my uname - > > > > FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr 8 > > 10:54:10 > > EEST > > 2007 tldstyl3@bogoqho.com:/usr/src/sys/i386/compile/bogoqho i386 > > > > And my sysctl - > > > > bogoqho# sysctl -a | egrep "one_pass\|ether" > > bogoqho# > > > > which as you can see returns nothing using the command you instructed me > > to > > use. > > > > If there's anything that would help you - just say the word... Let's > > brainstorm :) > > > > -- > > mEsS wItH tHe bEsT > > dIE liKe tHe rESt > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 19:14:45 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1820A16A402 for ; Thu, 26 Apr 2007 19:14:45 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 248B813C484 for ; Thu, 26 Apr 2007 19:14:43 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 51732 invoked by uid 0); 26 Apr 2007 16:24:22 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 3.580104 secs); 26 Apr 2007 19:24:22 -0000 Received: from unknown (HELO webmail.freebsdbrasil.com.br) (127.0.0.1) by capeta.freebsdbrasil.com.br with SMTP; 26 Apr 2007 16:24:18 -0300 X-Squirrel-UserHash: AxkWAwQS X-Squirrel-FromHash: BUtUVAdKVgE= Message-ID: <52464.BUtUVAdKVgE=.1177615458.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <937e203f0704261156ia80fad3v80d12d9e09adeb07@mail.gmail.com> References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> <937e203f0704261156ia80fad3v80d12d9e09adeb07@mail.gmail.com> Date: Thu, 26 Apr 2007 16:24:18 -0300 (BRT) From: eksffa@freebsdbrasil.com.br To: "Lubomir Georgiev" <0shady0recs0@gmail.com> User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 19:14:45 -0000 > Thanks for everyone's continuing attempts to help! > > OK so I tried putting in the ruleset which you provided - and I hit a > rock > very early in the run. IPFW returns that it doesn't understand the tag > option. > > ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2 > via $ifi > > > Does this sound familiar? What should I do? tag/tagged features were commited somewhere in time between 6.1-STABLE and 6.2-RELEASE, if I remember well. So the first release to have it is 6.2-R; csup to RELENG_6 branch to get the latest -STABLE; From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 19:29:38 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6528116A407 for ; Thu, 26 Apr 2007 19:29:38 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 203BC13C48A for ; Thu, 26 Apr 2007 19:29:38 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so370533ana for ; Thu, 26 Apr 2007 12:29:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=YVQwd0lAjRt0HEBHs6umZwI+o1OJrNMigusEev3nDwMxjhmrYd68lnTENdyuuIj1up7rVOxWWvbU30+r7JCF0fLadFX3Hv58IL6/eLj62Tq1ouVc2ctHoXQp8xjgIjrnKF6ahZi+DgLoapTj5Uj12F3kDhAeQcOnkfRelS9WwBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uuMa8DPRK/QkdtUuFBwy1PqdFznrEgzhODHgWY0x4XDBc+CI0j5ZRLZ5zL42hU1cPWcyx3mEL/1qgq4pn1BOsY2dLlIvKusINy1DHZa+cVr0AZaQFXRCNhso86aEFTJ57jaoi06GHo0B80UM2tguCFczUesfuSrOtlXYcsafkJg= Received: by 10.100.125.5 with SMTP id x5mr1409274anc.1177615775262; Thu, 26 Apr 2007 12:29:35 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 12:29:35 -0700 (PDT) Message-ID: <937e203f0704261229n56f50ce6p7e5874b6046d292e@mail.gmail.com> Date: Thu, 26 Apr 2007 22:29:35 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <52464.BUtUVAdKVgE=.1177615458.squirrel@webmail.freebsdbrasil.com.br> MIME-Version: 1.0 References: <937e203f0704241000k1db56507jba1b0ac89cd3aece@mail.gmail.com> <4178.BUtUVAdKVgE=.1177554351.squirrel@webmail.freebsdbrasil.com.br> <937e203f0704261156ia80fad3v80d12d9e09adeb07@mail.gmail.com> <52464.BUtUVAdKVgE=.1177615458.squirrel@webmail.freebsdbrasil.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 19:29:38 -0000 OK - So I guess we might have a problem... bogoqho# uname -a FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE # I'm currently thinking about using the deny approach you initially recommended. I'll just add an allow rule via the internal iface which will still allow me to ssh in and if everything else is OK then I guess that will be it. I'll check back shortly - in the mean time if you have any suggestions, feel free. On 4/26/07, eksffa@freebsdbrasil.com.br wrote: > > > Thanks for everyone's continuing attempts to help! > > > > OK so I tried putting in the ruleset which you provided - and I hit a > > rock > > very early in the run. IPFW returns that it doesn't understand the tag > > option. > > > > ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any > layer2 > > via $ifi > > > > > > Does this sound familiar? What should I do? > > tag/tagged features were commited somewhere in time between 6.1-STABLE and > 6.2-RELEASE, if I remember well. So the first release to have it is 6.2-R; > > csup to RELENG_6 branch to get the latest -STABLE; > > > > -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 19:42:59 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9223316A400 for ; Thu, 26 Apr 2007 19:42:59 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5133613C4BA for ; Thu, 26 Apr 2007 19:42:59 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so375117ana for ; Thu, 26 Apr 2007 12:42:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Vsrldz3F0rx2ggqCKBDTVH5XgreqTK3+tL2WfeOEVj8FSJ+5Rl9zOiW6NEADxYUh/uMUTjdbsoq6DAjRBGAdCiUoeVDtRibPqSFQCXVDUXlBz8kRzElRhr8wCnyHBeV6obg7uqPuO2U3RJXCf0VL1K6qEhkpgV0w1GuxI9cetnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ID8jmSAzXe85E5Thm0bPQd/PdoSMKOU/mK1B92x/IhVqU+eW9ECj2ZMXvvuB+56O5cEWBCvTZZH0VQ37vr4kkXvpASBQxb9rJDOh7JzVYMBsKQNDK+rlSwsC+RFvUVmSiKlRmgRSpk46CHmHvXdgpiAYW3gIbrHBfX968IptPmU= Received: by 10.100.133.9 with SMTP id g9mr1423267and.1177616577960; Thu, 26 Apr 2007 12:42:57 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 12:42:57 -0700 (PDT) Message-ID: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> Date: Thu, 26 Apr 2007 22:42:57 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 19:42:59 -0000 So I guess shit never stops... As I said I'm currently trying to use the deny rule which you initially supplied to drop the packets which don't get skipped. Here's my current ruleset - 00100 173035 29328940 allow ip from any to any via xl0 00300 292524 50232419 skipto 1200 ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any 00:19:d2:36:b8:48 } layer2 00800 0 0 deny log logamount 100 ip from any to any MAC any any layer2 via xl0 01203 3802723 1050820011 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 01205 2218931 1145072418 divert 8668 ip from any to me in via fxp0 01250 81843 84998617 queue 1 ip from any to any src-port 80 not layer2 via fxp0 01251 64777 18975661 queue 1 ip from any to any dst-port 80 not layer2 via fxp0 01300 4279821 1513380511 queue 2 ip from any to any not src-port 80 not layer2 via fxp0 01500 6137984 2192285003 allow ip from any to any 65535 5 416 deny ip from any to any And the result is the same - everyone on the 192.168.1.0/24 segment gets diverted. And as you can see no traffic hits rule 800. So what's the deal? Any ideas? -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 20:14:45 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1CAA16A403 for ; Thu, 26 Apr 2007 20:14:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outQ.internet-mail-service.net (outQ.internet-mail-service.net [216.240.47.240]) by mx1.freebsd.org (Postfix) with ESMTP id CF70A13C468 for ; Thu, 26 Apr 2007 20:14:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 26 Apr 2007 12:41:55 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 0AB81125B0D; Thu, 26 Apr 2007 13:14:45 -0700 (PDT) Message-ID: <46310846.6020306@elischer.org> Date: Thu, 26 Apr 2007 13:15:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> In-Reply-To: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 20:14:46 -0000 I'm surprised you haven't tried the firewall set I sent you.. I practically wrote the whole thing for you. From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 20:27:48 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BADD16A402 for ; Thu, 26 Apr 2007 20:27:48 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 09F3213C458 for ; Thu, 26 Apr 2007 20:27:47 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so390177ana for ; Thu, 26 Apr 2007 13:27:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=An51pNzCCW9Epo9ay+3H26+BCYZc7e+qY0+vHBFE17BXb/8AmnhUD4XYZs38p+Rg7mfBaU0GG0GgJ3+S7lFUB6PA+gFvF163XbOdQ//SwYVkFUNtB0aNsNdKi2W2zldJ5Kblsn79YBV3nB2Ms4zuyuLQJA2AwGYkr3S0qMEqYhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uh1Ffzuv6Wi8U/ExrVrBnLheHaKXJgTuQjvM81JrWD0BTreyBUKsR966EsuLmAiVX2i+0t5k8ftJYd4kkfXMuFDwgD3tNkq9EsG7iZ99t26QOelePsu4DAe0S5IvMirttHVV3QZGq6Jo3458SWns3OyFrIZwQ3+GvS1/FCsB+ok= Received: by 10.100.37.4 with SMTP id k4mr1438458ank.1177619267390; Thu, 26 Apr 2007 13:27:47 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 13:27:47 -0700 (PDT) Message-ID: <937e203f0704261327y2ebae482x956c22e0de24589b@mail.gmail.com> Date: Thu, 26 Apr 2007 23:27:47 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <46310846.6020306@elischer.org> MIME-Version: 1.0 References: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> <46310846.6020306@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 20:27:48 -0000 The reason I haven't tried it is because I try to keep things as simple as possible. Your set contained *a lot* of rules which, if the ruleset I'm trying to use right now works, would be pointless. Don't take it personally - I'm very grateful for all your help. And again - if you have any ideas on how to get the ruleset I posted a couple of minutes ago working feel free to share them. On 4/26/07, Julian Elischer wrote: > > I'm surprised you haven't tried the firewall set I sent you.. > I practically wrote the whole thing for you. > -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 21:24:19 2007 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C26A916A403 for ; Thu, 26 Apr 2007 21:24:19 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.freebsd.org (Postfix) with SMTP id 5B42213C48C for ; Thu, 26 Apr 2007 21:24:17 +0000 (UTC) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 64009 invoked by uid 0); 26 Apr 2007 18:33:56 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(127.0.0.1):. Processed in 0.86877 secs); 26 Apr 2007 21:33:56 -0000 Received: from unknown (HELO webmail.freebsdbrasil.com.br) (127.0.0.1) by capeta.freebsdbrasil.com.br with SMTP; 26 Apr 2007 18:33:55 -0300 X-Squirrel-UserHash: AxkWAwQS X-Squirrel-FromHash: BUtUVAdKVgE= Message-ID: <2031.BUtUVAdKVgE=.1177623235.squirrel@webmail.freebsdbrasil.com.br> In-Reply-To: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> References: <937e203f0704261242x8c13b9bw3f2bcc56bbe20729@mail.gmail.com> Date: Thu, 26 Apr 2007 18:33:55 -0300 (BRT) From: eksffa@freebsdbrasil.com.br To: "Lubomir Georgiev" <0shady0recs0@gmail.com> User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 21:24:19 -0000 > So I guess shit never stops... As I said I'm currently trying to use the > deny rule which you initially supplied to drop the packets which don't get > skipped. Here's my current ruleset - Now it is a different ruleset, where you want to allow first. You have to have the flow picture in mind: > > 00100 173035 29328940 allow ip from any to any via xl0 You dont want it! since net.link.ether.ipfw is on, the above rule allows everything on layer2, when it reaches ether_demux() via xl0 device. So who will match the next rule? Probably L2 packets flowing via a different interface. What you probably want is to allow only on upper layers, on a later packet inspection when packets finally reach L3 layer and so on: ipfw add 100 allow log logamount 0 ip from any to any via $ifi not layer2 > 00300 292524 50232419 skipto 1200 ip from any to any { MAC > 00:19:d2:36:b8:48 any or MAC any 00:19:d2:36:b8:48 } layer2 Ok here, but if you do "via xl0" you will better avoid further problems, which do not exist right now, but maybe will, in a bigger setup. > 00800 0 0 deny log logamount 100 ip from any to any MAC any > any layer2 via xl0 This one is good, denying via xl0, so you wont drop your own (firewall“s own) L2 packets. > 01203 3802723 1050820011 divert 8668 ip from 192.168.1.0/24 to any out via > fxp0 > 01205 2218931 1145072418 divert 8668 ip from any to me in via fxp0 Untill Elischer“s patches reach the tree, divert will only get processed on ip_input and ip_output, so it is ok if you DO understand that, only after L2 packets get processed, packets will finally get diverted. So, the "skipto" action on rule 300 does not sends that packets to divertion. No. They only say "go try to reach other rules what understand L2 and exist". No further rule you have that satisfies it (in fact you do: the kernel rule, which allows), so, when packets reaches upper layers they will matched by this divert rule. So you will understand the bavior better if you explicitly say "not layer" for divert rules. This rules: ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC $my_mac any } layer2 ipfw add 300 skipto 1500 ip from any to any { MAC any $my_mac or MAC $my_mac any } layer2 Are just the same in your setup. If you use "allow" action instead of "skipto", it is the same too. Do you understand why? Because no further rule can make an action with L2 packets, other than deny or allow. > 01250 81843 84998617 queue 1 ip from any to any src-port 80 not layer2 > via fxp0 > 01251 64777 18975661 queue 1 ip from any to any dst-port 80 not layer2 > via fxp0 > 01300 4279821 1513380511 queue 2 ip from any to any not src-port 80 not > layer2 via fxp0 Good. To be sure we are only working on ip_*() layers. > 01500 6137984 2192285003 allow ip from any to any > 65535 5 416 deny ip from any to any They match L2 and upper layers, because no "layer2" or "not layer2" are used. Once again a working ruleset. Try to use it first, before you change, and keep the logging untill the whole ruleset is completly tested/ready to go production. (logging, makes me remember ipfw0 bpf device logging patch Rizzo has made in the past, why didnt it reach the tree? would be a lot more helpfull than the current kind of logging we have) Here is the ruleset # ipfw show 00100 2973 955186 allow log ip from any to any via xl0 not layer2 00300 2967 953994 allow ip from any to any { MAC any 00:17:31:df:bc:ab or MAC 00:17:31:df:bc:ab any } layer2 // allow everything on L2 00500 52 10586 deny log ip from any to any layer2 via xl0 01203 1422 830971 divert 8668 log ip from 10.69.0.0/16 to any out via vr0 01205 5623 3452838 divert 8668 log ip from any to me in via vr0 01250 39 7832 queue 1 ip from any to any src-port 80 via vr0 not layer2 01251 35 12373 queue 1 ip from any to any dst-port 80 via vr0 not layer2 01300 11126 6030053 queue 2 ip from any to any not src-port 80 via vr0 not layer2 01440 23275 12119240 allow ip from any to any 65535 0 0 allow ip from any to any Only that MAC, flowing via xl0, is getting diverted (because only the packets belonging to that mac can reach L3 and above layers, where things get diverted). So who is matching the deny rule that much? # grep 500 /var/log/security | tail -2 Apr 26 18:16:17 mmach kernel: ipfw: 500 Deny UDP 10.69.69.39:55937 200.167.232.15:53 in via xl0 Apr 26 18:16:17 mmach kernel: ipfw: 500 Deny UDP 10.69.69.39:55937 200.167.232.14:53 in via xl0 RIGHT, certainly someone else, with a different MAC. Just in case: # arp 10.69.69.39 ? (10.69.69.39) at 00:12:17:fb:ee:e7 on xl0 [ethernet] From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 22:54:19 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B4D16A400 for ; Thu, 26 Apr 2007 22:54:19 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 8796C13C46A for ; Thu, 26 Apr 2007 22:54:19 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so430095ana for ; Thu, 26 Apr 2007 15:54:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=NVl1b7v2dgNmeoPawrwuHn4VrOEFIzdsFwqIesETQ2EjYYL+Q5w0Pa2exbJWBszYq5pCnicZOmzMRi/yLWFKWbL1fdvnAFbQwpPvR3LR3zEfIxaapmQgbYSMaNSAl/MV+OSr4sXgYN90L6EEEjILpRcu8Il0UYwsu/u2LMTVhWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bdO1VREjwRej5DCTqAOTwa5YaJG/Esk4vNg81ZxhTQEPkibgOHt/syvLcnVzEovzD4pXKXJbtVs9s7Z8bZRWkRNJ6St3zKHFn6hAFQ+tCERUzrqON/leDpE5F+vU/xuqS9GvZGJDSdrffJEsuH6dxZtL0mWk/dg8w3eubKqUHj8= Received: by 10.100.13.12 with SMTP id 12mr1379618anm.1177628058861; Thu, 26 Apr 2007 15:54:18 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 15:54:18 -0700 (PDT) Message-ID: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> Date: Fri, 27 Apr 2007 01:54:18 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 22:54:19 -0000 Yeah! People, we can congratulate ourselves! We've done it! With a few modifications I've finally found the smallest working MAC filtered NAT system. So here's what I ended up with - I'm including the queues just for the entirety of the ruleset, they have nothing to do with the filtering. 00100 allow ip from any to me not dst-port 8668 via xl0 00101 allow ip from me not 8668 to any via xl0 00300 allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any 00:19:d2:36:b8:48 } layer2 00800 deny log logamount 200 ip from any to any MAC any any layer2 via xl0 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 01205 divert 8668 ip from any to me in via fxp0 01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0 01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0 01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0 01500 allow ip from any to any 65535 deny ip from any to any Just one note - when I first reached this conclusion I had two very strange *blackouts*. As if the 100 and the 101 rule just suddenly stop working and I'm left out of the box e.g. I can't ssh in although the diverting still works - I can ping hosts on the Internet. It seems to be fine now and once I gain some knowledge I'm probably going to expand this ruleset, but for now I've accomplished my goal! I have all of you to thank for that! Even though it wasn't easy /mostly because of my ignorance I'm sure/ you pulled me through. Respect. One last request - if someone happens to have some free time and wishes to donate it to me I'd really like to better understand the whole *layer* thing. I have searched the Internet for answers on this as well as read the ipfw man page, but I can't really understand it. \/ Peace. -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 26 23:01:15 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F78916A401 for ; Thu, 26 Apr 2007 23:01:15 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 201E313C45E for ; Thu, 26 Apr 2007 23:01:15 +0000 (UTC) (envelope-from 0shady0recs0@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so431717ana for ; Thu, 26 Apr 2007 16:01:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=W7wlqyvbpqsCn5St+btEbwvmcx+GQgQM/ol6GbdxVTYApPwlXQjPsEBuOiW8vPWGx1viZU3Ug3tEZsrPX5UhE5UUeLiE6LfqH0ZPkbardFsWHjObDY5h+sSOi5HTS1SkhdI4KTnE2nyTv3ESgWO5pWE2kMzIciHf270qtD59rsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=RVR1lmvMd1M+HUVqRuu6CQXrS+ql53T1UEmHMJzAgeJJncDLbh9R55D96rGqMlcODdCv/34rjziXscb9NYjm3M09TNOXZlqEbG0XJ8SPFZUV4FnG/8AtQQqKPuHnAiutAhMvM2Ve0sNoB8zLVpkd7h3Y7yYcH4rXsfhb74K3AoM= Received: by 10.100.126.2 with SMTP id y2mr737975anc.1177628472532; Thu, 26 Apr 2007 16:01:12 -0700 (PDT) Received: by 10.100.137.17 with HTTP; Thu, 26 Apr 2007 16:01:12 -0700 (PDT) Message-ID: <937e203f0704261601w36ef2428sc35eaa35811262f9@mail.gmail.com> Date: Fri, 27 Apr 2007 02:01:12 +0300 From: "Lubomir Georgiev" <0shady0recs0@gmail.com> To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 23:01:15 -0000 Remember those *blackouts* I wrote about a few minutes ago... I guess they're not over yet - they just keep happening again and again. While everything's going fine - ssh is working, diverting's OK I hear the server's HDD twirking and pop goes my SSH. I can no longer ping it, but I can ping hosts on the internet and open up pages - so natd and the diverts must be working. So it must be something with my rules # 100 and # 101. Any ideas? Anyone ever experienced this? -- mEsS wItH tHe bEsT dIE liKe tHe rESt From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 00:49:50 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4610316A402 for ; Fri, 27 Apr 2007 00:49:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 3322C13C45D for ; Fri, 27 Apr 2007 00:49:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 26 Apr 2007 17:16:57 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 9C551125B0D; Thu, 26 Apr 2007 17:49:48 -0700 (PDT) Message-ID: <463148BD.4050903@elischer.org> Date: Thu, 26 Apr 2007 17:50:05 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Lubomir Georgiev <0shady0recs0@gmail.com> References: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> In-Reply-To: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 00:49:50 -0000 Lubomir Georgiev wrote: > Yeah! People, we can congratulate ourselves! We've done it! With a few > modifications I've finally found the smallest working MAC filtered NAT > system. So here's what I ended up with - I'm including the queues just for > the entirety of the ruleset, they have nothing to do with the filtering. I presume xl0 is the inside interface? here is how you should comment your script. > # The following rules are applied at layer 2 and layer 3. # Allow anything on the inside to talk to me directly if it wants to, # * unless it wants to use port 8668 * (why 8668?) ipfw add 00100 allow ip from any to me not dst-port 8668 via xl0 ipfw add 00101 allow ip from me not 8668 to any via xl0 # # BTW also.. try not use the via keyword.. instead specify exactly what you want # as it hides exactly what you are doing.. use in, out, recv and xmit # (possibly in combination). # Anything that is not to me directly is bound for the outside. # At layer 2 we clobber any that are not 'blessed machines'. ipfw add 00300 "allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any 00:19:d2:36:b8:48 } layer2" ipfw add 00800 "deny log logamount 200 ip from any to any MAC any any layer2 via xl0" # easier written as # ipfw add 800 deny log logamount 200 ip from any to any layer2 # In layer 2 we have no more packets by this point. # In layer 3, only packets that escaped layer 2 alive get diverted ipfw add 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 ipfw add 01205 divert 8668 ip from any to me in via fxp0 # The rest is for conditionning the traffic on the external link > 01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0 > 01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0 > 01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0 > 01500 allow ip from any to any > 65535 deny ip from any to any > > > Just one note - when I first reached this conclusion I had two very > strange *blackouts*. As if the 100 and the 101 rule just suddenly stop > working and I'm left out of the box e.g. I can't ssh in although the > diverting still works - I can ping hosts on the Internet. It seems to be > fine now and once I gain some knowledge I'm probably going to expand this > ruleset, but for now I've accomplished my goal! > > I have all of you to thank for that! Even though it wasn't easy /mostly > because of my ignorance I'm sure/ you pulled me through. > > > Respect. > > > > > One last request - if someone happens to have some free time and wishes to > donate it to me I'd really like to better understand the whole *layer* > thing. I have searched the Internet for answers on this as well as read the > ipfw man page, but I can't really understand it. > > \/ Peace. and here is how I would write it: #!/bin/sh INSIDE="xl0" OUTSIDE="fxp0" BLESSED_MAC="00:19:d2:36:b8:48" OUTSIDE_IP="1.1.1.1" ################################################# # START. ALL PACKETS FROM EVERYWHERE COME HERE. # # A packet being routed comes here 4 times. # ################################################# # first split up the layer 2 packets and layer 3 packets ipfw add 100 skipto 1000 ip from any to any not layer2 ############################################### # ###### START LAYER 2 PROCESSING ############# # this happens as the packet is traversing # the ethernet driver. # A routed packet comes here TWICE. # # In layer 2 just allow packets not traversing the inside # interface as we have no interest in other interfaces. # Now split up incoming and outgoing. ipfw add 110 skipto 120 ip from any to any in ######## PACKETS EXITING ${INSIDE} ############# # packet is exiting the INSIDE ethernet # If it is not from us, and not to a blessed machine, kill it. ipfw add 111 allow ip from any to any not xmit ${INSIDE} #ipfw add 112 allow ip from me to any #ipfw add 113 allow ip from any to any MAC {$BLESSED_MAC} any #ipfw add 114 deny ip from any to any # this is actually pointless as there will be no such traffic, # so in fact just allow everything. ipfw add 112 allow ip from any to any # ######## PACKETS COMING IN THROUGH ${INSIDE} ######## # If it is not to us, and not from a blessed machine, kill it. ipfw add 120 allow ip from any to any not recv ${INSIDE} ipfw add 122 allow ip from any to me ipfw add 124 allow ip from any to any MAC any ${BLESSED_MAC} ipfw add 126 deny log logamount 200 ip from any to any ###################################################### # END OF ALL LAYER 2 PROCESSING # # # # START LAYER 3 PROCESSING # ###################################################### # SPLIT FOR DIRECTION ipfw add 1000 skipto 1500 ip from any to any in # ########## OUTGOING PROCESSING #################### # ignore everything not on "${OUTDSIDE}".. we just don't care. # NAT anything that is not from my outside address. ipfw add 1100 allow ip from any to any not xmit ${OUTSIDE} ipfw add 1110 divert natd ip from not ${OUTSIDE_IP} to any # Rate limit outgoing WEB packets to external servers (Mostly ACKS or POSTs) ipfw add 1120 queue 1 tcp from any to any 80 # Rate limit outgoing WEB packets from INTERNAL servers to outside. # (Assuming you have a server on this box, it would be real data). ipfw add 1120 queue 2 tcp from any 80 to any ipfw add 1130 allow ip from any to any # ########### INCOMING PROCESSING #################### # Ignore anything not on ${OUTSIDE} ipfw add 1500 allow ip from any to any not recv ${OUTSIDE} # lets just be paranoid here. ipfw add 1501 deny ip from any to not ${OUTSIDE_IP} # anything remaining must be nat'd. ipfw add 1510 divert natd ip from any to any # rate limit incoming packets ipfw add 1520 queue 3 tcp from any to any 80 (POSTS and ACKS to your server) ipfw add 1530 queue 4 tcp from any 80 to any (real download data) # Protect your machine with more rules here ipfw add 1550 allow ip from any to any # end of ruleset You may think that this is much more complicated than what you have, but it is MUCH more efficient. And, each rule is used for one and only one thing. You can change a rule in one place and be sure you are not screwing up what is going on somewhere else. it only does processing on each packet that it has to. Your rules are processing every rule for every packet for every interface for each direction.. I have not tested this however and I have a very small doubt about line 101.. it might have to be split to lines From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 01:06:55 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C2E316A401 for ; Fri, 27 Apr 2007 01:06:55 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id C0B7913C44C for ; Fri, 27 Apr 2007 01:06:53 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l3R16tuj074528; Thu, 26 Apr 2007 22:06:55 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Thu, 26 Apr 2007 22:06:43 -0300 User-Agent: KMail/1.9.5 References: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> In-Reply-To: <937e203f0704261554i701849d4j6ecf265490d8252b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704262206.44161.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Lubomir Georgiev <0shady0recs0@gmail.com> Subject: Re: ipfw with nat - allowing by MAC address X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 01:06:55 -0000 On Thursday 26 April 2007 19:54, Lubomir Georgiev wrote: > Yeah! People, we can congratulate ourselves! We've done it! With a few > modifications I've finally found the smallest working MAC filtered NAT > system. So here's what I ended up with - I'm including the queues just for > the entirety of the ruleset, they have nothing to do with the filtering. > not so loud, the honors are coming only at the end and often only after the= =20 end :) when we are dead already :) unfortunatly of course but life is hard : ( :) =20 fun aside, even if you might be able to *block* access using a layer2 rule = any=20 further layer2 rules as skipping in order to jump to another rule on a=20 *router* is not catching anything else as arp, means it is certainly useles= s=20 a natd router is what the name says a router and so the legitmate traffic i= n=20 this scenario is *IP* hitting the GW IP and *NOT* layer2, being then "route= d"=20 to the servers default gateway - so - as long as the mac of the src-ip is i= n=20 the arptable it's traffic goes through whatever nasty fun you do=20 with "layer2" level rules if then exists a natd this traffic might be diverted before leaving the box finally, here is *NO* layer2 traffic (BRIDGED traffic)=20 hence, what you can do is make traffic flow decision based on src/dst IPs o= r=20 ports, nothing else then, even if you (can) block layer2 mac traffic (arp) on a router it does= =20 not touch any legitimate ip traffic, so obviously your arptable will *age=20 out* and suddenly no arp goes through (or to) this box anymore and/or=20 depending on your rules anything is diverted and you lose access to the=20 router ... so as hint, any who likes to play with arp of any kind should no= t=20 only do ipfw flush but also run arp -ad in order to get clean and reliable= =20 results for nasty rules "in real time" :)=20 blocking a mac by blocking arp is one thing controlling traffic flow based on MAC is another in order to control layer2 TRAFFIC flow you need a bridge what follows is a thought because i never needed something like this but th= e=20 only possible setup for *YOUR* wish I can imagin is first making it a bridg= e=20 with no IP on the inner NIC, then associating the GW IP of the internal=20 subnet to the bridge or the external nic if you have then two IPs on the external NIC you divert on IP and not the N= IC *NOW* finally you get bridged traffic (LAYER2) to the gw ip which you CAN=20 control as "skipto proto ip layer2 mac" not from authorized macs to a rule= =20 higher than the divert rule in order not hitting the divert rule. Ok? Resuming, as long you have a router you can not control layer2 traffic, you= =20 only might be able to block certain arp traffic to a certain extense Sooo, at the end this are only my thoughts and opinions, like I said before= =20 router and layer2 with ipfw sounds strange to me so I do not use it today a= nd=20 what I said here might work for one and not for another so please don't hit= =20 me if you get unexpected results :)=20 some comments, no ofense pleease: > 00100 allow ip from any to me not dst-port 8668 via xl0 > 00101 allow ip from me not 8668 to any via xl0 useless > 00300 allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any > 00:19:d2:36:b8:48 } layer2 not sure if you want "or" or even {} > 00800 deny log logamount 200 ip from any to any MAC any any layer2 via xl0 this is your time-bomb which kills access to the router internally, means y= our=20 ruleset might work until the active macs (arptable) are timing out (!on a=20 router) > 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0 > 01205 divert 8668 ip from any to me in via fxp0 ook > 01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0 > 01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0 > 01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0 > 01500 allow ip from any to any > 65535 deny ip from any to any > whatever ... but if your interest or concern is only with tcp:80 you might consider squid wh= ich=20 has some kind of mac acl and you reduce your ipfw-brain-damage on this=20 issue :) Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 05:10:15 2007 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC39816A404 for ; Fri, 27 Apr 2007 05:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 813C813C484 for ; Fri, 27 Apr 2007 05:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3R5A9FH009161 for ; Fri, 27 Apr 2007 05:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3R5A9ut009152; Fri, 27 Apr 2007 05:10:09 GMT (envelope-from gnats) Date: Fri, 27 Apr 2007 05:10:09 GMT Message-Id: <200704270510.l3R5A9ut009152@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 05:10:15 -0000 The following reply was made to PR kern/107305; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-followup@FreeBSD.org, hidden@4you.lt Cc: Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work Date: Fri, 27 Apr 2007 08:46:09 +0400 Hi, IP Address 212.59.27.254 is local for your system. In 6.0-RELEASE you should add IPFIREWALL_FORWARD_EXTENDED kernel option in your kernel config. http://www.freebsd.org/releases/6.0R/relnotes-i386.html "The ipfw(8) ipfw fwd rule now supports the full packet destination manipulation when the kernel option options IPFIREWALL_FORWARD_EXTENDED is specified in addition to options IPFIRWALL_FORWARD. This kernel option disables all restrictions to ensure proper behavior for locally generated packets and allows redirection of packets destined to locally configured IP addresses. Note that ipfw(8) rules have to be carefully crafted to make sure that things like PMTU discovery do not break." -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 05:51:22 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29B1416A401 for ; Fri, 27 Apr 2007 05:51:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outZ.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 163EE13C44B for ; Fri, 27 Apr 2007 05:51:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Thu, 26 Apr 2007 22:18:28 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id EDA4F125ADB; Thu, 26 Apr 2007 22:51:20 -0700 (PDT) Message-ID: <46318F6B.5000308@elischer.org> Date: Thu, 26 Apr 2007 22:51:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <200704270510.l3R5A9ut009152@freefall.freebsd.org> In-Reply-To: <200704270510.l3R5A9ut009152@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 05:51:22 -0000 Andrey V. Elsukov wrote: > The following reply was made to PR kern/107305; it has been noted by GNATS. > This was fixed in 6.[later] (6.2 at least, maybe 6.1) (The need for the EXTENDED option) > > -- > WBR, Andrey V. Elsukov > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 06:46:27 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BB6B16A401 for ; Fri, 27 Apr 2007 06:46:27 +0000 (UTC) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.freebsd.org (Postfix) with ESMTP id D239A13C45D for ; Fri, 27 Apr 2007 06:46:26 +0000 (UTC) (envelope-from jan@melen.org) Received: from localhost ([IPv6:2001:14b8:400:f00::ffff]) (authenticated bits=0) by foxgw.melen.org (8.13.8/8.13.8) with ESMTP id l3R6SObq064285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Apr 2007 09:28:35 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-ipfw@freebsd.org Date: Fri, 27 Apr 2007 09:28:33 +0300 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704270928.34327.jan@melen.org> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on foxgw.melen.org X-Virus-Status: Clean Subject: ipfw2: IPv6 and new protocols X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 06:46:27 -0000 Hi, Is there a specific reason why the upper-layer protocols are limited in IPv6 with ipfw2? The problem that I see is that if there is a firewall in the net that uses ipfw2 you can't introduce any new protocols to IPv6 without updating all firewalls of the net? When using new next header numbers ipfw2 complains "Unknown Extension Header(253)" although the there is a rule that allows the protocol to pass through, but the packet is dropped already before the rules are checked. I noticed from the code that for example all MIPv6 extension headers and SCTP are missing from the code and probably many others as well. Regards, Jan From owner-freebsd-ipfw@FreeBSD.ORG Fri Apr 27 08:15:07 2007 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E119A16A400; Fri, 27 Apr 2007 08:15:07 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp3.yandex.ru (smtp3.yandex.ru [213.180.200.14]) by mx1.freebsd.org (Postfix) with ESMTP id E400B13C458; Fri, 27 Apr 2007 08:15:06 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([77.72.136.145]:24539 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3590433AbXD0IOu (ORCPT + 1 other); Fri, 27 Apr 2007 12:14:50 +0400 X-Comment: RFC 2476 MSA function at smtp3.yandex.ru logged sender identity as: bu7cher Message-ID: <4631B11A.8050405@yandex.ru> Date: Fri, 27 Apr 2007 12:15:22 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Julian Elischer References: <200704270510.l3R5A9ut009152@freefall.freebsd.org> <46318F6B.5000308@elischer.org> In-Reply-To: <46318F6B.5000308@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, Mark Linimon Subject: Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 08:15:08 -0000 Julian Elischer wrote: > This was fixed in 6.[later] (6.2 at least, maybe 6.1) > (The need for the EXTENDED option) Yes, i know. I think this PR can be closed. -- WBR, Andrey V. Elsukov