Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-pf Digest, Vol 276, Issue 1

2 views

Skip to first unread message

freebsd-p...@freebsd.org

unread,

Feb 5, 2010, 7:47:14 PM2/5/10

to freeb...@freebsd.org

Send freebsd-pf mailing list submissions to
freeb...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
or, via email, send a message with subject or body 'help' to
freebsd-p...@freebsd.org

You can reach the person managing the list at
freebsd-...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-pf digest..."

Today's Topics:

1. Re: Ruleset causing problems with N95? (britneyfreek)
2. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
3. Re: conf/142961: [pf] No way to adjust pidfile in pflogd
(lin...@FreeBSD.org)
4. Important: Please verify your email address (Bebo Service)
5. Important: Please verify your email address (Bebo Service)
6. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
7. Routing router-originating traffic via route-to rules (Stefan)
8. Re: Routing router-originating traffic via route-to rules
(Frank Behrens)
9. Re: Routing router-originating traffic via route-to rules (Stefan)
10. allow-opts on a nat pass rule (Ludovico Cavedon)
11. Absensi Sidik Jari 1,3Jt ---> LIFETIME WARANTY
(Absensi Sidik Jari 1, 3Jt ---> LIFETIME WARANTY)
12. Possible bug: pf ignores "reply-to" in block-rules
(Kristian Kr?mmer Nielsen)
13. Re: Possible bug: pf ignores "reply-to" in block-rules
(Peter Maxwell)
14. Re: Possible bug: pf ignores "reply-to" in block-rules
(Kristian Kr?mmer Nielsen)
15. Re: Possible bug: pf ignores "reply-to" in block-rules
(Kristian Kr?mmer Nielsen)
16. Current problem reports assigned to freeb...@FreeBSD.org
(FreeBSD bugmaster)
17. pf and enc0 (Vadym Chepkov)
18. Re: pf and enc0 (Vadym Chepkov)
19. toute-to on lo0 not working? (Stefan)
20. [patch] outgoing states are not killed by authpf (olli hauer)
21. Re: bin/143504: [patch] outgoing states are not killed by
authpf(8) (lin...@FreeBSD.org)
22. Re: toute-to on lo0 not working? (jhell)
23. Re: toute-to on lo0 not working? (Stefan)
24. Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
(lin...@FreeBSD.org)
25. How make the route-to working ? (Albert Shih)
26. Re: How make the route-to working ? (Stefan)
27. Re: How make the route-to working ? (David DeSimone)
28. using pf to NAT with only one NIC (Maurice)
29. Re: using pf to NAT with only one NIC (Peter Maxwell)

----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Jan 2010 16:26:58 +0100
From: britneyfreek <britne...@googlemail.com>
Subject: Re: Ruleset causing problems with N95?
To: Adam Egan <adam...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<2ad621ab1001150726l291...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

sorry for the long delay - happy new year btw ;)

i still believe your problem has to do with mss/mtu sizes. i am no
professional on that topic but i assume there are options to fix this
- either in your pppoe client (that your router is supposed to use) or
in your firewall config.

i remember myself trying to optimize mss/mtu sizes once. i also used a
value of 1452 and this raised problems like not completely loading web
pages. i'm from germany, all german websites loaded completely but
some from overseas stopped loading html/css/images occasionally.

that said, you might try removing the max-mss option? or try a value of 1492?

what (pppoe-)client software connects you to the internet?

- b

2009/12/22 Adam Egan <adam...@gmail.com>:
> I'm not using a PPPoE client that I'm aware of...
>
> Phone -> Wireless -> router
>
> My router has UPnP enabled which I thought might have helped but it doesn't :(
>
> I just googled for 'n95 fix-mss' and all I got was this mail on
> kernaltrap.. was surprised it appeared so fast!
>
> I added some tcp reassemble stuff to my ruleset to help with Vista/7's
> window scaling/autotuninglevel - could this be affecting it?
>
> Adam
>
> 2009/12/22 no name <britne...@googlemail.com>:
>> hello, i had a similar problem on my iphone/podtouch... try to enable
>> any fix-mss option in your pppoe client (i suppose u use one)
>>
>> cheers, b
>>
>> Am 21.12.2009 um 22:42 schrieb Adam Egan <adam...@gmail.com>:
>>
>>> I've recently been making an effort to get my N95 to work on my LAN. I
>>> have reason to believe that for some reason, my router/ruleset is
>>> inhibiting the phone's access.
>>>
>>> My ruleset is here: http://pastebin.com/m56dadcd8
>>>
>>> basically, i cannot download files on my phone, or use the sync,
>>> spotify, gmail or similar applications. When I try to download a file,
>>> it seems to be listed as 2KB, and then nothing happens. I'm not sure
>>> what on earth could be causing it, and I have tried playing around
>>> with the rules.
>>>
>>> taking the router out of the equasian does fix the matter.
>>>
>>> add
>>> _______________________________________________
>>> freeb...@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>>> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>>
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>

------------------------------

Message: 2
Date: Mon, 18 Jan 2010 11:07:02 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201001181107....@freefall.freebsd.org>

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl
o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697 pf [pf] pf behaviour changes - must be documented
o kern/137982 pf [pf] when pf can hit state limits, random IP failures
o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948 pf [pf] [gre] pf not natting gre protocol
o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732 pf [pf] max-src-conn issue
o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent
f kern/132176 pf [pf] pf stalls connection when using route-to [regress
o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920 pf [pf] ipv6 and synproxy don't play well together
o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439 pf [pf] deadlock in pf
f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression]
o kern/127121 pf [pf] [patch] pf incorrect log priority
o kern/127042 pf [pf] [patch] pf recursion panic if interface group is
o kern/125467 pf [pf] pf keep state bug while handling sessions between
s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge
o kern/122773 pf [pf] pf doesn't log uid or pid when configured to
o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf
o kern/121704 pf [pf] PF mangles loopback packets
o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr
o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355 pf [pf] [patch] pfctl(8) help message options order false
o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c
o kern/114095 pf [carp] carp+pf delay with high state limit
o kern/111220 pf [pf] repeatable hangs while manipulating pf tables
s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283 pf pfsync fails to sucessfully transfer some sessions
o kern/103281 pf pfsync reports bulk update failures
o kern/93825 pf [pf] pf reply-to doesn't work
o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s
o kern/92949 pf [pf] PF + ALTQ problems with latency
o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency

39 problems total.

------------------------------

Message: 3
Date: Tue, 19 Jan 2010 14:43:00 GMT
From: lin...@FreeBSD.org
Subject: Re: conf/142961: [pf] No way to adjust pidfile in pflogd
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201001191443....@freefall.freebsd.org>

Old Synopsis: No way to adjust pidfile in pflogd
New Synopsis: [pf] No way to adjust pidfile in pflogd

Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jan 19 14:42:38 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=142961

------------------------------

Message: 4
Date: Wed, 20 Jan 2010 11:11:13 +0000 (UTC)
From: Bebo Service <ser...@noreply.bebo.com>
Subject: Important: Please verify your email address
To: Lilio Tavake <freeb...@freebsd.org>
Message-ID: <393910067.17372126398...@bebo.com>
Content-Type: text/plain; charset=utf-8

Lilio,

IMPORTANT: Please click on the link below to verify this email address:
http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/verify/10315080041a885482616

If you did not enter your email address and are not a member of Bebo please click below:
http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/notmine/10315080041a885482616

......................................................................
Please do not reply directly to this email.
Questions? Contact us - http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/contactus

Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.

------------------------------

Message: 5
Date: Wed, 20 Jan 2010 11:11:13 +0000 (UTC)
From: Bebo Service <ser...@noreply.bebo.com>
Subject: Important: Please verify your email address
To: Lilio Tavake <freeb...@freebsd.org>
Message-ID: <1703922137.19550126398...@bebo.com>
Content-Type: text/plain; charset=utf-8

Lilio,

IMPORTANT: Please click on the link below to verify this email address:
http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/verify/10315080041a885482616

If you did not enter your email address and are not a member of Bebo please click below:
http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/notmine/10315080041a885482616

......................................................................
Please do not reply directly to this email.
Questions? Contact us - http://www.bebo.com/T/2.laCbZVRbRPOZ4aALXFkKmg/contactus

Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA.

------------------------------

Message: 6
Date: Mon, 25 Jan 2010 11:07:06 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201001251107....@freefall.freebsd.org>

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

S Tracker Resp. Description
--------------------------------------------------------------------------------
o conf/142961 pf [pf] No way to adjust pidfile in pflogd
o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl
o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty
o kern/140697 pf [pf] pf behaviour changes - must be documented
o kern/137982 pf [pf] when pf can hit state limits, random IP failures
o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg
o kern/135948 pf [pf] [gre] pf not natting gre protocol
o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel
o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w
o kern/133732 pf [pf] max-src-conn issue
o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent
f kern/132176 pf [pf] pf stalls connection when using route-to [regress
o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st
o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co
o kern/127920 pf [pf] ipv6 and synproxy don't play well together
o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w
o kern/127439 pf [pf] deadlock in pf
f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression]
o kern/127121 pf [pf] [patch] pf incorrect log priority
o kern/127042 pf [pf] [patch] pf recursion panic if interface group is
o kern/125467 pf [pf] pf keep state bug while handling sessions between
s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented
o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge
o kern/122773 pf [pf] pf doesn't log uid or pid when configured to
o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf
o kern/121704 pf [pf] PF mangles loopback packets
o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr
o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c
o bin/118355 pf [pf] [patch] pfctl(8) help message options order false
o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c
o kern/114095 pf [carp] carp+pf delay with high state limit
o kern/111220 pf [pf] repeatable hangs while manipulating pf tables
s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5.
o kern/103283 pf pfsync fails to sucessfully transfer some sessions
o kern/103281 pf pfsync reports bulk update failures
o kern/93825 pf [pf] pf reply-to doesn't work
o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s
o kern/92949 pf [pf] PF + ALTQ problems with latency
o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf.
o kern/82271 pf [pf] cbq scheduler cause bad latency

40 problems total.

------------------------------

Message: 7
Date: Tue, 26 Jan 2010 12:02:20 +0200
From: Stefan <stefanf...@gmail.com>
Subject: Routing router-originating traffic via route-to rules
To: freeb...@freebsd.org
Message-ID: <4B5EBDAC...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I've googled this one to bits and pulled out quite a lot of hair:
Basically I need a way to route, using "route-to" filter rules, the
traffic originating on the freebsd router itself. The problem with doing
this is that pf only sees the packets on their way out, when an outbound
interface has already been chosen by the routing tables. Therefore pf's
route-to rules have no effect on locally originating traffic.

I've tried several approaches to get around this. They all center around
looping back the router's traffic before routing it out, so that pf can
see the packets as inbound once before they get routed properly. This
means changing the default route to one of the tried loopbacks, then
using pf filter rules coming in on the chosen loopback of bridge. I've
tried this using bridged netgraph and tap interfaces, and using loopback
interfaces. I've also tried it using a loopback interface with an IP on
a unique subnet, to keep the packets from routing through lo0.

Please, I'm desperate to get this working! Has anyone done this type of
thing successfully or does anyone have any idea how to get it working?
I'd think that this would be a fairly common requirement, if not for
routing then at least for filtering outbound (router) traffic...

------------------------------

Message: 8
Date: Tue, 26 Jan 2010 12:07:16 +0100
From: "Frank Behrens" <fr...@jasmin.behrens.de>
Subject: Re: Routing router-originating traffic via route-to rules
To: freeb...@freebsd.org
Message-ID: <201001261107....@post.behrens.de>
Content-Type: text/plain; charset=US-ASCII

Stefan <stefanf...@gmail.com> wrote on 26 Jan 2010 12:02:
> I've googled this one to bits and pulled out quite a lot of hair:
> Basically I need a way to route, using "route-to" filter rules, the
> traffic originating on the freebsd router itself. The problem with doing
> this is that pf only sees the packets on their way out, when an outbound
> interface has already been chosen by the routing tables. Therefore pf's
> route-to rules have no effect on locally originating traffic.

I had always some trouble with this approach. I used rules like

nat inet from any to xxx port yyy tag IF2 -> $myaddr
pass out quick on $iface from $myaddr to any tag IF2
pass out quick on $defaultinterface route-to ($iface $hisaddr) tagged IF2

Now I'm using an associated FIB (setfib(8)) for desired processes and it works very well
without any trouble. Routed traffic is also assigned to the fib with pf's "rtable" option.

Frank

--
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.

------------------------------

Message: 9
Date: Tue, 26 Jan 2010 13:27:22 +0200
From: Stefan <stefanf...@gmail.com>
Subject: Re: Routing router-originating traffic via route-to rules
To: freeb...@freebsd.org
Message-ID: <4B5ED19A...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Thanks, I'll keep that approach in mind. Unfortunately that still relies
on routing tables to perform outbound routing, unless I misunderstand?

The problem is that my routing setup is a little complex for the routing
tables, so I really need to route using pf. My setup looks roughly like
this:
* Almost 600 IP ranges get routed over one set of links, with load
balancing to get better ADSL line usage (local routes)
* VPN traffic goes out over an IPSec tunnel
* Other traffic gets routed via another ADSL link (International traffic)

Most of the above can be done using routing tables (except for the load
balancing?), but having to maintain both the pf rules and the routing
tables is undesirable, especially since my setup changes quite often.

This is what I've managed so far:
1 - The default route (set to IP of lo1) loops traffic back to the
router. Without pf routing, that traffic loops until the TTL is
exceeded, as expected. But when I try to route it on the incoming
traffic of the loopback (pass in on lo1 route-to ...), the packets go
nowhere and I can't figure out what's happening with tcpdump.
2 - The above setup results in the packets looping back via lo0, despite
setting the default route to lo1. This happens even when I configure lo1
on a unique subnet. When I configure the route via the loopback IP
first, and then use "route change" to set the interface to lo1
explicitly on the default route, I get messages along the line of
"address family not supported by the protocol family" whenever packets
are routed to the loopback. This happens even after I make sure to
assign both IPv4 and IPv6 addresses to lo1.

From the above it seems I'm very close to a solution, but it just
doesn't want to work...

On 2010-01-26 13:07, Frank Behrens wrote:
> Stefan<stefanf...@gmail.com> wrote on 26 Jan 2010 12:02:
>
>> I've googled this one to bits and pulled out quite a lot of hair:
>> Basically I need a way to route, using "route-to" filter rules, the
>> traffic originating on the freebsd router itself. The problem with doing
>> this is that pf only sees the packets on their way out, when an outbound
>> interface has already been chosen by the routing tables. Therefore pf's
>> route-to rules have no effect on locally originating traffic.
>>
> I had always some trouble with this approach. I used rules like
>
> nat inet from any to xxx port yyy tag IF2 -> $myaddr
> pass out quick on $iface from $myaddr to any tag IF2
> pass out quick on $defaultinterface route-to ($iface $hisaddr) tagged IF2
>
>
> Now I'm using an associated FIB (setfib(8)) for desired processes and it works very well
> without any trouble. Routed traffic is also assigned to the fib with pf's "rtable" option.
>
> Frank
>
>

------------------------------

Message: 10
Date: Wed, 27 Jan 2010 00:01:01 +0000 (UTC)
From: Ludovico Cavedon <ludovico...@gmail.com>
Subject: allow-opts on a nat pass rule
To: freeb...@freebsd.org
Message-ID: <loom.2010012...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii

Hi all,
I have a freebsd firewall with a configuration like this:

#### BEGIN ###
ext_if4="em0" # public interface
int_if="em1" # private interface, to be source NATted

nat pass log (to pflog2) on $ext_if4 inet from $int_if:network to ! ($ext_if4)
-> ($ext_if4)
block drop log # logs to pflog0
pass quick log (to pflog1) on $int_if allow-opts # private network
pass out from ($ext_if4) allow-opts modulate state # public network
#### END ###

If I send a packet to a public host from an private one, everything is fine, the
packet arrives at the destination, and is logged by pflog1 and pflog2.

If this packet, however, contains an IP option (e.g. NOP), the packets if
blocked by the firewall, and logged by pflog1 and pflog0.

Looks like it is not possible to specify "allow-opts" for the "nat pass" rules.
Is there any way I can get packets with IP options to be NATted?

Thank you in advance,
Ludovico

------------------------------

Message: 11
Date: Fri, 29 Jan 2010 11:10:43 +0700
From: "Absensi Sidik Jari 1, 3Jt ---> LIFETIME WARANTY"
<rose_fi...@yahoo.co.id>
Subject: Absensi Sidik Jari 1,3Jt ---> LIFETIME WARANTY
To: freeb...@freebsd.org
Message-ID: <28126442798416907214@IONBARU-3>
Content-Type: text/plain

Absensi Sidik Jari Cuma 1,3 JT

GARANSI SPARE PART 3 TAHUN
GARANSI SERVICE LIFETIME
Gratis Ongkos Kirim untuk wilayah Jakarta

Hub : Rosnita ( 021- 93229090)
Id YM : rose_fingerspot

------------------------------

Message: 12
Date: Sat, 30 Jan 2010 05:11:17 +0100
From: Kristian Kr?mmer Nielsen <jk...@jkkn.dk>
Subject: Possible bug: pf ignores "reply-to" in block-rules
To: freeb...@freebsd.org
Message-ID: <4B63B165...@jkkn.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hey,

I am experiencing an issue using reply-to on block rules.

I am a "nice" firewall administrator and always uses "block return"
rules, thereby pf sends nice reset packets back to clients if they
attempt to connect to a port that pf is setup to block.

My setup is using a gif0 tunnel to tunnel specific traffic from another
public IP-address to the server. Since it is important that packages are
then to be routed back the same way and not using the default-route, I
use "pass in reply-to gif0"-rules and this worked perfectly for all
incoming traffic.

But, on my "block return in gif0 reply-to gif0" - pf seem to simply
ignore the reply-to parameter and instead decides to send the packs back
using the default route.

I see the packages go out on the wrong interface, in my case my ethernet
interface (em0), that is the default route for the server.

Could someone check to see if pf respects "reply-to" when sending reset
packages (block return)?

Or if that is not the case explain to me what "reply-to" is suppose to
do on "block"-rules?

Best regards,
Kristian Kr�mmer Nielsen,
Odense, Denmark

------------------------------

Message: 13
Date: Sat, 30 Jan 2010 05:31:28 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: Possible bug: pf ignores "reply-to" in block-rules
To: Kristian Kr?mmer Nielsen <jk...@jkkn.dk>, freeb...@freebsd.org
Message-ID:
<7731938b1001292131l15...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Kristian,

This is quite late, so if my reply doesn't make and sense please
ignore it ;-) Also, I'm not really answering your question, just
suggesting an alternative.

Instead of using reply-to, can the upstream device that is sending
packets to the gif0 tunnel - or even pf if it works in this scenario -
NAT the source address of incoming packets to a rfc1918 subnet? That
way all you need to do is add an appropriate entry to your routing
table and you don't have to worry about trying to route to overlapping
address space.

Although I haven't tried it, FreeBSD 8.0 can use multiple routing
tables but have no idea whether this would help.

I know it comes down to personal taste but can I ask why you are using
"block return" in the first place? There are a few possible
disadvantages: if the packet source address is spoofed your packet
filter will be sending tcp rst/icmp packets back to the wrong IP, and
you are also doubling the resources taken for dealing with what is
essentially spurious traffic. It's not a big deal normally but if
someone attempts some form of denial of service, it won't help either.

Regards,

Peter

On 30 January 2010 04:11, Kristian Kr�mmer Nielsen <jk...@jkkn.dk> wrote:
> Hey,
>
> I am experiencing an issue using reply-to on block rules.
>
> I am a "nice" firewall administrator and always uses "block return" rules,
> thereby pf sends nice reset packets back to clients if they attempt to
> connect to a port that pf is setup to block.
>
> My setup is using a gif0 tunnel to tunnel specific traffic from another
> public IP-address to the server. Since it is important that packages are
> then to be routed back the same way and not using the default-route, I use
> "pass in reply-to gif0"-rules and this worked perfectly for all incoming
> traffic.
>
> But, on my "block return in gif0 reply-to gif0" - pf seem to simply ignore
> the reply-to parameter and instead decides to send the packs back using the
> default route.
>
> I see the packages go out on the wrong interface, in my case my ethernet
> interface (em0), that is the default route for the server.
>
> Could someone check to see if pf respects "reply-to" when sending reset
> packages (block return)?
>
> Or if that is not the case explain to me what "reply-to" is suppose to do on
> "block"-rules?
>
> Best regards,
> Kristian Kr�mmer Nielsen,
> Odense, Denmark
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>

------------------------------

Message: 14
Date: Sat, 30 Jan 2010 06:41:47 +0100
From: Kristian Kr?mmer Nielsen <jk...@jkkn.dk>
Subject: Re: Possible bug: pf ignores "reply-to" in block-rules
To: Peter Maxwell <pe...@allicient.co.uk>
Cc: freeb...@freebsd.org
Message-ID: <4B63C69B...@jkkn.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Peter,

Thanks for the reply. Unfortunately I do not see NAT'ing as an
alternative in this case.

The main reason for that is that the traffic that I am forwarding is
smtp-traffic and I need sendmail to see the actual source IP address to
validate the source mail-server and not a NAT-IP. So best case is that
the server sees the right public address even it has a different return
route.

I also considered the multiple routing tables for FreeBSD, which might
also help me do this special routing scenario but I found it much more
complex than using the nice "pass in reply-to"-feature of pf which works
perfect for my allowed traffic. Also I would have to have multiple
sendmail-instances running which for each routing scenario - I don't by
using pf.

The reason for using "block return" is I think it makes debugging much
easier than dropping packages. To avoid spoofing I of course have
"antispoof"-rules that have higher priority and these are of course set
to drop packets and not return them.

So again, why is "block return reply-to" not sending the reset-packages
back to the specified interface?

/Kristian

On 30-01-2010 06:31, Peter Maxwell wrote:
> Hi Kristian,
>
> This is quite late, so if my reply doesn't make and sense please
> ignore it ;-) Also, I'm not really answering your question, just
> suggesting an alternative.
>
> Instead of using reply-to, can the upstream device that is sending
> packets to the gif0 tunnel - or even pf if it works in this scenario -
> NAT the source address of incoming packets to a rfc1918 subnet? That
> way all you need to do is add an appropriate entry to your routing
> table and you don't have to worry about trying to route to overlapping
> address space.
>
> Although I haven't tried it, FreeBSD 8.0 can use multiple routing
> tables but have no idea whether this would help.
>
> I know it comes down to personal taste but can I ask why you are using
> "block return" in the first place? There are a few possible
> disadvantages: if the packet source address is spoofed your packet
> filter will be sending tcp rst/icmp packets back to the wrong IP, and
> you are also doubling the resources taken for dealing with what is
> essentially spurious traffic. It's not a big deal normally but if
> someone attempts some form of denial of service, it won't help either.
>
> Regards,
>
> Peter
>
>
>
>
>
> On 30 January 2010 04:11, Kristian Kr�mmer Nielsen<jk...@jkkn.dk> wrote:
>
>> Hey,
>>
>> I am experiencing an issue using reply-to on block rules.
>>
>> I am a "nice" firewall administrator and always uses "block return" rules,
>> thereby pf sends nice reset packets back to clients if they attempt to
>> connect to a port that pf is setup to block.
>>
>> My setup is using a gif0 tunnel to tunnel specific traffic from another
>> public IP-address to the server. Since it is important that packages are
>> then to be routed back the same way and not using the default-route, I use
>> "pass in reply-to gif0"-rules and this worked perfectly for all incoming
>> traffic.
>>
>> But, on my "block return in gif0 reply-to gif0" - pf seem to simply ignore
>> the reply-to parameter and instead decides to send the packs back using the
>> default route.
>>
>> I see the packages go out on the wrong interface, in my case my ethernet
>> interface (em0), that is the default route for the server.
>>
>> Could someone check to see if pf respects "reply-to" when sending reset
>> packages (block return)?
>>
>> Or if that is not the case explain to me what "reply-to" is suppose to do on
>> "block"-rules?
>>
>> Best regards,
>> Kristian Kr�mmer Nielsen,
>> Odense, Denmark
>> _______________________________________________
>> freeb...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>>
>>

------------------------------

Message: 15
Date: Sun, 31 Jan 2010 01:49:58 +0100
From: Kristian Kr?mmer Nielsen <jk...@jkkn.dk>
Subject: Re: Possible bug: pf ignores "reply-to" in block-rules
To: freeb...@freebsd.org
Message-ID: <4B64D3B6...@jkkn.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hey again,

I have been looking through the source-code of pf and wondering if this
might be an issue with all packets that pf initiates and sends by it self?

As far as I can tell pf uses the method "pf_send_tcp" to initiase
packages from itself, like the reset-packet used by "block return"-rules.

But routes like route-to/dub-to/reply-to seem only to be handle in
"pf_route" which is only used for the packets pf processes.

THE ISSUE:
The problem is "pf_send_tcp" does not really call "pf_route" at any time
so I guess routing is not handled at all for these packets?
Would we dear to call pf_route() somewhere in pf_send_tcp() to fix this
- could someone give me a hint on this?

I also discovered an unrelated issue, in the sourcecode of pf_route() I
see a comment saying "Copied from FreeBSD 5.1-CURRENT ip_output" - this
code seem quiet old, e.x. there are no support for IPSEC in the copied
code. Both outside the FreeBSD special case and ip_output in CURRENT
does additional checks for IPSEC - I am not using IPSEC myself, but we
might also have trouble routing IPSEC traffic until this copied code is
updated?

Hope someone can hint me on pf_send_tcp/pf_route.

Thanks,
Kristian

On 30-01-2010 05:11, Kristian Kr�mmer Nielsen wrote:
> Hey,
>
> I am experiencing an issue using reply-to on block rules.
>
> I am a "nice" firewall administrator and always uses "block return"
> rules, thereby pf sends nice reset packets back to clients if they
> attempt to connect to a port that pf is setup to block.
>
> My setup is using a gif0 tunnel to tunnel specific traffic from
> another public IP-address to the server. Since it is important that
> packages are then to be routed back the same way and not using the
> default-route, I use "pass in reply-to gif0"-rules and this worked
> perfectly for all incoming traffic.
>
> But, on my "block return in gif0 reply-to gif0" - pf seem to simply
> ignore the reply-to parameter and instead decides to send the packs
> back using the default route.
>
> I see the packages go out on the wrong interface, in my case my
> ethernet interface (em0), that is the default route for the server.
>
> Could someone check to see if pf respects "reply-to" when sending
> reset packages (block return)?
>
> Or if that is not the case explain to me what "reply-to" is suppose to
> do on "block"-rules?
>
> Best regards,
> Kristian Kr�mmer Nielsen,
> Odense, Denmark
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"

------------------------------

Message: 16
Date: Mon, 1 Feb 2010 11:07:02 GMT
From: FreeBSD bugmaster <bugm...@FreeBSD.org>
Subject: Current problem reports assigned to freeb...@FreeBSD.org
To: freeb...@FreeBSD.org
Message-ID: <201002011107....@freefall.freebsd.org>

Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.

40 problems total.

------------------------------

Message: 17
Date: Tue, 2 Feb 2010 04:22:04 -0500
From: Vadym Chepkov <vche...@gmail.com>
Subject: pf and enc0
To: freeb...@FreeBSD.org
Message-ID: <AF293434-875D-47DD...@gmail.com>
Content-Type: text/plain; charset=us-ascii

Hi,

I have stumbled on a problem and I am not sure if it's a bug or a feature.

very simple block rules

# pfctl -sr | grep block
block return in log on bge0 all
block return in quick on bge0 from <martians> to any
block return out quick on bge0 from any to <martians>

bge0 is my WAN interface, I have FreeBSD 6.4

I enabled IPSEC in my kernel

options FAST_IPSEC
options IPSEC_NAT_T
device enc
device crypto
device cryptodev

and all works fine until I do 'ifconfig enc0 up'
after that traffic coming through ipsec tunnel is getting rejected and I can see it's recorded in pflog0

I am not sure why and how to prevent this from happening.

Thanks,
Vadym Chepkov

------------------------------

Message: 18
Date: Tue, 2 Feb 2010 04:51:04 -0500
From: Vadym Chepkov <vche...@gmail.com>
Subject: Re: pf and enc0
To: dug <d...@xgs-france.com>
Cc: freeb...@FreeBSD.org
Message-ID: <3EFB5293-0CCA-41F7...@gmail.com>
Content-Type: text/plain; charset=iso-8859-1

But I don't "block" it, I thought default is to "pass" ?

On Feb 2, 2010, at 4:48 AM, dug wrote:

> Hello,
>
> You have to allow this traffic on your enc0 interface.
> It's not a bug.
>
>
> Le 2 f�vr. 2010 � 10:22, Vadym Chepkov a �crit :
>
>> Hi,
>>
>> I have stumbled on a problem and I am not sure if it's a bug or a feature.
>>
>> very simple block rules
>>
>> # pfctl -sr | grep block
>> block return in log on bge0 all
>> block return in quick on bge0 from <martians> to any
>> block return out quick on bge0 from any to <martians>
>>
>> bge0 is my WAN interface, I have FreeBSD 6.4
>>
>> I enabled IPSEC in my kernel
>>
>> options FAST_IPSEC
>> options IPSEC_NAT_T
>> device enc
>> device crypto
>> device cryptodev
>>
>> and all works fine until I do 'ifconfig enc0 up'
>> after that traffic coming through ipsec tunnel is getting rejected and I can see it's recorded in pflog0
>>
>> I am not sure why and how to prevent this from happening.
>>
>> Thanks,
>> Vadym Chepkov_______________________________________________
>> freeb...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
>> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>>
>

------------------------------

Message: 19
Date: Tue, 02 Feb 2010 19:54:29 +0200
From: Stefan <stefanf...@gmail.com>
Subject: toute-to on lo0 not working?
To: freeb...@freebsd.org
Message-ID: <4B6866D5...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

In my quest to route traffic originating on the freebsd machine, I've
managed to loop back outbound traffic via lo0 so that I can try and
route it inbound on lo0 (pf can't apply route-to logic to outbound
traffic; by then it's to late to try and route it over a different
interface).

The loopback works when I switch off skip on lo0, and pass all lo0
traffic, so that traffic is definitely processed by pf. I also know the
looping works, because when I try to ping an outside IP, I get a
response that the TTL has been exceeded, and traceroute shows repeating
entries of 127.0.0.1 (in other words, the packets jost loop back through
the pf box repeatedly till their TTL is exceeded).

The problem is the moment I change my rule to try and route the inbound
traffic on lo0, the packets just seem to go nowhere. They are not routed
correctly and I can't tell what happens to them. In the ruleset below,
enabling the second rule results in the packets looping back to the pf
box repeatedly, and the first rule results in the packets
"disappearing". The only difference is the route-to statement, which
works for all traffic originating elsewhere on the lan.

#pass in quick on lo0 route-to (adsl-int0 196.210.140.129) from any to !
$IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label zSA_Local tag zSA_Local
#pass in quick on lo0 from any to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT
label zSA_Local tag zSA_Local
pass out quick all $KEEPSTATE tagged zSA_Local
pass quick on lo0

Please help! I really need to route traffic originating on the pf box
via pf, and not via rtables!

------------------------------

Message: 20
Date: Tue, 2 Feb 2010 23:20:44 +0100 (CET)
From: olli hauer <oha...@gmx.de>
Subject: [patch] outgoing states are not killed by authpf
To: FreeBSD-gn...@freebsd.org
Cc: freeb...@freebsd.org
Message-ID: <201002022220...@u18-124.dsl.vianetworks.de>

>Submitter-Id: current-users
>Originator: olli hauer <oha...@gmx.de>
>Organization:
>Confidential: no
>Synopsis: [patch] outgoing states are not killed by authpf
>Severity: non-critical
>Priority: low
>Category: kern
>Class: sw-bug
>Release: FreeBSD 7.2-RELEASE-p6 i386
>Environment: System: FreeBSD 7.2-RELEASE-p6

>Description:
Outgoing states are not killed by authpf, since psk.psk_af is
overridden in authpf_kill_states with the No. of killed states
for incoming ipsrc.

Patch is only needed until code from OpenBSD >=200811 is merged
to FreeBSD since OpenBSD_4.4+ returns No. off killed states in
psk.psk_killed.

The OpenBSD change is not documented in man page at the moment,
but you can find it out in the source (net/pfvar.h).
I found it this way by hacking snortsam.

Please see additional my PR 140369 to correct the man page for FreeBSD

>From man (4) pf:

DIOCKILLSTATES struct pfioc_state_kill *psk
Remove matching entries from the state table. This ioctl returns
the number of killed states in psk_af.

Here are the structs from FreeBSD and OpenBSD

FreeBSD:
struct pfioc_state_kill {
/* XXX returns the number of states killed in psk_af */
sa_family_t psk_af;
int psk_proto;
struct pf_rule_addr psk_src;
struct pf_rule_addr psk_dst;
char psk_ifname[IFNAMSIZ];
};

OpenBSD_4.4/4.5:
struct pfioc_state_kill {
struct pf_state_cmp psk_pfcmp;
sa_family_t psk_af;
int psk_proto;
struct pf_rule_addr psk_src;
struct pf_rule_addr psk_dst;
char psk_ifname[IFNAMSIZ];
char psk_label[PF_RULE_LABEL_SIZE];
u_int psk_killed;
};

>How-To-Repeat:
>Fix:
The following patch safes the sa_family into a variable 'saf' and restores
psk.psk_af to this family after killing states from incoming ipsrc.

--- patch_authpf.c begins here ---
Index: base/stable/7/contrib/pf/authpf/authpf.c
===================================================================
--- base/stable/7/contrib/pf/authpf/authpf.c (revision 203401)
+++ base/stable/7/contrib/pf/authpf/authpf.c (working copy)
@@ -788,14 +788,15 @@ authpf_kill_states(void)
{
struct pfioc_state_kill psk;
struct pf_addr target;
+ sa_family_t saf; /* safe AF_INET family */

memset(&psk, 0, sizeof(psk));
memset(&target, 0, sizeof(target));

if (inet_pton(AF_INET, ipsrc, &target.v4) == 1)
- psk.psk_af = AF_INET;
+ psk.psk_af = saf = AF_INET;
else if (inet_pton(AF_INET6, ipsrc, &target.v6) == 1)
- psk.psk_af = AF_INET6;
+ psk.psk_af = saf = AF_INET6;
else {
syslog(LOG_ERR, "inet_pton(%s) failed", ipsrc);
return;
@@ -809,6 +810,9 @@ authpf_kill_states(void)
if (ioctl(dev, DIOCKILLSTATES, &psk))
syslog(LOG_ERR, "DIOCKILLSTATES failed (%m)");

+ /* restore AF_INET, since it contains now the Nr. of killed states */
+ psk.psk_af = saf;
+
/* Kill all states to ipsrc */
memset(&psk.psk_src, 0, sizeof(psk.psk_src));
memcpy(&psk.psk_dst.addr.v.a.addr, &target,
--- patch_authpf.c ends here ---

------------------------------

Message: 21
Date: Tue, 2 Feb 2010 22:42:33 GMT
From: lin...@FreeBSD.org
Subject: Re: bin/143504: [patch] outgoing states are not killed by
authpf(8)
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201002022242....@freefall.freebsd.org>

Old Synopsis: [patch] outgoing states are not killed by authpf
New Synopsis: [patch] outgoing states are not killed by authpf(8)

Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Feb 2 22:41:40 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=143504

------------------------------

Message: 22
Date: Tue, 2 Feb 2010 21:59:34 -0500
From: jhell <jh...@DataIX.net>
Subject: Re: toute-to on lo0 not working?
To: Stefan <stefanf...@gmail.com>
Cc: freeb...@freebsd.org
Message-ID:
<alpine.BSF.2.00.1...@qvfongpu.qngnvk.ybpny>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 2 Feb 2010 12:54, stefanferreira@ wrote:
> Hi
>
> In my quest to route traffic originating on the freebsd machine, I've managed
> to loop back outbound traffic via lo0 so that I can try and route it inbound
> on lo0 (pf can't apply route-to logic to outbound traffic; by then it's to
> late to try and route it over a different interface).
>
> The loopback works when I switch off skip on lo0, and pass all lo0 traffic,
> so that traffic is definitely processed by pf. I also know the looping works,
> because when I try to ping an outside IP, I get a response that the TTL has
> been exceeded, and traceroute shows repeating entries of 127.0.0.1 (in other
> words, the packets jost loop back through the pf box repeatedly till their
> TTL is exceeded).
>
> The problem is the moment I change my rule to try and route the inbound
> traffic on lo0, the packets just seem to go nowhere. They are not routed
> correctly and I can't tell what happens to them. In the ruleset below,
> enabling the second rule results in the packets looping back to the pf box
> repeatedly, and the first rule results in the packets "disappearing". The
> only difference is the route-to statement, which works for all traffic
> originating elsewhere on the lan.
>
> #pass in quick on lo0 route-to (adsl-int0 196.210.140.129) from any to !
> $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label zSA_Local tag zSA_Local
> #pass in quick on lo0 from any to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label
> zSA_Local tag zSA_Local
> pass out quick all $KEEPSTATE tagged zSA_Local
> pass quick on lo0
>
> Please help! I really need to route traffic originating on the pf box via pf,
> and not via rtables!
>

Have you tried implementing "binat" and possibly making use of rdr while
using some tables to hold your addresses and subnets ?

# BINAT
# Translate outgoing packets' source address (any protocol).
# Translate incoming packets' destination address to an internal machine
# (bidirectional).
binat on $ext_if from 10.1.2.150 to any -> $ext_ifA

you could change that to:
binat on $ext_if from <binathosts> to any -> $ext_ifA

Looping traffic that is originating internally back around to a loopback
interface is not going to solve this, and it will cause you a lot more
frustration.

Best of luck.

jhell

------------------------------

Message: 23
Date: Wed, 03 Feb 2010 22:17:40 +0200
From: Stefan <stefanf...@gmail.com>
Subject: Re: toute-to on lo0 not working?
To: jhell <jh...@DataIX.net>
Cc: freeb...@freebsd.org
Message-ID: <4B69D9E4...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Wouldn't the same problem then apply? By the time pf sees packets
originating on the pf box itself, they are already outbound on a
specific interface, and cannot be routed to the correct interface.

I think I'll have to use rtables after all. That just means I'm limited
to destination routing only and not full policy routing.

It also seems that the "loopback" option (two bridged tap interfaces)
can't work because the packets always bypass the actual full stack of
the interfaces. The only weird thing with that is that when I set my
default route to tap0 and block inbound on tap1 (bridged to tap0), the
pings are stopped, but when I pass the traffic it does loop until TTL
expires. This suggests that pf does indeed see those packets, yet when I
try to apply routes to them inbound on tap1, they go nowhere... I'm
convinced that I just don't know the interactions between pf nat, pf
route-to and rtables well enough to crack this one...

On 2010-02-03 04:59, jhell wrote:
>
> On Tue, 2 Feb 2010 12:54, stefanferreira@ wrote:
>> Hi
>>
>> In my quest to route traffic originating on the freebsd machine, I've
>> managed to loop back outbound traffic via lo0 so that I can try and
>> route it inbound on lo0 (pf can't apply route-to logic to outbound
>> traffic; by then it's to late to try and route it over a different
>> interface).
>>
>> The loopback works when I switch off skip on lo0, and pass all lo0
>> traffic, so that traffic is definitely processed by pf. I also know
>> the looping works, because when I try to ping an outside IP, I get a
>> response that the TTL has been exceeded, and traceroute shows
>> repeating entries of 127.0.0.1 (in other words, the packets jost loop
>> back through the pf box repeatedly till their TTL is exceeded).
>>
>> The problem is the moment I change my rule to try and route the
>> inbound traffic on lo0, the packets just seem to go nowhere. They are
>> not routed correctly and I can't tell what happens to them. In the
>> ruleset below, enabling the second rule results in the packets
>> looping back to the pf box repeatedly, and the first rule results in
>> the packets "disappearing". The only difference is the route-to
>> statement, which works for all traffic originating elsewhere on the lan.
>>
>> #pass in quick on lo0 route-to (adsl-int0 196.210.140.129) from any
>> to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label zSA_Local tag zSA_Local
>> #pass in quick on lo0 from any to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT
>> label zSA_Local tag zSA_Local
>> pass out quick all $KEEPSTATE tagged zSA_Local
>> pass quick on lo0
>>
>> Please help! I really need to route traffic originating on the pf box
>> via pf, and not via rtables!
>>
>
> Have you tried implementing "binat" and possibly making use of rdr
> while using some tables to hold your addresses and subnets ?
>
> # BINAT
> # Translate outgoing packets' source address (any protocol).
> # Translate incoming packets' destination address to an internal machine
> # (bidirectional).
> binat on $ext_if from 10.1.2.150 to any -> $ext_ifA
>
> you could change that to:
> binat on $ext_if from <binathosts> to any -> $ext_ifA
>
> Looping traffic that is originating internally back around to a
> loopback interface is not going to solve this, and it will cause you a
> lot more frustration.
>
> Best of luck.
>

------------------------------

Message: 24
Date: Thu, 4 Feb 2010 10:21:40 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/143543: [pf] [panic] PF route-to causes kernel panic
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201002041021....@freefall.freebsd.org>

Old Synopsis: PF route-to causes kernel panic
New Synopsis: [pf] [panic] PF route-to causes kernel panic

Responsible-Changed-From-To: freebsd-bugs->freebsd-pf
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Feb 4 10:21:23 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=143543

------------------------------

Message: 25
Date: Fri, 5 Feb 2010 13:32:54 +0100
From: Albert Shih <Alber...@obspm.fr>
Subject: How make the route-to working ?
To: freebs...@freebsd.org, freeb...@freebsd.org
Message-ID: <20100205123...@obspm.fr>
Content-Type: text/plain; charset=iso-8859-1

Hi all,

I've a problem with route-to.

I've a server with 2 interfaces, and I'm running jail on this server. Each
interface have is own public IP address.

eth0 -- IP0 eth1 -- IP1

and I've a default route (for example in IP0 subnet).

So if the jail is in the IP0 subnet no problem everything work.

Now if I put a jail in IP1 subnet, and some client try to connect to this
jail the answer come out through eth0 because of the default route (suppose
the client is not on my subnet).

I don't want that. I want the answer come out through the eth1

I'm trying to use pf to do that and put in my pf.conf something like

pass in all
pass out all
pass out on eth0 route-to {(eth0 IP0_Gateway)} from <IP0> to ! IP0_subnet
pass out on eth1 route-to {(eth1 IP1_Gateway)} from <IP1> to ! IP1_subnet

but it's not working, if I run a tcpdump on the host I can see the
incoming packet come in from eth1 and the outgoing come out on eth0.

And if I try do remove default route the outgoing packet don't come out....

Any help ?

Regards.

--
Albert SHIH
SIO batiment 15
Observatoire de Paris Meudon
5 Place Jules Janssen
92195 Meudon Cedex
T�l�phone : 01 45 07 76 26/06 86 69 95 71
Heure local/Local time:
Ven 5 f�v 2010 13:25:02 CET

------------------------------

Message: 26
Date: Fri, 05 Feb 2010 14:56:31 +0200
From: Stefan <stefanf...@gmail.com>
Subject: Re: How make the route-to working ?
To: freeb...@freebsd.org
Message-ID: <4B6C157F...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Pf doesn't seem to be able to route packets on the outbound interface.
Therefore you have to always put the route-to statements on "pass in
on..." rules.

I don't have experience setting up pf in a server environment, but I
believe that rdr rules are normally used for what you are trying to
achieve...

Regards,
Stefan

On 2010-02-05 14:32, Albert Shih wrote:
> Hi all,
>
> I've a problem with route-to.
>
> I've a server with 2 interfaces, and I'm running jail on this server. Each
> interface have is own public IP address.
>
> eth0 -- IP0 eth1 -- IP1
>
> and I've a default route (for example in IP0 subnet).
>
> So if the jail is in the IP0 subnet no problem everything work.
>
> Now if I put a jail in IP1 subnet, and some client try to connect to this
> jail the answer come out through eth0 because of the default route (suppose
> the client is not on my subnet).
>
> I don't want that. I want the answer come out through the eth1
>
> I'm trying to use pf to do that and put in my pf.conf something like
>
> pass in all
> pass out all
> pass out on eth0 route-to {(eth0 IP0_Gateway)} from<IP0> to ! IP0_subnet
> pass out on eth1 route-to {(eth1 IP1_Gateway)} from<IP1> to ! IP1_subnet
>
> but it's not working, if I run a tcpdump on the host I can see the
> incoming packet come in from eth1 and the outgoing come out on eth0.
>
> And if I try do remove default route the outgoing packet don't come out....
>
> Any help ?
>
> Regards.
>
>
>

------------------------------

Message: 27
Date: Fri, 5 Feb 2010 13:26:04 -0600
From: "David DeSimone" <f...@verio.net>
Subject: Re: How make the route-to working ?
To: <freeb...@freebsd.org>
Message-ID: <2010020519...@verio.net>
Content-Type: text/plain; charset="us-ascii"

Stefan <stefanf...@gmail.com> wrote:
>
> Pf doesn't seem to be able to route packets on the outbound interface.
> Therefore you have to always put the route-to statements on "pass in
> on..." rules.

What you'd want to use for received traffic is "pass in" rules that make
use of "reply-to".

--
David DeSimone == Network Admin == f...@verio.net
"I don't like spinach, and I'm glad I don't, because if I
liked it I'd eat it, and I just hate it." -- Clarence Darrow

This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you.

------------------------------

Message: 28
Date: Fri, 5 Feb 2010 15:53:14 -0700
From: Maurice <mau...@gmail.com>
Subject: using pf to NAT with only one NIC
To: freeb...@freebsd.org
Message-ID:
<d3e0b6a01002051453o377...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have been looking for a couple days now, with no luck, for some direction
as to whether I can successfully configure my freebsd to NAT with only one
NIC. This is because I am setting up my system to jail my webserver, and I
don't think I can get it to work without NATting it. If you have an
alternate solution that would be great too. This is what my pf.conf looks
like right now:

# $FreeBSD: src/share/examples/pf/pf.conf,v 1.1.2.1.6.1 2009/04/15
03:14:26 kensmith Exp $
# $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
#
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
# in /etc/sysctl.conf if packets are to be forwarded between interfaces.

block in all
block out all

ext_if="fxp0"
#int_if="int0"
all_if="{fxp0, lo0}"

#Internal network subnet
int_net="10.0.0.0/32"

#name and IP of webserver
APACHE="10.0.0.1"

#table <spamd-white> persist

set skip on lo

scrub in

#nat-anchor "ftp-proxy/*"
#rdr-anchor "ftp-proxy/*"
#nat on $ext_if from !($ext_if) -> ($ext_if:0)
#rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
#no rdr on $ext_if proto tcp from <spamd-white> to any port smtp
#rdr pass on $ext_if proto tcp from any to any port smtp \
# -> 127.0.0.1 port spamd

#anchor "ftp-proxy/*"
#pass out

#pass quick on $int_if no state
#antispoof quick for { lo $int_if }
block in quick from urpf-failed

pass in on $ext_if proto tcp to ($ext_if) port ssh synproxy state
rdr on $all_if proto tcp from any to fxp0 port 80 -> $APACHE port 80
nat on $ext_if from $APACHE to any -> fxp0

#pass in log on $ext_if proto tcp to ($ext_if) port smtp
#pass out log on $ext_if proto tcp from ($ext_if) to port smtp

That doesn't seem to be doing the trick, since I can't ping and DNS won't
resolve anything from within the jail (APACHE). I am going off some examples
I found that would seem to suggest it is possible with only one NIC, but I
can't seem to get it to work. Any help/advice would be greatly appreciated.

thanks,

Maurice

------------------------------

Message: 29
Date: Sat, 6 Feb 2010 00:47:01 +0000
From: Peter Maxwell <pe...@allicient.co.uk>
Subject: Re: using pf to NAT with only one NIC
To: Maurice <mau...@gmail.com>, freeb...@freebsd.org
Message-ID:
<7731938b1002051647y78...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi Maurice,

Yes, you can do it without much difficulty and I've got my server
setup in that manner: there's about twenty separate jails that can
access the internet via specific NAT rules and incoming services
handled via RDR rules. Note: you won't be able to ping from a jail,
unless you want to allow your jailed processes to create raw sockets
(you don't) :-)

There's probably many ways it can be done, but what I did was something like:

i) create a second loopback interface, lo1 (c.f. cloned interfaces)
and assign appropriate alias netblocks for your jails on that
interface;

ii) create your pf.conf, set skip on lo0 but not the external or lo1 interface;

iii) I'd set "set state-policy if-bound" so you know what's going on;

iv) don't use the antispoof keyword, it will make a mess in this situation;

v) setting up bind to handle local dns resolution is a good idea -
point your jails towards this and you'll need to add in an appropriate
rule(s) later on;

vi) setup outgoing nat rules, e.g.

nat on $ext_if inet from $int_ip_smtp to ! $int_lo1_if:network port
smtp -> $ext_ip

vii) setup incoming services, e.g.

rdr on $ext_if proto tcp from any to $ext_ip port smtp -> $int_ip_mail port smtp

viii) put in pass rules to allow nat out and rdr in; remember NAT is
done first, so your outgoing packets ALL have source IP of the
external IP now and not the jail IP

pass out log on $ext_if proto tcp from $ext_ip to any port smtp flags
S/SA modulate state
pass in log on $ext_if proto tcp from any to $int_ip_mail port smtp
flags S/SA modulate state

ix) allow jail implicit access to itself

pass log on $int_lo1_if proto { udp, tcp } from $int_ip_mail to
$int_ip_mail flags S/SA keep state

x) add in rules to allow any interjail communication as needed
(remember the incoming/outgoing packets appear the other way round
here - use tcpdump to check if in doubt)

If you have any problems, run tcpdump in a serarate terminal window to
determine what's going on.

Peter

On 5 February 2010 22:53, Maurice <mau...@gmail.com> wrote:
> Hi,
>
> I have been looking for a couple days now, with no luck, for some direction
> as to whether I can successfully configure my freebsd to NAT with only one
> NIC. �This is because I am setting up my system to jail my webserver, and I
> don't think I can get it to work without NATting it. If you have an
> alternate solution that would be great too. This is what my pf.conf looks
> like right now:
>
>
> # � � � $FreeBSD: src/share/examples/pf/pf.conf,v 1.1.2.1.6.1 2009/04/15
> 03:14:26 kensmith Exp $
> # � � � $OpenBSD: pf.conf,v 1.34 2007/02/24 19:30:59 millert Exp $
> #
> # See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
> # Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1
> # in /etc/sysctl.conf if packets are to be forwarded between interfaces.
>
> block in all
> block out all
>
> ext_if="fxp0"
> #int_if="int0"
> all_if="{fxp0, lo0}"
>
> #Internal network subnet
> int_net="10.0.0.0/32"
>
> #name and IP of webserver
> APACHE="10.0.0.1"
>
> #table <spamd-white> persist
>
> set skip on lo
>
> scrub in
>
> #nat-anchor "ftp-proxy/*"
> #rdr-anchor "ftp-proxy/*"
> #nat on $ext_if from !($ext_if) -> ($ext_if:0)
> #rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
> #no rdr on $ext_if proto tcp from <spamd-white> to any port smtp
> #rdr pass on $ext_if proto tcp from any to any port smtp \
> # � � � -> 127.0.0.1 port spamd
>
> #anchor "ftp-proxy/*"
> #pass out
>
> #pass quick on $int_if no state
> #antispoof quick for { lo $int_if }
> block in quick from urpf-failed
>
> pass in on $ext_if proto tcp to ($ext_if) port ssh synproxy state
> rdr on $all_if proto tcp from any to fxp0 port 80 -> $APACHE port 80
> nat on $ext_if from $APACHE to any -> fxp0
>
> #pass in log on $ext_if proto tcp to ($ext_if) port smtp
> #pass out log on $ext_if proto tcp from ($ext_if) to port smtp
>
> That doesn't seem to be doing the trick, since I can't ping and DNS won't
> resolve anything from within the jail (APACHE). I am going off some examples
> I found that would seem to suggest it is possible with only one NIC, but I
> can't seem to get it to work. Any help/advice would be greatly appreciated.
>
> thanks,
>
> Maurice
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-...@freebsd.org"
>

------------------------------

End of freebsd-pf Digest, Vol 276, Issue 1
******************************************

0 new messages