pfctl: carp0: driver does not support altq
Hi, The subject pretty much says it all. :-) The system is an older snapshot, 3.5 GENERIC#127 i386. I'd like to have live failover on my traffic shaper box, but when I try to queue on the carp interface I get the error pfctl: carp0: driver does not support altq I imagine that I could do some other sort of workaround to get live failover, say, with a crossover cable and ifstatd, but CARP is much much easier. Any suggestions? I've done some web searches, of course, but it seems that nobody else has this problem... ==ml -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: Cisco Routers for the Desperate http://www.CiscoRoutersForTheDesperate.com
Re: setting up vpn tunnel with nat - twisted
brianBOFH wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. This is possible, but very tricky. You can create a transport-mode IPSec flow between the public IP of your 2 gateways, and then do nat on enc0 and maybe rdr on enc0. There is a chicken and eggs problem between the routing table lookup and IPSec lookup. Read (man ipsec) about NAT and *enc#* interfaces. You will have to setup a dummy flow from 192.168.1.0/24 to convince the kernel to ipsec-process your packet. Plan a good week of trial-and-error to make that work. Cedric
Re: setting up vpn tunnel with nat - twisted
On Wed, 5 Jan 2005 18:20:10 -0500, brianBOFH wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. Cheers, Brian First we need to know that there are no address clashes between members of each LAN. Second: Do you expect to be able to connect in any way from LAN1:hostx to LAN2:hosty ? Or are you just wanting to do something at the other gateway? The question seemed easy (to state) to you but it misses much detail. If you tell us too much we can filter better than we can construct in the absence of detail. Maybe renumbering one end is actually easier.. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
carp and vlans
Hello list-members: I've got a problem with carp and vlans. The two firewalls are clustered (no loadbalancing, but ha). They are connected to a cisco switch in one trunk. State table changes are pronounced over interface em0 (crosslink). Problem seems to be: both firewalls have serveral vlans defined on the out Interface (fxp0). Of course both vlans are identical, only difference is the mac address. Now the firewalls allways complain about duplicate ip-addresses (duplicate IP address 192.168.90.69 sent from ethernet address 00:10:dc:f1:22:70). How to get rid of this (if possible at all)? Thank you for any tips Hints: uname -a: OpenBSD bsd_node1.smc-d.de 3.5 GENERIC#9 i386 sysctl net.inet.carp: net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=0 net.inet.carp.arpbalance=0 ifconfig -a: rl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:0a:cd:05:18:e8 media: Ethernet 100baseTX full-duplex status: active inet 192.168.90.248 netmask 0xffe0 broadcast 192.168.90.255 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:10:dc:f5:b2:0b media: Ethernet 1000baseT full-duplex status: active inet 10.10.10.1 netmask 0xfffc broadcast 10.10.10.3 fxp0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:10:dc:f5:b2:0c media: Ethernet 100baseTX full-duplex status: active inet 5.5.5.5 netmask 0xfff8 broadcast 5.5.5.7 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=41UP,RUNNING mtu 1348 pfsync: syncif: em0 maxupd: 128 vlan9: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:10:dc:f5:b2:0c vlan: 9 parent interface: fxp0 inet 82.210.20.190 netmask 0xfff8 broadcast 82.210.20.191 ---snip--- (here several more vlans) ---snip--- carp0: flags=41UP,RUNNING mtu 1500 carp: MASTER vhid 1 advbase 1 advskew 0 inet 192.168.90.249 netmask 0xffe0 carp1: flags=41UP,RUNNING mtu 1500 carp: MASTER vhid 2 advbase 1 advskew 0 inet 5.5.5.6 netmask 0xfff8 netstat -sp carp: carp: 18 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 159542 packets sent (IPv4) 0 packets sent (IPv6) Olaf Zenker Systemmanager SMC Düsseldorf T-Systems International GmbH Global Network Factory Systemmanagement Customer Solutions Sohnstr.45, 40237 Düsseldorf +49 211-9148-620 (tel) +49 211-9148-975 (fax) E-Mail: [EMAIL PROTECTED] Internetseite: http://www.t-systems.com Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: pfctl: carp0: driver does not support altq
Michael W. Lucas wrote: I'd like to have live failover on my traffic shaper box, but when I try to queue on the carp interface I get the error pfctl: carp0: driver does not support altq WHy are you trying to queue on the carp interfaces and not on the real interfaces? --- Lars
Re: setting up vpn tunnel with nat - twisted
On Thu, 06 Jan 2005 21:11:08 +1100, Rod.. Whitworth [EMAIL PROTECTED] wrote: On Wed, 5 Jan 2005 18:20:10 -0500, brianBOFH wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. Cheers, Brian First we need to know that there are no address clashes between members of each LAN. Second: Do you expect to be able to connect in any way from LAN1:hostx to LAN2:hosty ? Or are you just wanting to do something at the other gateway? The question seemed easy (to state) to you but it misses much detail. If you tell us too much we can filter better than we can construct in the absence of detail. Maybe renumbering one end is actually easier.. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server. There will definately be overlap between the two. Hence my wanting to nat the entire network going both directions. I need to connect from LAN1:host(1-254) to LAN2:host(1-254) and vice versa. Ideally I would be able to add a route to a pseudo-net(nat'd openbsd box the gateway of course) on either end. If it's not possible just say so :) Thanks, Brian
Re: pfctl: carp0: driver does not support altq
On Thu, Jan 06, 2005 at 08:59:53PM +0800, Lars Hansson wrote: Michael W. Lucas wrote: I'd like to have live failover on my traffic shaper box, but when I try to queue on the carp interface I get the error pfctl: carp0: driver does not support altq WHy are you trying to queue on the carp interfaces and not on the real interfaces? If that will work, I'll do it. It seems to me (now *there's* dangerous phrase :-) that since the traffic would be going to the IP address of the carp interface, I would have to queue on the carp interface? If I can just queue on the real interface, I'm fine with that. Can you just queue on the real interface and have it work for traffic arriving via CARP? I haven't been able to find any documentation one way or the other. ==ml -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: Cisco Routers for the Desperate http://www.CiscoRoutersForTheDesperate.com
Re: setting up vpn tunnel with nat - twisted
Thanks. On the flip-side, shouldn't I be able to setup one-direction fairly easily? In this case, connections can be initiated from LAN1 - LAN2 but not from LAN2 - LAN1. In this model - after IPSEC endpoints are created, I would simply nat traffic on the private interface from LAN1 to 192.168.1.50(openbsd gateway) with a destination of 192.168.88.0/24 - which then crosses the tunnel and gets NAT'd from 192.168.88.0/24 to 192.168.1.0/24(LAN2). Thoughts? :) -Brian On Thu, 06 Jan 2005 11:11:12 +0100, Cedric Berger [EMAIL PROTECTED] wrote: brianBOFH wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. This is possible, but very tricky. You can create a transport-mode IPSec flow between the public IP of your 2 gateways, and then do nat on enc0 and maybe rdr on enc0. There is a chicken and eggs problem between the routing table lookup and IPSec lookup. Read (man ipsec) about NAT and *enc#* interfaces. You will have to setup a dummy flow from 192.168.1.0/24 to convince the kernel to ipsec-process your packet. Plan a good week of trial-and-error to make that work. Cedric
Re: setting up vpn tunnel with nat - twisted
undeadly has this: http://www.undeadly.org/cgi?action=articlesid=20041009000521 Don't know if that's what you are looking for. On Wed, 5 Jan 2005 18:20:10 -0500, brianBOFH [EMAIL PROTECTED] wrote: Hi, I have two 192.168.1.0/24 networks physically separated. I need to get connectivity from one to the other and vice versa _without_ renumbering hosts. That being said - I have an openbsd 3.6 machine with one public and one private interface on each end. I know I can setup the tunnel between the two. But because I can't bridge and route between the same network, my question is setting up NAT between them. Obviously the SRC and DST needs to be rewritten on either side which means your typical NAT setup will not work. Can this be achieved with pf? If anyone can point me in the right direction I would appreciate it. Cheers, Brian
Strange ? keep state behaviour
Hello new to the list, but not exactly new to pf.
I've got a 3 interface firewall and I'm seeing what I would call strange
behaviour. Here is the scenario. I want to allow http in from the Internet
to a web server on an isolated segment. I have a rdr rule set up and it
works just fine (traffic flows when no filtering is being done).
If I have a rule set like the following:
block log all
antispoof quick for { lo0 $uat_if $dev_if }
# Allow web traffic to the UAT (marlin) box.
pass in log quick on $ext_if proto tcp from any to $marlin port { 80, 443 }
flags S/SA keep state
Traffic does not flow. I get the following in the logs:
Jan 06 12:11:56.324068 rule 13/0(match): pass in on ext_if:
out.side.add.ress.61005 in.side.web.server.80: S 3708921981:3708921981(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:11:56.324104 rule 0/0(match): block out on uat_if:
out.side.add.ress.61005 in.side.web.server.80: S 3708921981:3708921981(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:11:59.353276 rule 0/0(match): block out on uat_if:
out.side.add.ress.61005 in.side.web.server.80: S 3708921981:3708921981(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:12:05.361189 rule 0/0(match): block out on uat_if:
out.side.add.ress.61005 in.side.web.server.80: S 3708921981:3708921981(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
This does not make any sense to me. AFAIK (from reading man pf.conf
numerous times) the keep state should allow the traffic to pass once the
pass in on $ext_if... rule is matched.
Regardless, it does not work. To get it to work I have to add the following:
pass out log quick on $uat_if proto tcp from any to $marlin port {80, 443 }
flags S/SA keep state
Then my logs show:
Jan 06 12:19:32.244139 rule 13/0(match): pass in on ext_if:
out.side.add.ress.56709 in.side.web.server.80: S 457881634:457881634(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:19:32.244176 rule 15/0(match): pass out on uat_if:
out.side.add.ress.56709 in.side.web.server.80: S 457881634:457881634(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:19:32.567937 rule 13/0(match): pass in on ext_if:
out.side.add.ress.63950 in.side.web.server.80: S 3954645361:3954645361(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
Jan 06 12:19:32.567955 rule 15/0(match): pass out on uat_if:
out.side.add.ress.63950 in.side.web.server.80: S 3954645361:3954645361(0)
win 16384 mss 1460,nop,nop,sackOK (DF)
And it works and all is better. Except for the fact that this is not the
behaviour I expect from my reading of the docs.
Can anyone shed any light on this for me?
Thanks in advance.
Re: Strange ? keep state behaviour
I'm cc'ing the pf list so that the whole thread is archived.
I've included the whole pf.conf file. There isn't much more than what you
already have.
Your suggestion does work, but it weakens the rule set. Instead of a
default deny stance, I have a default deny inbound on the external interface.
It also doesn't provide any clue as to why keep state isn't carrying
across the interfaces.
Sven wrote:
snip On Thu, 06 Jan 2005 16:48:50 -0500, Jason Murray
[EMAIL PROTECTED] wrote:
Without seeing the rest of your ruleset (hint) I can't say for sure
but does it work if you change
block log all
to
block log all on $ext_if
?
# macros
uat_if = rl0 # UAT
dev_if = xl0 # DEV
ext_if = fxp0
tcp_services = { 22 }
icmp_types = echoreq
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
marlin = 10.245.245.130
simba = 10.245.245.2
# options
set block-policy return
set loginterface $ext_if
set state-policy floating
# scrub
scrub in all
# nat/rdr
nat on $ext_if from $uat_if:network to any - ($ext_if)
nat on $ext_if from $dev_if:network to any - ($ext_if)
#rdr on $uat_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
#rdr on $dev_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
rdr on $ext_if proto tcp from any to any port 80 - $marlin
rdr on $ext_if proto tcp from any to any port 443 - $marlin
# filter rules
# Default policy is to block traffic if it is not specifically allowed
block log all
antispoof quick for { lo0 $uat_if $dev_if }
# Traffic is allowed from Simba and Marlin
pass in log quick on $dev_if from any to $marlin keep state
# Traffic is not allowed from Marlin to Simba
block in log quick on $uat_if from any to $simba
# ssh vpn stuff
# Allow inbound ssh from the Internet only to the external interface.
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port { 22 } flags
S/SA keep state
# Allow traffic from the loopback to pass.
pass log quick on lo0 all keep state
# Allow web traffic to the UAT (marlin) box.
pass in log quick on $ext_if proto tcp from any to $marlin port { 80, 443 } flag
s S/SA keep state
# this rule should not be need since the keep state above should obviate it,
# however I could not get the traffic to pass unless it was there.
pass out log quick on $uat_if proto tcp from any to $marlin port {80, 443 } flag
s S/SA keep state
# Allow ping from any box to pass.
pass in log quick inet proto icmp all icmp-type $icmp_types keep state
Re: Strange ? keep state behaviour
On Thu, 2005-01-06 at 16:48, Jason Murray wrote:
Hello new to the list, but not exactly new to pf.
I've got a 3 interface firewall and I'm seeing what I would call strange
behaviour. Here is the scenario. I want to allow http in from the Internet
to a web server on an isolated segment. I have a rdr rule set up and it
works just fine (traffic flows when no filtering is being done).
If I have a rule set like the following:
block log all
antispoof quick for { lo0 $uat_if $dev_if }
# Allow web traffic to the UAT (marlin) box.
pass in log quick on $ext_if proto tcp from any to $marlin port { 80, 443 }
flags S/SA keep state
snip
i *really* hope someone will smack me if i'm off-base here, because i'm
not sure i'm 100% clear on this...BUT...as *i* understand it, as soon as
you use on $if in a rule--the state that is created is if-bound even
if your state-policy is floating. so you either (a) create 2 rules, one
pass in for the inbound interface and one pass out for the outbound
interface, (b) create strict rules on the inbound interface and a single
lax rule on the outbound interface or (c) don't use the on $if
construct in your rules.
personally--i use (b) for internal-external rules and (a) for
external-internal rules. i always assumed that if i needed to build a
pf.conf to support an enormous number of states--i would use (c).
-j
--
I'm having the best day of my life, and I owe it all to not going
to Church!
--The Simpsons
Re: Strange ? keep state behaviour
Sven wrote: On Thu, 06 Jan 2005 18:06:48 -0500, Jason Murray [EMAIL PROTECTED] wrote: I'm cc'ing the pf list so that the whole thread is archived. I've included the whole pf.conf file. There isn't much more than what you already have. Your suggestion does work, but it weakens the rule set. Instead of a default deny stance, I have a default deny inbound on the external interface. It also doesn't provide any clue as to why keep state isn't carrying across the interfaces. Because you block all traffic on $uat_if snip I think you misunderstand keep state. From man pf.conf: If a packet matches a pass ... keep state rule, the filter creates a state for this connection and automatically lets pass all subsequent packets of that connection. The emphasis is on subsequent. In your case the first packet, the one that's supposed to create the state, is blocked on $uat_if because of the block log all rule. I must have read that statement a dozen times. If I understand things properly when the packet comes in on $ext_if it creates the state. Because the state is floating it should be picked up when the packet tries to go out on $uat_if. Since it is in the state table it should pass no problem. To have to create a keep state rule on each interface a packet traverses seems counter intuitive to the way it is described. But, that does seem to be what is needed. This suggests that if I do: pass quick log from any to $marlin flags S/SA keep state It should also solve my problems. I'll try this tomorrow and see what results I get. The rule you added is a good solution to your problem. However, the implication is that if you want to be highly granular with your ruleset, then you will have to add more rules.
Re: Strange ? keep state behaviour
On Thu, 06 Jan 2005 18:06:48 -0500, Jason Murray [EMAIL PROTECTED] wrote:
I'm cc'ing the pf list so that the whole thread is archived.
I've included the whole pf.conf file. There isn't much more than what you
already have.
Your suggestion does work, but it weakens the rule set. Instead of a
default deny stance, I have a default deny inbound on the external interface.
It also doesn't provide any clue as to why keep state isn't carrying
across the interfaces.
Because you block all traffic on $uat_if
Sven wrote:
snip On Thu, 06 Jan 2005 16:48:50 -0500, Jason Murray
[EMAIL PROTECTED] wrote:
Without seeing the rest of your ruleset (hint) I can't say for sure
but does it work if you change
block log all
to
block log all on $ext_if
?
# macros
uat_if = rl0 # UAT
dev_if = xl0 # DEV
ext_if = fxp0
tcp_services = { 22 }
icmp_types = echoreq
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
marlin = 10.245.245.130
simba = 10.245.245.2
# options
set block-policy return
set loginterface $ext_if
set state-policy floating
# scrub
scrub in all
# nat/rdr
nat on $ext_if from $uat_if:network to any - ($ext_if)
nat on $ext_if from $dev_if:network to any - ($ext_if)
#rdr on $uat_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
#rdr on $dev_if proto tcp from any to any port 21 - 127.0.0.1 port 8021
rdr on $ext_if proto tcp from any to any port 80 - $marlin
rdr on $ext_if proto tcp from any to any port 443 - $marlin
# filter rules
# Default policy is to block traffic if it is not specifically allowed
block log all
antispoof quick for { lo0 $uat_if $dev_if }
# Traffic is allowed from Simba and Marlin
pass in log quick on $dev_if from any to $marlin keep state
# Traffic is not allowed from Marlin to Simba
block in log quick on $uat_if from any to $simba
# ssh vpn stuff
# Allow inbound ssh from the Internet only to the external interface.
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port { 22 }
flags
S/SA keep state
# Allow traffic from the loopback to pass.
pass log quick on lo0 all keep state
# Allow web traffic to the UAT (marlin) box.
pass in log quick on $ext_if proto tcp from any to $marlin port { 80, 443 }
flag
s S/SA keep state
# this rule should not be need since the keep state above should obviate it,
# however I could not get the traffic to pass unless it was there.
pass out log quick on $uat_if proto tcp from any to $marlin port {80, 443 }
flag
s S/SA keep state
# Allow ping from any box to pass.
pass in log quick inet proto icmp all icmp-type $icmp_types keep state
I think you misunderstand keep state. From man pf.conf:
If a packet matches a pass ... keep state rule, the filter creates a
state for this connection and automatically lets pass all subsequent
packets of that connection.
The emphasis is on subsequent. In your case the first packet, the one
that's supposed to create the state, is blocked on $uat_if because of
the block log all rule.
The rule you added is a good solution to your problem.
/Sven
--
Why are the pretty ones always insane?
-- J.G. Thirlwell
