Re: binat and filtering
On Tuesday, Jun 3, 2003, at 00:41 US/Pacific, Volker Kindermann wrote: binat on fxp0 from $web_serv_int to any -> $web_serv_ext How are the packets seen by the filter? Is it: - for incoming packets: src: internet address of client dst: web_serv_int (that is after binat) - for outgoing packets: src: web_serv_ext (that is after binat) dst: address of (e.g.) dnsserver Is this correct? Yes. There's a flowchart here: http://mniam.net/pf/pf.png
Bandwidth cap for a bunch of hosts
Hi. Justhave a simple question. I have a openbsd 3.3 nat router and want to limit bandwith for each host on the lan (on both incoming and outgoing directions). The way i understand it i need to create a queue for each host on the lan (about 200) on the int_if (for incomming traffic)and on the ext_if (for outgoing traffic). Is there anyway you could simplyfy this using macros/whatever? that many rules and queues seems abit messy, so any ideas on how to keep pf.conf small and tidy would be appriciated. Thanks in advance :) //Kristoffer Björk
binat and filtering
Hi, I have a question concerning binat and filtering. I found the answer for rdr rules, but I'm not sure how this works with binat. Let's say I have: web_serv_int = "192.168.1.100" web_serv_ext = "24.5.6.0" binat on fxp0 from $web_serv_int to any -> $web_serv_ext How are the packets seen by the filter? Is it: - for incoming packets: src: internet address of client dst: web_serv_int (that is after binat) - for outgoing packets: src: web_serv_ext (that is after binat) dst: address of (e.g.) dnsserver Is this correct? Thanks Volker
Re: pfstat on alpha - floating point exception
got the same problem!
gate:/root >uname -rp
3.3 Digital AlphaPC 164LX 533 MHz
gate:/root >cat /etc/pfstat.conf
image "/var/www/htdocs/pfstat/pfstat.jpg" {
from 1 weeks to now
width 960 height 300
left
graph bytes_v4_in label "incoming" color 0 192 0
filled,
graph bytes_v4_out label "outgoing" color 0 0 255
right
graph states_searches label "states searches" color 192
192 0
}
gate:/home/ste >/usr/local/bin/pfstat -c /etc/pfstat.conf -d /var/log/pfstat
reading data file /var/log/pfstat
generating image file /var/www/htdocs/pfstat/pfstat.jpg
m[0] == 18130597.459994
m[1] == 120460.836135
Floating point exception (core dumped)
- Original Message -
From: "Jeremy Andrews" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 12:40 AM
Subject: pfstat on alpha - floating point exception
> Hi,
>
> I'm trying to use pfstat for my first time, but it seems every time I
> run it to generate images, it core dumps. It appears to be gathering data
> fine (I'm logging stats on my external interface) Now I'm trying to figure
> out if I'm just doing something really stupid, or if there's an issue with
> running pfstat on Alpha?
>
> Here's what I'm seeing:
>
> ---
> # uname -rp
> 3.3 COMPAQ AlphaServer DS10 466 MHz
> # cat /etc/pfstat.conf
> image "/var/www/htdocs/pfstat/one.jpg" {
> from 1 weeks to now
> width 960 height 300
> left
> graph bytes_v4_in label "incoming" color 0 192 0 filled,
> graph bytes_v4_outlabel "outgoing" color 0 0 255
> right
> graph states_searches label "states searches" color 192 192 0
> }
> # /usr/bin/pfstat -c /etc/pfstat.conf -d /var/log/pfstat
> reading data file /var/log/pfstat
> generating image file /var/www/htdocs/pfstat/one.jpg
> m[0] == 4353556.931810
> m[1] == 27621.584121
> Floating point exception (core dumped)
> ---
>
> I've tried various configurations for pfstat.conf, but always end up
> with a "Floating point exception". Any ideas?
>
> (I'm running OpenBSD 3.3, and installed/compiled pfstat from ports)
>
> Thanks,
> -Jeremy
>
> --
> Jeremy Andrews
> PGP Key ID: 8F8B617A http://www.kerneltrap.org/
>
>
>
Re: simple question: pfctl -vvsq
On Monday, Jun 2, 2003, at 21:05 US/Pacific, Dave St.Germain wrote: Another question: what is the difference between saying flags S/SA and S/SAFR when it comes to queueing? Or just in general? If you're using scrub, no difference to filtering; the scrub code already deals with illegal TCP flag combinations. If you're not scrubbing packets, the second would be a more accurate match for a connection-creating packet. No impact on queueing either way.
Re: simple question: pfctl -vvsq
On Monday, June 2, 2003, at 11:30 PM, Trevor Talbot wrote: You get to push 1.2Mbit/s outbound? Nice. At any rate, this is only outbound traffic being counted, not inbound. The only impact downloads have on this is response traffic. I realized my error after posting. For some reason I thought all traffic would go through the queue. No, my upload speed is capped at somewhere between 240-340kbps. Not bad for cable. Which is as it should be. When you start pushing a bunch of traffic out, the queues should ramp up to whatever max you specified on the interface (or until the link is saturated, whichever comes first). Another question: what is the difference between saying flags S/SA and S/SAFR when it comes to queueing? Or just in general? -- Dave St.Germain http://funk.shacknet.nu/
Re: simple question: pfctl -vvsq
On Monday, Jun 2, 2003, at 18:45 US/Pacific, Dave St.Germain wrote: Does pfctl -vvsq display bandwidth in bits/second or bytes/second? bits/sec. Here's a snippit (just basic ACK prioritizing): queue q_pri priority 7 [ pkts: 1475 bytes: 92446 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] [ measured: 5.4 packets/s, 2.84Kb/s ] queue q_def priq( default ) [ pkts: 46376 bytes: 21163651 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] [ measured:43.1 packets/s, 110.01Kb/s ] 110 kiloBYTES/second would make more sense considering I'm on a cable modem that can do about 1.2Mbits/sec on a really good day. You get to push 1.2Mbit/s outbound? Nice. At any rate, this is only outbound traffic being counted, not inbound. The only impact downloads have on this is response traffic. I haven't seen that number go higher than about 290Kb/s, even though I know I'm downloading at about the maximum speed. Which is as it should be. When you start pushing a bunch of traffic out, the queues should ramp up to whatever max you specified on the interface (or until the link is saturated, whichever comes first). An experiment you could try would be to define a queue on the inside interface. Don't specify a bandwidth, and just use one default queue. The statistics you get from that should reflect your download speeds.
simple question: pfctl -vvsq
Here's a simple question: Does pfctl -vvsq display bandwidth in bits/second or bytes/second? Here's a snippit (just basic ACK prioritizing): queue q_pri priority 7 [ pkts: 1475 bytes: 92446 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] [ measured: 5.4 packets/s, 2.84Kb/s ] queue q_def priq( default ) [ pkts: 46376 bytes: 21163651 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] [ measured:43.1 packets/s, 110.01Kb/s ] 110 kiloBYTES/second would make more sense considering I'm on a cable modem that can do about 1.2Mbits/sec on a really good day. I haven't seen that number go higher than about 290Kb/s, even though I know I'm downloading at about the maximum speed. What I'm getting at is: shouldn't it show a capital B if it's measuring bytes per second (and lowercase b for bits)? Or is my queue messed up? Sorry for being longwinded. I'm new here! Dave
RE: Ruleset Problem
Yea I added some now it works, this got it all working now, attaching 2 pf.conf's and the diagram is below, lemme know If I still got something amiss, I think I got it all. Eth0(---Internet) | Machine1---Eth1(10.0.0.1,10.0.0.0/24)-| | | Eth2(10.0.1.1,10.0.1.0/24) | | | | Eth0(---Internet) | | | Machine2---Eth1(10.0.0.2,10.0.0.0/24)-| | Eth2(10.0.4.1,10.0.4.0/24) Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j knight Sent: Monday, June 02, 2003 5:50 PM To: pf Subject: Re: Ruleset Problem Amir Seyavash Mesry wrote: > OMG TYPO! Packet is going from 10.0.0.51 to 10.0.0.1 to 10.0.0.2 to > 10.0.4.1 Maybe this clarifys it now, lol. I'm sorry, it really doesn't. > Machine1 > Eth0=77.77.77.77 > Eth1=10.0.0.1 network 10.0.0.0/24 > Eth2=10.0.0.2 network 10.0.0.0/24 > > Machine2 > Eth0=11.11.11.11 > Eth1=10.0.0.2 network 10.0.0.0/24 > Eth2=10.0.4.1 network 10.0.4.0/24 I don't understand how these machines are connected or which machine is loaded with the pf.conf you gave. You say above the packets are going from 10.0.0.2 to 10.0.4.1 but I don't see how that's possible with a /24 netmask without some intermediate hop. Did you test it with the "pass out" rules? .joel pf1.conf Description: Binary data pf2.conf Description: Binary data
RE: Ruleset Problem
Re-attaching pf2.conf, I forgot to add the ip changes. Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: Amir Seyavash Mesry [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 6:50 PM To: 'pf' Subject: RE: Ruleset Problem Yea I added some now it works, this got it all working now, attaching 2 pf.conf's and the diagram is below, lemme know If I still got something amiss, I think I got it all. Eth0(---Internet) | Machine1---Eth1(10.0.0.1,10.0.0.0/24)-| | | Eth2(10.0.1.1,10.0.1.0/24) | | | | Eth0(---Internet) | | | Machine2---Eth1(10.0.0.2,10.0.0.0/24)-| | Eth2(10.0.4.1,10.0.4.0/24) Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j knight Sent: Monday, June 02, 2003 5:50 PM To: pf Subject: Re: Ruleset Problem Amir Seyavash Mesry wrote: > OMG TYPO! Packet is going from 10.0.0.51 to 10.0.0.1 to 10.0.0.2 to > 10.0.4.1 Maybe this clarifys it now, lol. I'm sorry, it really doesn't. > Machine1 > Eth0=77.77.77.77 > Eth1=10.0.0.1 network 10.0.0.0/24 > Eth2=10.0.0.2 network 10.0.0.0/24 > > Machine2 > Eth0=11.11.11.11 > Eth1=10.0.0.2 network 10.0.0.0/24 > Eth2=10.0.4.1 network 10.0.4.0/24 I don't understand how these machines are connected or which machine is loaded with the pf.conf you gave. You say above the packets are going from 10.0.0.2 to 10.0.4.1 but I don't see how that's possible with a /24 netmask without some intermediate hop. Did you test it with the "pass out" rules? .joel pf2.conf Description: Binary data
pfstat on alpha - floating point exception
Hi,
I'm trying to use pfstat for my first time, but it seems every time I
run it to generate images, it core dumps. It appears to be gathering data
fine (I'm logging stats on my external interface) Now I'm trying to figure
out if I'm just doing something really stupid, or if there's an issue with
running pfstat on Alpha?
Here's what I'm seeing:
---
# uname -rp
3.3 COMPAQ AlphaServer DS10 466 MHz
# cat /etc/pfstat.conf
image "/var/www/htdocs/pfstat/one.jpg" {
from 1 weeks to now
width 960 height 300
left
graph bytes_v4_in label "incoming" color 0 192 0 filled,
graph bytes_v4_outlabel "outgoing" color 0 0 255
right
graph states_searches label "states searches" color 192 192 0
}
# /usr/bin/pfstat -c /etc/pfstat.conf -d /var/log/pfstat
reading data file /var/log/pfstat
generating image file /var/www/htdocs/pfstat/one.jpg
m[0] == 4353556.931810
m[1] == 27621.584121
Floating point exception (core dumped)
---
I've tried various configurations for pfstat.conf, but always end up
with a "Floating point exception". Any ideas?
(I'm running OpenBSD 3.3, and installed/compiled pfstat from ports)
Thanks,
-Jeremy
--
Jeremy Andrews
PGP Key ID: 8F8B617A http://www.kerneltrap.org/
Re: Ruleset Problem
Amir Seyavash Mesry wrote: OMG TYPO! Packet is going from 10.0.0.51 to 10.0.0.1 to 10.0.0.2 to 10.0.4.1 Maybe this clarifys it now, lol. I'm sorry, it really doesn't. Machine1 Eth0=77.77.77.77 Eth1=10.0.0.1 network 10.0.0.0/24 Eth2=10.0.0.2 network 10.0.0.0/24 Machine2 Eth0=11.11.11.11 Eth1=10.0.0.2 network 10.0.0.0/24 Eth2=10.0.4.1 network 10.0.4.0/24 I don't understand how these machines are connected or which machine is loaded with the pf.conf you gave. You say above the packets are going from 10.0.0.2 to 10.0.4.1 but I don't see how that's possible with a /24 netmask without some intermediate hop. Did you test it with the "pass out" rules? .joel
RE: Ruleset Problem
OMG TYPO! Packet is going from 10.0.0.51 to 10.0.0.1 to 10.0.0.2 to 10.0.4.1 Maybe this clarifys it now, lol. Machine1 Eth0=77.77.77.77 Eth1=10.0.0.1 network 10.0.0.0/24 Eth2=10.0.0.2 network 10.0.0.0/24 Machine2 Eth0=11.11.11.11 Eth1=10.0.0.2 network 10.0.0.0/24 Eth2=10.0.4.1 network 10.0.4.0/24 (routing table) Route Destination Gateway 10.0.0.0 Eth1 10.0.0.2 Eth1 10.0.1.0 Eth2 10.0.4.0 10.0.0.2 BTW, Thanks for working with me on this, and helping me figure where I am going wrong! Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j knight Sent: Monday, June 02, 2003 4:50 PM To: pf Subject: Re: Ruleset Problem Amir Seyavash Mesry wrote: > Sorry, I thought I gave enough info, they come in on eth1 and leave on > eth1. IE machine that pf.conf was given for is doing nat and some > small routing. Machine1(pf.conf given for this one) Eth0=internetip > Eth1=10.0.0.1 network 10.0.0.0/24 > Eth1=10.0.0.2 network 10.0.0.0/24 > > Machine2 > Eth0=internetip > Eth1=10.0.0.2 network 10.0.0.0/24 > Eth1=10.0.4.1 network 10.0.4.0/24 Now I'm really confused :(. Perhaps you could draw a simple diagram? > > If I am reading this right translation takes precendence over > filtering, which means If I have the following after translation, then > the packets will still pass, or do they get blocked after translation > on the outbound if.x Translated packets still pass through the filter engine and are subject to your filter rules > block in log all > block out log all ... so this will block translated packets. You'll need to "pass out on $ext ..." later on. > As for the keep state rules, what I was trying to accomplish is > passing packets between eth1 & eth2 checking state on each interface. > Maybe one 2 revised rules would be > > pass in on $eth1 inet proto udp from $lan1 to $lan2 keep state > pass in on $eth2 inet proto udp from $lan1 to $lan2 keep state Is $lan1 connected to $eth1 or $eth2? From what I can tell, $lan1 is on $eth1 so looking for packets from $lan1 on $eth2 isn't necessary. > Do I need a corresponding one backtracking such as? > > pass in on $eth2 inet proto udp from $lan2 to $lan1 keep state > pass in on $eth1 inet proto udp from $lan2 to $lan1 keep state Same situation here with $lan2. What you need is a set of rules to pass traffic OUT on $eth1, $eth2. Like I said, "keep state" only tracks state on one interface, not all of them. pass in on $eth1 from $lan1 to $lan2 keep state pass out on $eth2 from $lan1 to $lan2 keep state .joel
Re: dest-hash ?
On Monday, Jun 2, 2003, at 13:02 US/Pacific, Jedi/Sector One wrote: I have two upstream ADSL links, and PF with route-to/round-robin works very well to balance outgoing connections over both links. Although it won't solve all issues (especially with servers that use DNS to balance the load), would it have been possible to implement something like "dest-hash" so that a destination always get the same source address? As I suggested to someone else a while ago, you would probably be better off with something that dynamically manipulates the routing tables on the machine instead. You would also gain failover abilities from that setup. I believe routed(8) is capable, but I've never tried it. If you want to experiment with static routing: route add 0.0.0.0 -netmask 0.0.0.1 gateway1.ip route add 0.0.0.1 -netmask 0.0.0.1 gateway2.ip The net effect should be to choose one gateway based on whether the dest IP is odd or even. For the ICQ issue, you could also add a rule to route-to only one gateway for dest tcp port 5190. All that said, dest-hash might still be a useful option.
Re: Ruleset Problem
Amir Seyavash Mesry wrote: Sorry, I thought I gave enough info, they come in on eth1 and leave on eth1. IE machine that pf.conf was given for is doing nat and some small routing. Machine1(pf.conf given for this one) Eth0=internetip Eth1=10.0.0.1 network 10.0.0.0/24 Eth1=10.0.0.2 network 10.0.0.0/24 Machine2 Eth0=internetip Eth1=10.0.0.2 network 10.0.0.0/24 Eth1=10.0.4.1 network 10.0.4.0/24 Now I'm really confused :(. Perhaps you could draw a simple diagram? If I am reading this right translation takes precendence over filtering, which means If I have the following after translation, then the packets will still pass, or do they get blocked after translation on the outbound if.x Translated packets still pass through the filter engine and are subject to your filter rules block in log all block out log all ... so this will block translated packets. You'll need to "pass out on $ext ..." later on. As for the keep state rules, what I was trying to accomplish is passing packets between eth1 & eth2 checking state on each interface. Maybe one 2 revised rules would be pass in on $eth1 inet proto udp from $lan1 to $lan2 keep state pass in on $eth2 inet proto udp from $lan1 to $lan2 keep state Is $lan1 connected to $eth1 or $eth2? From what I can tell, $lan1 is on $eth1 so looking for packets from $lan1 on $eth2 isn't necessary. Do I need a corresponding one backtracking such as? pass in on $eth2 inet proto udp from $lan2 to $lan1 keep state pass in on $eth1 inet proto udp from $lan2 to $lan1 keep state Same situation here with $lan2. What you need is a set of rules to pass traffic OUT on $eth1, $eth2. Like I said, "keep state" only tracks state on one interface, not all of them. pass in on $eth1 from $lan1 to $lan2 keep state pass out on $eth2 from $lan1 to $lan2 keep state .joel
RE: Ruleset Problem
Sorry, I thought I gave enough info, they come in on eth1 and leave on eth1.
IE machine that pf.conf was given for is doing nat and some small routing.
Machine1(pf.conf given for this one)
Eth0=internetip
Eth1=10.0.0.1 network 10.0.0.0/24
Eth1=10.0.0.2 network 10.0.0.0/24
Machine2
Eth0=internetip
Eth1=10.0.0.2 network 10.0.0.0/24
Eth1=10.0.4.1 network 10.0.4.0/24
If I am reading this right translation takes precendence over filtering,
which means If I have the following after translation, then the packets will
still pass, or do they get blocked after translation on the outbound if.x
block in log all
block out log all
As for the keep state rules, what I was trying to accomplish is passing
packets between eth1 & eth2 checking state on each interface. Maybe one 2
revised rules would be
pass in on $eth1 inet proto udp from $lan1 to $lan2 keep state
pass in on $eth2 inet proto udp from $lan1 to $lan2 keep state
Do I need a corresponding one backtracking such as?
pass in on $eth2 inet proto udp from $lan2 to $lan1 keep state
pass in on $eth1 inet proto udp from $lan2 to $lan1 keep state
Amir Seyavash Mesry
[EMAIL PROTECTED]
LSI Logic Corporation
http://www.lsilogic.com/
Raid Support Test Technician
6145-D Northbelt Parkway
Norcross, GA 30071
678-728-1211
NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient, or believe that you have
received this communication in error, please do not print, copy, retransmit,
disseminate, or otherwise use the information. Also, please indicate to the
sender that you have received this communication in error, and delete the
copy you received. Thank you.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of j
knight
Sent: Monday, June 02, 2003 2:42 PM
To: pf
Subject: Re: Ruleset Problem
Amir Seyavash Mesry wrote:
> I am having a odd problem and I am hoping someone one the list can
> point out my error, Here is my pf.conf, the keepstate on the icmp
> doesn't seem to be working, it won't pass the packets out. Ie
> I am on host 10.0.0.51, I ping 10.0.4.1(routing table entry is present for
> this net) and it won't ping it, but if I ping 10.0.0.1(fxp1) then it will
> allow the packet and let it return. I think it is something really simple
> that I am overlooking but I can't figure it out. Any help is appreciated.
Which interface do packets have to exit to reach 10.0.4.1?
> #allow outgoing traffic from Internet nic to internet if initiated
> from Internet Nic.
> pass out on $eth0 inet proto tcp from $eth0 to anymodulate state
> pass out on $eth0 inet proto udp from $eth0 to anykeep state
> pass out on $eth0 inet proto icmp from $eth0 to any icmp-type 8 code 0
keep
> state
Translation happens before filtering so you will find that these rules
are passing packets from $lan1, $lan2 as well.
> #allow nat for both lan segments only if lan segments initiate request.
> pass out on $eth0 inet proto tcp from $lan1 to anymodulate
> state
> pass out on $eth0 inet proto udp from $lan1 to anykeep state
> pass out on $eth0 inet proto icmp from $lan1 to any icmp-type 8 code 0
> keep state
> pass out on $eth0 inet proto tcp from $lan2 to anymodulate
> state
> pass out on $eth0 inet proto udp from $lan2 to anykeep state
> pass out on $eth0 inet proto icmp from $lan2 to any icmp-type 8 code 0
> keep state
These rules will have no affect because of what I mentioned above.
> #allow requests from segment 1 to segment 2 or internet only if
> segment 1 requests it.
> pass in on $eth1 inet proto tcp from $lan1 to any modulate
> state
> pass in on $eth1 inet proto udp from $lan1 to any keep state
> pass in on $eth1 inet proto icmp from { $lan1, $loc } to any icmp-type 8
> code 0keep state
>
> #allow requests from segment 2 to segment 1 or internet only if
> segment 2 requests it.
> pass in on $eth2 inet proto tcp from $lan2 to any modulate
> state
> pass in on $eth2 inet proto udp from $lan2 to any keep state
> pass in on $eth2 inet proto icmp from { $lan1, $loc } to any icmp-type 8
> code 0 keep state
Where are your "pass out on { $eth1, $eth2 }" rules? "Keep state" only
tracks state on one interface; you still have to pass the traffic
through any other interface the packets will pass through.
.joel
dest-hash ?
Hello. I have two upstream ADSL links, and PF with route-to/round-robin works very well to balance outgoing connections over both links. However, round-robin brings a little issue. There are web sites that can't understand that a single session can use two different IP addresses. ICQ also doesn't like it. There's no way connecting to an ICQ server if the IP address of every packet changes. Although it won't solve all issues (especially with servers that use DNS to balance the load), would it have been possible to implement something like "dest-hash" so that a destination always get the same source address? -- __ /*- Frank DENIS (Jedi/Sector One) <[EMAIL PROTECTED]> -*\ __ \ '/http://www.PureFTPd.Org/";> Secure FTP Server \' / \/ http://www.Jedi.Claranet.Fr/";> Misc. free software \/
Re: fastroute
On Tue, 3 Jun 2003, Marco Grigull wrote: > A feature that might be useful to others would be to set the ttl to a defined > value, or adjust it for hiding not so capable routers. > > 'ttl -2' decremnt it by 2, probably useless > 'ttl 64' re/set it to 64, hiding a variety of OSes on the network > 'ttl +1' increment it by 1, hiding this firewall and an inner or outer router > 'ttl 0' aka fastroute If you want to have a hidden firewall, you should make it a bridge. PF already has some way to adjust the TTL of packets: 1) scrub has an option min-ttl to enforces a minimum TTL for matching IP packets. 2) -current has scrub reassemble tcp. pf.conf(4) explains what it does Statefully normalizes TCP connections. scrub reassemble tcp rules may not have the direction (in/out) specified. reassemble tcp per- forms the following normalizations: ttl Neither side of the connection is allowed to reduce their IP TTL. An attacker may send a packet such that it reach- es the firewall, affects the firewall state, and expires before reaching the destination host. reassemble tcp will raise the TTL of all packets back up to the highest value seen on the connection. Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
Re: Ruleset Problem
Amir Seyavash Mesry wrote:
I am having a odd problem and I am hoping someone one the list can point out
my error,
Here is my pf.conf, the keepstate on the icmp doesn't seem to be working, it
won't pass the packets out. Ie
I am on host 10.0.0.51, I ping 10.0.4.1(routing table entry is present for
this net) and it won't ping it, but if I ping 10.0.0.1(fxp1) then it will
allow the packet and let it return. I think it is something really simple
that I am overlooking but I can't figure it out. Any help is appreciated.
Which interface do packets have to exit to reach 10.0.4.1?
#allow outgoing traffic from Internet nic to internet if initiated from
Internet Nic.
pass out on $eth0 inet proto tcp from $eth0 to any modulate state
pass out on $eth0 inet proto udp from $eth0 to any keep state
pass out on $eth0 inet proto icmp from $eth0 to any icmp-type 8 code 0 keep
state
Translation happens before filtering so you will find that these rules
are passing packets from $lan1, $lan2 as well.
#allow nat for both lan segments only if lan segments initiate request.
pass out on $eth0 inet proto tcp from $lan1 to any modulate
state
pass out on $eth0 inet proto udp from $lan1 to any keep state
pass out on $eth0 inet proto icmp from $lan1 to any icmp-type 8 code 0
keep state
pass out on $eth0 inet proto tcp from $lan2 to any modulate
state
pass out on $eth0 inet proto udp from $lan2 to any keep state
pass out on $eth0 inet proto icmp from $lan2 to any icmp-type 8 code 0
keep state
These rules will have no affect because of what I mentioned above.
#allow requests from segment 1 to segment 2 or internet only if segment 1
requests it.
pass in on $eth1 inet proto tcp from $lan1 to any modulate
state
pass in on $eth1 inet proto udp from $lan1 to any keep state
pass in on $eth1 inet proto icmp from { $lan1, $loc } to any icmp-type 8
code 0 keep state
#allow requests from segment 2 to segment 1 or internet only if segment 2
requests it.
pass in on $eth2 inet proto tcp from $lan2 to any modulate
state
pass in on $eth2 inet proto udp from $lan2 to any keep state
pass in on $eth2 inet proto icmp from { $lan1, $loc } to any icmp-type 8
code 0 keep state
Where are your "pass out on { $eth1, $eth2 }" rules? "Keep state" only
tracks state on one interface; you still have to pass the traffic
through any other interface the packets will pass through.
.joel
fastroute
Hi, After as bit of experimenting around with fastroute, I found that setting it on an outbound rule was bad. It locks up the machine. Using it on inbound rules seems to work as expected. It would be great if the parser would pick this up, not allowing the ruleset to be loaded. Some doco to reflect this may also relieve others of needing to find out the hard way. A feature that might be useful to others would be to set the ttl to a defined value, or adjust it for hiding not so capable routers. 'ttl -2'decremnt it by 2, probably useless 'ttl 64're/set it to 64, hiding a variety of OSes on the network 'ttl +1'increment it by 1, hiding this firewall and an inner or outer router 'ttl 0' aka fastroute cheers Marco
Re: Ruleset Problem
On Monday, Jun 2, 2003, at 09:48 US/Pacific, Amir Seyavash Mesry wrote: Here is my pf.conf, the keepstate on the icmp doesn't seem to be working, it won't pass the packets out. Ie I am on host 10.0.0.51, I ping 10.0.4.1(routing table entry is present for this net) and it won't ping it, but if I ping 10.0.0.1(fxp1) then it will allow the packet and let it return. I think it is something really simple that I am overlooking but I can't figure it out. Any help is appreciated. # nat rules for both lan segments nat on $eth0 from $lan1 to any -> $eth0 nat on $eth0 from $lan2 to any -> $eth0 #block all in-out block in log all block out log all You don't have any "pass out" rules for $eth2, so the packet is never reaching 10.0.4.1 (assuming it's on $eth2; you didn't say). #allow nat for both lan segments only if lan segments initiate request. pass out on $eth0 inet proto tcp from $lan1 to any modulate state pass out on $eth0 inet proto udp from $lan1 to any keep state pass out on $eth0 inet proto icmp from $lan1 to any icmp-type 8 code 0 keep state pass out on $eth0 inet proto tcp from $lan2 to any modulate state pass out on $eth0 inet proto udp from $lan2 to any keep state pass out on $eth0 inet proto icmp from $lan2 to any icmp-type 8 code 0 keep state As a side note, these rules should never apply, as nat has already taken effect by the time you get to filter out on $eth0.
NAT + ESP
I'm having trouble getting pf to NAT ESP traffic, and am wondering if I am missing anything. NAT rules began as : nat on $ext from to any -> $natAddr And were expanded to this when I discovered NAT was not happening for ESP traffic: nat on $ext from to any -> $natAddr nat on $ext inet proto esp from to any -> $natAddr It appears ESP traffic is still traversing pf without being NATed, as evidenced by a catch-all rule that prevents untranslated traffic from leaving the egress interface (IPs changed): rule 1/0(match): block out on sis0: esp 1.2.3.4 > 5.6.7.8 spi 0x0022791B seq 21194 len 892 rule 1/0(match): block out on sis0: esp 1.2.3.4 > 5.6.7.8 spi 0x0022791B seq 21195 len 92 rule 1/0(match): block out on sis0: esp 1.2.3.4 > 5.6.7.8 spi 0x0022791B seq 21196 len 92 What am I doing wrong? matthew
Ruleset Problem
I am having a odd problem and I am hoping someone one the list can point out
my error,
Here is my pf.conf, the keepstate on the icmp doesn't seem to be working, it
won't pass the packets out. Ie
I am on host 10.0.0.51, I ping 10.0.4.1(routing table entry is present for
this net) and it won't ping it, but if I ping 10.0.0.1(fxp1) then it will
allow the packet and let it return. I think it is something really simple
that I am overlooking but I can't figure it out. Any help is appreciated.
#OpenBSD 3.3
#macros
#interfaces
eth0="fxp0"
eth1="fxp1"
eth2="fxp2"
#lan segment ips
lan1="10.0.0.0/24"
lan2="10.0.1.0/24"
loc="127.0.0.1/8"
#ip's to block
badip="0.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 172.31.0.0/16,
192.168.0.0/16, 224.0.0.0/3, 255.255.255.255/32"
lanip="10.0.0.0/8"
# Normalize: reassemble fragments and resolve or reduce traffic ambiguities
scrub in all
scrub out all
# nat rules for both lan segments
nat on $eth0 from $lan1 to any -> $eth0
nat on $eth0 from $lan2 to any -> $eth0
# rdr port mapping rules if needed
# rdr on eth0 proto tcp from any to 192.168.1.1/32 port 1234 -> 10.1.1.1
port 5678
# filter rules
#block all in-out
block in log all
block out log all
block in on $eth0 inet proto {tcp, udp} from any to any port 136 >< 140
#allow for dchp
pass in on $eth0 inet proto {tcp, udp} from any to $eth0 port 67
#allow outgoing traffic from Internet nic to internet if initiated from
Internet Nic.
pass out on $eth0 inet proto tcp from $eth0 to any modulate state
pass out on $eth0 inet proto udp from $eth0 to any keep state
pass out on $eth0 inet proto icmp from $eth0 to any icmp-type 8 code 0 keep
state
#allow nat for both lan segments only if lan segments initiate request.
pass out on $eth0 inet proto tcp from $lan1 to any modulate
state
pass out on $eth0 inet proto udp from $lan1 to any keep state
pass out on $eth0 inet proto icmp from $lan1 to any icmp-type 8 code 0
keep state
pass out on $eth0 inet proto tcp from $lan2 to any modulate
state
pass out on $eth0 inet proto udp from $lan2 to any keep state
pass out on $eth0 inet proto icmp from $lan2 to any icmp-type 8 code 0
keep state
#allow requests from segment 1 to segment 2 or internet only if segment 1
requests it.
pass in on $eth1 inet proto tcp from $lan1 to any modulate
state
pass in on $eth1 inet proto udp from $lan1 to any keep state
pass in on $eth1 inet proto icmp from { $lan1, $loc } to any icmp-type 8
code 0 keep state
#allow requests from segment 2 to segment 1 or internet only if segment 2
requests it.
pass in on $eth2 inet proto tcp from $lan2 to any modulate
state
pass in on $eth2 inet proto udp from $lan2 to any keep state
pass in on $eth2 inet proto icmp from { $lan1, $loc } to any icmp-type 8
code 0 keep state
#denie requests Out to internet for bad ip's
block out on $eth0 inet from any to { $badip, $lanip, $loc }
block out on $eth1 inet from any to { $badip }
block out on $eth2 inet from any to { $badip }
Amir Seyavash Mesry
[EMAIL PROTECTED]
LSI Logic Corporation
http://www.lsilogic.com/
Raid Support Test Technician
6145-D Northbelt Parkway
Norcross, GA 30071
678-728-1211
NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient, or believe that you have
received this communication in error, please do not print, copy, retransmit,
disseminate, or otherwise use the information. Also, please indicate to the
sender that you have received this communication in error, and delete the
copy you received. Thank you.
RE: pf/altq on a fast link
They would be much simpler if you supported OpenBSD PF, sadly you do not, making it difficult for people to trust what your offering since your basing your support on capital flow and not security. Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Sent: Sunday, June 01, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: Re: pf/altq on a fast link [EMAIL PROTECTED] (Henning Brauer) wrote in message news:<[EMAIL PROTECTED]>... > On Sun, Jun 01, 2003 at 06:20:23AM -0700, Dennis wrote: > > If you get serious about bandwidth management, take a look at > > something a bit more advanced at a very affordable price. Our > > software > > blah blah blah. what a bullshit. take your commercial advertising crap > elsewhere. Sorry. I hate to see people struggle to do simple things. Do you still use a hand mower to cut your grass too? Wash your clothes in a stream behind the house? :-) DB
Re: pf/altq on a fast link
On Mon, 1 Jun 2003, Dennis wrote: > [EMAIL PROTECTED] (Henning Brauer) wrote in message news:<[EMAIL PROTECTED]>... > > > > blah blah blah. what a bullshit. take your commercial advertising crap > > elsewhere. > > Sorry. I hate to see people struggle to do simple things. Do you still > use a hand mower to cut your grass too? Wash your clothes in a stream > behind the house? :-) No, we all use free software, and it works. //Wouter
