Re: How to segregate forwarded and firewall-generated traffic in pf?
On 20/12/13 16:56, Maxim Khitrov wrote: On Thu, Dec 19, 2013 at 8:33 AM, Camiel Dobbelaar wrote: On 18/12/13 22:32, Camiel Dobbelaar wrote: I think a documentation fix for pf.conf(5) is all that can be done. The diff adds the following paragraph: When listening sockets are bound to the wildcard address, pf(4) cannot determine if a connection is destined for the firewall itself. To avoid false matches on just the destination port, combine a user rule with source or destination address self. Also, it deletes all mentions of the "unknown" user since it's useless. And the example is updated. Better? Not sure if you were asking me or other developers, but I think an update to the man page is fine. Yeah, anyone who was confused can chime in. :-) However, are you certain that pf cannot determine where the packet is going? It should be possible to perform a routing check to find out whether the destination IP belongs to the firewall, and thus may be accepted by a wildcard address, or if it's going to be forwarded to some other destination and should only match 'user unknown'. I think something similar is already being done by the urpf-failed check, only in reverse. Yes, that check is done (and belongs) in the IP layer. You don't want to duplicate that in pf. What the pf "user" socket check does is two things: (1) lookup existing TCP connections, this works fine (2) call the TCP in_pcblookup_listen() function which checks if a _TCP layer_ listener would accept the connection. But a wildcard bind looks like this: $ netstat -an | less Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp 0 0 *.22 *.*LISTEN That means the _TCP layer_ will accept any source and destination address, only the destination port has to match. As noted above, the _IP layer_ decides if a packet should be delivered locally or is forwarded. Hence, the "user" check is pretty useless for this purpose, and the manpage shouldn't imply that kind of usage. Regards, Cam
Re: How to segregate forwarded and firewall-generated traffic in pf?
On 18/12/13 22:32, Camiel Dobbelaar wrote:
On 18/12/13 14:50, Maxim Khitrov wrote:
On Wed, Dec 18, 2013 at 8:42 AM, Camiel Dobbelaar wrote:
On 18/12/13 13:53, Maxim Khitrov wrote:
When writing outbound rules in pf, is there an accepted best practice
for only matching packets that are either forwarded or
firewall-generated?
The best that I could come up with is 'received-on all' as a way of
identifying forwarded packets, but that option can't be negated to
match packets that were not received on any inbound interface (i.e.
those generated by the firewall itself).
Another option is 'from (self)', but then you have to be careful with
any preceding nat rules. Ideally, I want a solution that doesn't
depend on the context. I also tried to use tags in combination with
'received-on', but it became rather messy and created conflicts with
other tag usage.
What is everyone else using to solve this problem?
Check the "user" option in pf.conf(5):
user
This rule only applies to packets of sockets owned by the
specified user. For outgoing connections initiated
from the
firewall, this is the user that opened the connection.
For
incoming connections to the firewall itself, this is
the user
that listens on the destination port. For forwarded
connections,
where the firewall is not a connection endpoint, the
user and
group are unknown.
I tried that a while ago and it doesn't work as documented:
http://marc.info/?l=openbsd-bugs&m=137650531124231&w=2
http://marc.info/?l=openbsd-bugs&m=137658379014570&w=2
Nice of you to lure me in like this, and spent a few hours looking at
the code. :-)
I'd say the feature is indeed broken, and probably has been for more
then 10 years.
in_pcblookup_listen() in pf.c is the culprit. The destination IP does
not seem to matter for the socket lookup and will match anything. As
you noticed, this makes forwarded traffic match too.
So I guess the only way to make this work at all is to match the source
and destination IP's yourself first in pf.conf like this:
pass in from any to self port 22 user root
pass out from self to any user camield
I think a documentation fix for pf.conf(5) is all that can be done.
The diff adds the following paragraph:
When listening sockets are bound to the wildcard address,
pf(4)
cannot determine if a connection is destined for the firewall
itself. To avoid false matches on just the destination port,
combine a user rule with source or destination address self.
Also, it deletes all mentions of the "unknown" user since it's useless.
And the example is updated.
Better?
camield@xmts $ cvs diff -u
cvs server: Diffing .
Index: pf.conf.5
===
RCS file: /cvs/src/share/man/man5/pf.conf.5,v
retrieving revision 1.531
diff -u -p -u -r1.531 pf.conf.5
--- pf.conf.5 27 Nov 2013 15:16:29 - 1.531
+++ pf.conf.5 19 Dec 2013 13:32:17 -
@@ -760,9 +760,14 @@ For outgoing connections initiated from
that opened the connection.
For incoming connections to the firewall itself, this is the user that
listens on the destination port.
-For forwarded connections, where the firewall is not a connection endpoint,
-the user and group are
-.Em unknown .
+.Pp
+When listening sockets are bound to the wildcard address,
+.Xr pf 4
+cannot determine if a connection is destined for the firewall itself.
+To avoid false matches on just the destination port, combine a
+.Ar user
+rule with source or destination address
+.Ar self .
.Pp
All packets, both outgoing and incoming, of one connection are associated
with the same user and group.
@@ -777,32 +782,11 @@ user ID (to drop privileges), the creden
.Pp
User and group IDs can be specified as either numbers or names.
The syntax is similar to the one for ports.
-The value
-.Ar unknown
-matches packets of forwarded connections.
-.Ar unknown
-can only be used with the operators
-.Cm =
-and
-.Cm != .
-Other constructs like
-.Cm user \*(Ge unknown
-are invalid.
-Forwarded packets with unknown user and group ID match only rules
-that explicitly compare
-.Ar unknown
-with the operators
-.Cm =
-or
-.Cm != .
-For instance
-.Cm user \*(Ge 0
-does not match forwarded packets.
The following example allows only selected users to open outgoing
connections:
.Bd -literal -offset indent
-block out proto { tcp, udp } all
-pass out proto { tcp, udp } all user { \*(Lt 1000, dhartmei }
+block out proto tcp all
+pass out proto tcp from self user { \*(Lt 1000, dhartmei }
.Ed
.El
.Ss Translation
Re: How to segregate forwarded and firewall-generated traffic in pf?
On 18/12/13 14:50, Maxim Khitrov wrote: On Wed, Dec 18, 2013 at 8:42 AM, Camiel Dobbelaar wrote: On 18/12/13 13:53, Maxim Khitrov wrote: When writing outbound rules in pf, is there an accepted best practice for only matching packets that are either forwarded or firewall-generated? The best that I could come up with is 'received-on all' as a way of identifying forwarded packets, but that option can't be negated to match packets that were not received on any inbound interface (i.e. those generated by the firewall itself). Another option is 'from (self)', but then you have to be careful with any preceding nat rules. Ideally, I want a solution that doesn't depend on the context. I also tried to use tags in combination with 'received-on', but it became rather messy and created conflicts with other tag usage. What is everyone else using to solve this problem? Check the "user" option in pf.conf(5): user This rule only applies to packets of sockets owned by the specified user. For outgoing connections initiated from the firewall, this is the user that opened the connection. For incoming connections to the firewall itself, this is the user that listens on the destination port. For forwarded connections, where the firewall is not a connection endpoint, the user and group are unknown. I tried that a while ago and it doesn't work as documented: http://marc.info/?l=openbsd-bugs&m=137650531124231&w=2 http://marc.info/?l=openbsd-bugs&m=137658379014570&w=2 Nice of you to lure me in like this, and spent a few hours looking at the code. :-) I'd say the feature is indeed broken, and probably has been for more then 10 years. in_pcblookup_listen() in pf.c is the culprit. The destination IP does not seem to matter for the socket lookup and will match anything. As you noticed, this makes forwarded traffic match too. So I guess the only way to make this work at all is to match the source and destination IP's yourself first in pf.conf like this: pass in from any to self port 22 user root pass out from self to any user camield Regards, Cam
Re: How to segregate forwarded and firewall-generated traffic in pf?
On 18/12/13 13:53, Maxim Khitrov wrote: When writing outbound rules in pf, is there an accepted best practice for only matching packets that are either forwarded or firewall-generated? The best that I could come up with is 'received-on all' as a way of identifying forwarded packets, but that option can't be negated to match packets that were not received on any inbound interface (i.e. those generated by the firewall itself). Another option is 'from (self)', but then you have to be careful with any preceding nat rules. Ideally, I want a solution that doesn't depend on the context. I also tried to use tags in combination with 'received-on', but it became rather messy and created conflicts with other tag usage. What is everyone else using to solve this problem? Check the "user" option in pf.conf(5): user This rule only applies to packets of sockets owned by the specified user. For outgoing connections initiated from the firewall, this is the user that opened the connection. For incoming connections to the firewall itself, this is the user that listens on the destination port. For forwarded connections, where the firewall is not a connection endpoint, the user and group are unknown.
Re: how to compare ipsec.conf and isakmpd.conf settings?
On 9/27/13 10:46 AM, Daniel Polak wrote: What would have helped me solve this is a way to see what the current configuration of isakmpd looks like (irrespective of whether it was loaded from isakmpd.conf or from ipsec.conf). It appears there is no equivalent of a "C get all" command to the FIFO to get the configuration values of all sections in the running isakmpd configuration. If you send isakmpd a SIGUSR1, it will generate /var/run/isakmpd.report which also has the running configuration in it.
Re: Bridge0 "Oerrs" with throughput speed issues
On 9/16/13 5:56 PM, Stephen Maher wrote: There are no errors on any other interface. Some interfaces are autoneg and some are full 100 statically set. (Normally I associate network errors with negotiation mismatch however I'm baffled how this can happen with a bridge) The bridge code increases the Oerrs counter for roughly two reasons: - it cannot get an mbuf - the sendqueue of the interface it tries to send a packet on is full In your case it's probably the second reason. Do you have some interfaces at 100 and the others at 1000 Mbit/s ? -- Cam
Re: CARP on Switch ports without port fast leading to double master-master problems
On 7/22/13 1:12 PM, Andy wrote: I messed up and added '!sleep 5' to the hostname.carp instead of the physical interface.. None the less I'm surprised that no one else has any thoughts on this when it has been discussed several times before. It would be /very/ easy to resolve (by someone with talent and experience of the code base ;) and would aid the stability of OpenBSD greatly (in an operational sense), as the knock on effects this has really affect sasyncd, openbgpd and openospfd to name to the ones I have problems with when a cable is pulled/NIC reset etc. E.g. https://groups.google.com/forum/#!topic/fa.openbsd.tech/NXy2rivB_z0 I feel your pain. ;-) (the mail in the link is mine) I cannot imagine their is a technical challenge beyond adding a sleep(x) at INIT state with 'x' taken from a sysctl value (saying this as someone who doesn't know the code base at all). - One day when I have more time I will check it out.. If you happen to have the code base nearby I would really appreciate so much if you could throw a sleep in after CARP moves to INIT. Adding a sleep is simple indeed, but then everything would stop for x seconds... Seriously, I tried and found it hard to add. The carp functionality is event/timer based and there are already mechanisms in there that suppress and/or delay. -- Cam
Re: ftp-proxy(8) and ftpd(8) on the same host
On 3/27/13 4:14 PM, LEVAI Daniel wrote: On 5.2-stable, I'm trying to setup the stock ftpd(8) on a machine where the incoming traffic is not allowed arbitrarily above net.inet.ip.porthifirst, and the clients wish to use passive mode data connections. I thought I could use ftp-proxy(8) to append a pass in rule to the ftp-proxy anchor every time the client issues a PASV command, allowing the passive inbound data connection from the client to the server. I'm running ftp-proxy(8) and ftpd(8) like this: /usr/sbin/ftp-proxy -D 7 -b -p -R 127.0.0.1 -P 21 /usr/libexec/ftpd -D -A -ll -4 -n -W -u 027 -d [-P] # I've tried with and without -P It does not work on the same server. You might try rules with "user _ftp" in pf.conf.
Re: packet loss in larger packets
On Fri, 21 Sep 2012, Erwin Lubbers wrote: > I'm using OpenBSD 5.1 and an Intel 10GbE SR (82598AF) ethernet card as a > router/firewall and it's working almost perfect. It is routing around 2 gbps > of traffic. > > On the ix0 interface there are several vlans configured with an MTU of 1500. > When I'm pinging a switch connected to the system (with 10 gbps) there is no > packet loss while sending packets of 1472 bytes. From 1473 bytes and more > there is somewhere between 15 to 40% loss. > > I first thought the switch was busy, but from another (Linux) system, > connected with 10 gbps and the same network interface there is no loss on > larger packets. > > Does someone have an idea on how to solve this? Can you show from both systems with tcpdump what the packets look like? You are using normal (no flood) ping and the systems and switch are not loaded with other traffic?
Re: hostname.if: preventing IPV4 assignment
On 30-8-2012 23:30, Scott wrote: > vis-a-vis /etc/hostname.if, where the 'if' is em1 and is a real > interface that is aggregating several VLANs (as em1 is connected to a > Cisco L2 switch). Since the each of the VLAN interface has its own, > and topology relevant, IPV4 address, we don't want or need em1 itself > to have an IP. Our /etc/hostname.em1 is as follows, > > START > -inet mtu 1518 -inet6 group inside > up > END - > > However, post boot/reboot (but NOT "./netstart em1"), > > START > em1: flags=28843 mtu 1518 > lladdr 00:15:17:98:93:75 > priority: 0 > groups: inside > media: Ethernet autoselect (1000baseT full-duplex) > status: active > inet 8.15.7.107 netmask 0xff00 broadcast 8.255.255.255 > END - > > 'em1' is CORRECTLY absent an IPV6 address (NOINET6); however, it > always -- and UNDESIRABLY -- comes up with an IPV4 address in the > 8.n.n.n/8 range. (Side note: No idea why it gets an IPV4 8/8 as that > isn't in our topology anywhere and it becomes problematic at times to > the routing table.) > > What is the correct hostname.if configuration method for preventing an > interface from coming up with an NOINET4 result on boot/reboot? Why are you using -inet, is that somewhere in a manpage? If I try your hostname file I get a warning: camield@xmts $ sudo sh netstart vlan10 ifconfig: -inet: bad value What about just omitting that, and put the statements on seperate lines for clarity: mtu 1518 -inet6 group inside (side question: why do you need the mtu?) Note that "-inet" probably eats the "mtu" as an argument, and the 1518 is taken as an IPv4 address, and weird things happen here too: > camield@xmts $ sudo ifconfig vlan10 1518 > camield@xmts $ ifconfig vlan10 > vlan10: flags=8843 mtu 1500 > lladdr 00:d0:59:b6:f4:27 > priority: 0 > vlan: 10 parent interface: fxp0 > groups: vlan > status: active > inet6 fe80::2d0:59ff:feb6:f427%vlan10 prefixlen 64 scopeid 0x6 > inet 0.0.5.238 netmask 0xff00 broadcast 0.255.255.255
Re: ifconfig bridge delete
On 31-5-2012 19:01, Pieter Verberne wrote: > $ sudo ifconfig bridge0 delete athn0 > ifconfig: athn0: bad value > $ sudo ifconfig bridge0 del athn0 > $ The manpage is wrong. Only "del" works for the bridge. "delete" is used to remove an address from the interface. Probably a remainder of the brconfig/ifconfig merge. I'll prepare a diff for the manpage if nobody beats me to it.
Re: carp mixed states
They should both be backup. Check if you have "keep state (no-sync)" on your carp pf rule. If not add it, and flush the state tables. Other hints to debug carp setups: - netstat -s -p carp - ifconfig -g carp - sysctl net.inet.carp.log=4 (check /var/log/messages) -- Cam On 18-5-2012 3:38, shadrock wrote: > hi > still looking for an answer to the following question >> hi all >> have configured two firewalls with carp >> i have connectivity to the internet and the firewalls failover properly. >> when i check the carp states of each firewall the slave reports that its >> wan connection is in the master state the same as the master firewall >> while the slave carp lan connection is in the backup state. >> is this normal or should both carps be in backup for the slave ? >> shadrock >> >> >> master firewall >> /etc/hostname.carp1 >> inet 10.5.5.1 255.255.255.0 10.5.5.255 vhid 1 carpdev em1 pass pass1 >> >> /etc/hostname.carp2 >> inet 192.168.5.1 255.255.255.0 192.168.5.255 vhid 2 carpdev em0 pass >> pass2 >> >> /etc/hostname.em0 >> inet 192.168.5.2 255.255.255.0 >> >> /etc/hostname.em1 >> inet 10.5.5.2 255.255.255.0 NONE >> >> /etc/hostname.bge0 >> inet 172.16.0.2 255.255.255.0 NONE >> >> /etc/hostname.pfsync0 >> up syncdev bge0 >> >> >> ifconfig -a >> >> lo0: flags=8049 mtu 33196 >> priority: 0 >> groups: lo >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 >> inet 127.0.0.1 netmask 0xff00 >> bge0: flags=8843 mtu 1500 >> lladdr 00:18:8b:60:7b:06 >> priority: 0 >> media: Ethernet autoselect (1000baseT >> full-duplex,master,rxpause,txpause) >> status: active >> inet 172.16.0.2 netmask 0xff00 broadcast 172.16.0.255 >> inet6 fe80::218:8bff:fe60:7b06%bge0 prefixlen 64 scopeid 0x1 >> em0: flags=8b43 >> mtu 1500 >> lladdr 00:04:23:df:6b:a4 >> priority: 0 >> groups: egress >> media: Ethernet autoselect (100baseTX >> full-duplex,rxpause,txpause) >> status: active >> inet 192.168.5.2 netmask 0xff00 broadcast 192.168.5.255 >> inet6 fe80::204:23ff:fedf:6ba4%em0 prefixlen 64 scopeid 0x2 >> em1: flags=8b43 >> mtu 1500 >> lladdr 00:04:23:df:6b:a5 >> priority: 0 >> media: Ethernet autoselect (1000baseT >> full-duplex,rxpause,txpause) >> status: active >> inet 10.5.5.2 netmask 0xff00 broadcast 10.5.5.255 >> inet6 fe80::204:23ff:fedf:6ba5%em1 prefixlen 64 scopeid 0x3 >> enc0: flags=41 >> priority: 0 >> groups: enc >> status: active >> pfsync0: flags=41 mtu 1500 >> priority: 0 >> pfsync: syncdev: bge0 maxupd: 128 defer: off >> groups: carp pfsync >> pflog0: flags=141 mtu 33196 >> priority: 0 >> groups: pflog >> carp1: flags=8843 mtu 1500 >> lladdr 00:00:5e:00:01:01 >> priority: 0 >> carp: MASTER carpdev em1 vhid 1 advbase 1 advskew 0 >> groups: carp >> status: master >> inet6 fe80::200:5eff:fe00:101%carp1 prefixlen 64 scopeid 0x6 >> inet 10.5.5.1 netmask 0xff00 broadcast 10.5.5.255 >> carp2: flags=8843 mtu 1500 >> lladdr 00:00:5e:00:01:02 >> priority: 0 >> carp: MASTER carpdev em0 vhid 2 advbase 1 advskew 0 >> groups: carp >> status: master >> inet6 fe80::200:5eff:fe00:102%carp2 prefixlen 64 scopeid 0x7 >> inet 192.168.5.1 netmask 0xff00 broadcast 192.168.5.255 >> >> >> slave firewall >> >> /etc/hostname.carp1 >> inet 10.5.5.1 255.255.255.0 10.5.5.255 vhid 1 carpdev em1 advskew 100 >> pass pass1 >> >> /etc/hostname.carp2 >> inet 192.168.5.1 255.255.255.0 192.168.5.255 vhid 2 carpdev em0 advskew >> 100 pass pass2 >> >> /etc/hostname.em0 >> inet 192.168.5.3 255.255.255.0 >> >> /etc/hostname.em1 >> inet 10.5.5.3 255.255.255.0 NONE >> >> /etc/hostname.bge0 >> inet 172.16.0.3 255.255.255.0 NONE >> >> /etc/hostname.pfsync0 >> up syncdev bge0 >> >> >> ifconfig -a >> >> lo0: flags=8049 mtu 33196 >> priority: 0 >> groups: lo >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 >> inet 127.0.0.1 netmask 0xff00 >> bge0: flags=8843 mtu 1500 >> lladdr 00:18:8b:6c:4e:85 >> priority: 0 >> media: Ethernet autoselect (1000baseT >> full-duplex,rxpause,txpause) >> status: active >> inet 172.16.0.3 netmask 0xff00 broadcast 172.16.0.255 >> inet6 fe80::218:8bff:fe6c:4e85%bge0 prefixlen 64 scopeid 0x1 >> em0: flags=8b43 >> mtu 1500 >> lladdr 00:04:23:e3:c7:92 >> priority: 0 >> groups: egress >> media: Ethernet autoselect (100baseTX >> full-duplex,rxpause,txpause) >> status: active >> inet 192.168.5.3 netmask 0xff00 broadcast 192.168.5.255 >>
Re: CARP interfaces randomly stop answering ARP requests
On 11-4-2012 11:48, Johan Ryberg wrote: > Regarding "f_ether.c: IFQ_SET_MAXLEN(&arpintrq, 50); /* > XXX hate magic numbers */" > > Is 50 the limitation of logical interface per each physical or is it > 50 carp per logic interface? No, it's the limit on the _global_ arp queue. arp requests (regardless of the interface) get added to a queue. This queue gets serviced every once in a while (on a soft interrupt). The problem with bridge and carp is that they duplicate those arp requests, so 1 incoming arp request on the network may turn into 50 arp requests on the queue. One for each interface on a bridge or one for each carp interface per carpdev. -- Cam
Re: CARP interfaces randomly stop answering ARP requests
On 11-4-2012 11:07, Ian Chard wrote: > On 03/04/12 10:32, Camiel Dobbelaar wrote: >> I suspect you may run into this limit (in sys/netinet): >> if_ether.c: IFQ_SET_MAXLEN(&arpintrq, 50); /* XXX hate >> magic numbers */ >> >> Can you raise that number to 100 and compile a new kernel? > > I've now had this running since your suggestion, and the problem hasn't > come back. Thanks again! Thanks for reporting back. I'm working on a fix that grows the limit with the number of interfaces, so this should not be a concern again. -- Cam
Re: CARP interfaces randomly stop answering ARP requests
On 3-4-2012 11:13, Ian Chard wrote: > I have an OpenBSD box acting as a NATting firewall. It has 59 CARP > interfaces defined, all identical apart from the IP address and vhid. At > the moment there is no failover pair, so all the interfaces are in > MASTER mode. > > Every so often, one of these interfaces will suddenly stop answering ARP > requests. With tcpdump I can see the ARP requests coming in, but they > are never answered. ifconfig output for the interface is no different > to any of the other CARP instances; most notably, it is still in MASTER > mode. I have net.inet.carp.log set to 7, but nothing is logged when > this happens: no state changes, no other messages. > > Recovery is simple: I just 'ifconfig carpxx down; ifconfig carpxx up'. > The interface recovers in a second or two. > > I had this problem with 4.9-stable, and today I migrated the config to a > fresh 5.0-stable installation with the same results. > > Any help much appreciated! I assume all your carp interfaces have the same carpdev (physical interface) ? I suspect you may run into this limit (in sys/netinet): if_ether.c: IFQ_SET_MAXLEN(&arpintrq, 50); /* XXX hate magic numbers */ Can you raise that number to 100 and compile a new kernel? Alternatively, you can combine IP addresses (using "alias") on the carp interfaces so you have less of those. -- Cam
Re: pfsync changes in current?
On 14-3-2012 10:43, Kapetanakis Giannis wrote: >> While heavily demoted, it still assumes the master role. I guess it's >> not seeing the carp announcements from firewall-2 at all. Do you use >> spanning tree in the network? > > Yes. The latest change which I did on the switch where the firewalls are > connected is adding: > spanning-tree portfast trunk > spanning-tree bpdufilter enable > in order to startup the port faster. Don't know if this is causing the > problem, cause now the ports are coming up really fast. They used to > come up after 1 minute. Fast is good. >> How many states do you typically have? The bulk pfsync is taking a >> really long time here... 4 minutes. Any errors on the pfsync interface? >> What speed is it? > I usually have around 90k states (pfctl -ss |wc -l) > On both firewalls it's 1Gbps > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > media: Ethernet autoselect (1000baseT full-duplex,master,rxpause,txpause) > > # netstat -id > > Name Mtu Network AddressIpkts Ierrs > Opkts Oerrs Colls Drop > > em2(sync_if_f1) 150000:19:99:98:e4:ea 682406 225 > 255969304 0 0 0 > bge1(sync_if_f2) 150000:0a:e4:80:73:3d 387753797 461 > 1152887 0 0 0 Hmm, 225 errors on 682406 packets is low, but a bit higher then I would expect to see. > > f1# netstat -s > carp: > 12 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for wrong TTL > 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 unknown vhid > 0 discarded because of a bad address list > 1586084 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 8 transitions to master > pfsync: > 682381 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 88 stale states > 809627 failed state lookup/inserts > 256080550 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 0 send error This is not from just after the reboot right? The "failed state lookup/inserts" might be interesting just after the firewalls have stabilized. > f2# netstat -s > carp: > 2236176 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for wrong TTL > 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 unknown vhid > 0 discarded because of a bad address list > 460 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 12 transitions to master > pfsync: > 387828563 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for bad ttl > 0 packets shorter than header > 0 packets discarded for bad version > 0 packets discarded for bad HMAC > 0 packets discarded for bad action > 0 packets discarded for short packet > 0 states discarded for bad values > 435 stale states > 1173653 failed state lookup/inserts > 1152819 packets sent (IPv4) > 0 packets sent (IPv6) > 0 send failed due to mbuf memory error > 0 send error > > > >> What does your ifstated.conf look like? >> > > ifstated runs only on primary firewall. > Primary firewall runs with advbase 1 advskew 10 > secondary firewall runs with advbase 1 advskew 100 > > carp_up = "carp0.link.up&& carp1.link.up&& carp2.link.up&& > carp3.link.up" > carp_down = "!carp0.link.up&& !carp1.link.up&& !carp2.link.up&& > !carp3.link.up" > carp_sync = "carp0.link.up&& carp1.link.up&& carp2.link.up&& > carp3.link.up || \ > !carp0.link.up&& !carp1.l
Re: may 7 carp addresses be too much on 5.0/amd64 ?
On 13-3-2012 9:52, Janne Johansson wrote: > 2012/3/4 PP;Q Q P(P8P?P8QP8P= : >> thank to Camiel Dobbelaar, carp log at 6 shown ip_output problem, which >> lead me to: >> >> pass quick proto carp no state > > Which doesn't match the PF FAQ which says: > "Since CARP is its own protocol it should have an explicit pass rule > in filter rulesets: > pass out on $carp_dev proto carp keep state" > > I'll test the "no state" as soon as I can rig one of my previously > failing boxes to not use my carppeer workaround. I think "keep state (no-sync)" is better. You don't want carp to get dropped when the box gets congested and only traffic for established states gets through. Since this is biting lots of people maybe we should look into setting no-sync by default on carp traffic, be it in pfctl, pf, or pfsync.
Re: pfsync changes in current?
Hi, comments inline: On 9-3-2012 15:20, Kapetanakis Giannis wrote: > On 08/03/12 18:17, Peter Hessler wrote: >> On 2012 Mar 07 (Wed) at 15:58:21 +0200 (+0200), Kapetanakis Giannis >> wrote: >> :Hi, >> : >> :I'm running a setup of Active/backup firewalls with carp/pfsync >> :successfully for the last year. >> : >> :Today I've upgraded the primary firewall to the latest snapshot (12 >> Feb), >> :and as soon as the firewall booted it became MASTER before pfsync >> :bulk transfer completed. >> >> >> Can you show this piece from the logs? Do you have additional logs? >> >> How are the interfaces connected, do you have a dedicated link for the >> pfsync traffic? >> >> Can you also share your ruleset? > > Both firewalls are now upgraded to latest snapshot (12 Feb). > I've managed to reproduce it by rebooting primary firewall a while ago. > > Logs are at the end. > > Firewalls use dedicated interface for pfsync ($sync_if). Are they connected directly via a cable or is there a switch in between? > For external and internal connectivity I use dedicated VLANs ($ext_if > and $int_if) > > I'll show you relevant ruleset (due to internal policy I cannot share > full ruleset). > > @0 match in all scrub (no-df max-mss 1440) > @1 block drop quick inet6 all > @2 pass quick on $sync_if all flags S/SA keep state (no-sync) > @3 pass quick on $ext_if proto carp all keep state (no-sync) > @4 pass quick on $int_if proto carp all keep state (no-sync) > @5 pass quick on $other_vlan_if proto carp all keep state (no-sync) > @6 pass quick on $other_vlan_if proto carp all keep state (no-sync) I usually have "set skip" on the sync_if, if it's dedicated. > Here is the reproducing and the logs from /var/log/messages from both > firewalls > > firewall-1# ifconfig -g carp carpdemote > firewall-1# sync;sync;reboot > > Mar 9 15:46:42 firewall-2 /bsd: carp0: state transition: BACKUP -> MASTER > Mar 9 15:46:42 firewall-2 /bsd: arp_rtrequest: bad gateway value > Mar 9 15:46:42 firewall-2 /bsd: carp1: state transition: BACKUP -> MASTER > Mar 9 15:46:42 firewall-2 /bsd: arp_rtrequest: bad gateway value > Mar 9 15:46:42 firewall-2 /bsd: carp2: state transition: BACKUP -> MASTER > Mar 9 15:46:42 firewall-2 /bsd: arp_rtrequest: bad gateway value > Mar 9 15:46:42 firewall-2 /bsd: carp3: state transition: BACKUP -> MASTER > Mar 9 15:46:42 firewall-2 /bsd: arp_rtrequest: bad gateway value Any idea what causes the arp_rtrequest errors? Are all your IP addresses and netmasks sane? > Mar 9 15:47:00 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 1 (pfsyncdev) > Mar 9 15:47:00 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 1 (pfsyncdev) > Mar 9 15:47:02 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 2 (pfsync bulk start) > Mar 9 15:47:02 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 2 (pfsync bulk start) > Mar 9 15:47:02 firewall-2 /bsd: carp: pfsync0 demoted group carp by -1 > to 1 (pfsyncdev) > Mar 9 15:47:02 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by > -1 to 1 (pfsyncdev) > Mar 9 15:47:09 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 2 (pfsyncdev) > Mar 9 15:47:09 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 2 (pfsyncdev) > Mar 9 15:47:11 firewall-2 /bsd: carp: pfsync0 demoted group carp by -1 > to 1 (pfsyncdev) > Mar 9 15:47:11 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by > -1 to 1 (pfsyncdev) > Mar 9 15:47:26 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 2 (pfsyncdev) > Mar 9 15:47:26 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 2 (pfsyncdev) > Mar 9 15:47:29 firewall-2 /bsd: carp: pfsync0 demoted group carp by -1 > to 1 (pfsyncdev) > Mar 9 15:47:29 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by > -1 to 1 (pfsyncdev) > Mar 9 15:48:39 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 2 (pfsyncdev) > Mar 9 15:48:39 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 2 (pfsyncdev) > Mar 9 15:48:43 firewall-2 /bsd: carp: pfsync0 demoted group carp by -1 > to 1 (pfsyncdev) > Mar 9 15:48:43 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by > -1 to 1 (pfsyncdev) > Mar 9 15:49:08 firewall-2 /bsd: carp: pfsync0 demoted group carp by 1 > to 2 (pfsyncdev) > Mar 9 15:49:08 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by 1 > to 2 (pfsyncdev) > Mar 9 15:49:11 firewall-2 /bsd: carp: pfsync0 demoted group carp by -1 > to 1 (pfsyncdev) > Mar 9 15:49:11 firewall-2 /bsd: carp: pfsync0 demoted group pfsync by > -1 to 1 (pfsyncdev) > Mar 9 15:49:16 firewall-2 /bsd: carp1: state transition: MASTER -> BACKUP > Mar 9 15:49:16 firewall-2 /bsd: carp0: state transition: MASTER -> BACKUP > Mar 9 15:49:16 firewall-2 /bsd: carp3: state transition: MASTER -> BACKUP > Mar 9 15:49:16 firewall-2 /bsd: carp2: state transition: MASTER -> BACKUP > > Mar 9 15:49:10 firewall-1 /bsd: root on sd0a (45a94a78df33ffd9.a) swap > on sd0b dump on sd0b > Mar 9 15:49:10 f
Re: may 7 carp addresses be too much on 5.0/amd64 ?
Why is demote 2? Do you have any carp interfaces in INIT? Note that demote takes precedence over advskew. What does "ifconfig -g carp", "ifconfig carp" and "netstat -s -p carp" look like on both machines? On 3-3-2012 19:26, PP;Q Q P(P8P?P8QP8P= wrote: > I permormed tcpdump on appropriate vlan on BOTH SERVERS, I see on > "advskew=200" announces. MASTER with advskew=0 does not do any > advertisement. > > 22:22:37.296866 CARPv2-advertise 36: vhid=60 advbase=1 advskew=200 demote=2 > (DF) [tos 0x10] > 22:22:39.096900 CARPv2-advertise 36: vhid=60 advbase=1 advskew=200 demote=2 > (DF) [tos 0x10] > > 2 MARTA 2012 G. 16:14 POLXZOWATELX Otto Moerbeek NAPISAL: > >> On Fri, Mar 02, 2012 at 02:53:31PM +0500, ??? wrote: >> >>> no, I copied hostname.carpXX, just added "advskew 200" >>> parameters are the same. >> >> To be 100% sure, also look at ifconfig carpXX on both machines. >> >>-Otto >>> >>> 2 MARTA 2012 G. 15:25 POLXZOWATELX Otto Moerbeek >> NAPISAL: >>> On Fri, Mar 02, 2012 at 01:53:17PM +0500, ??? wrote: > hello! > > we are running CARP-ed load balancers (carp over different vlans). > it was running just great with 6 carp addresses. > > when we added 7th, randomly we get MASTERs on both server for certain carp > interface. After reboot we can get different carp interface on dual MASTER > state, and so on. > carp negotiations are ok, tcpdump shows them all. both peers see each other. > > if I put one interface to BACKUP state, it goes to mASTER soon. > > we are runnung 5.0/amd64 > > Cheers, > Ilya Shipitsin Carefully compare the address lists (including masks) on both machines. Likely they are not the same. -Otto
Re: may 7 carp addresses be too much on 5.0/amd64 ?
Do you have spanning tree enabled on the switch? The firewall ports should be in portfast mode, otherwise the backup may become master after a reboot or when bouncing the physical interface. And do you have carp preempt enabled? (net.inet.carp.preempt=1) On 2-3-2012 16:31, favar wrote: > hi list, we have same problem with carp. (with 45 ip addresses) > and after reboot, host with advskew 200 became master, and with > advskew 1 - slave. > > 2012/3/2 PP;Q Q P(P8P?P8QP8P= : >> no, I copied hostname.carpXX, just added "advskew 200" >> parameters are the same. >> >> 2 MARTA 2012 G. 15:25 POLXZOWATELX Otto Moerbeek NAPISAL: >> >>> On Fri, Mar 02, 2012 at 01:53:17PM +0500, ??? wrote: >>> hello! we are running CARP-ed load balancers (carp over different vlans). it was running just great with 6 carp addresses. when we added 7th, randomly we get MASTERs on both server for certain >>> carp interface. After reboot we can get different carp interface on dual >>> MASTER state, and so on. carp negotiations are ok, tcpdump shows them all. both peers see each >>> other. if I put one interface to BACKUP state, it goes to mASTER soon. we are runnung 5.0/amd64 Cheers, Ilya Shipitsin >>> >>> Carefully compare the address lists (including masks) on both >>> machines. Likely they are not the same. >>> >>> B B B B -Otto
Re: Problem filtering CARP in PF
On 2-3-2012 9:23, Marios Makassikis wrote: >> I just thought of something that bit me recently as well. >> >> With a real IPv6 address CARP will send out advertisements via IPv4 >> _and_ IPv6. It's the same CARP message so if either one reaches the >> backup it's ok. >> >> Your block rule had "inet" so you were probably blocking IPv4 only. But >> because of the send errors (due to pf blocking) fw1 started to demote >> itself. >> >> Anyway, you have to block inet6 too if you want to block carp completely. >> > > > Hi, > > I thought of this yesterday shortly after leaving ... > Indeed, after bumping the net.inet.carp.log value even more, there > are messages such as this one in /var/log/messages : > fw1 /bsd: carp0: ip_output failed: 65 > fw1 /bsd: carp0: ip6_output failed: 65 > fw1 /bsd: carp1: ip_output failed: 65 > fw1 /bsd: carp1: ip6_output failed: 65 > > After clearing the states, reloading PF to allow CARP packets, fw1 says it > transitioned from master to backup. I take it's because of the demote > counter: > as soon as I set it back up to 0, fw1 goes back to master and fw2 to backup. Ok! > The demotion counter is decremented when you lose connectivity (ip_output > errors for instance), but shouldn't it be reincremented when you regain > connectivity? Yup, it should. Maybe inet4 clears the errorcounter for inet6 or vice versa. I'll take a look. > I also tested the issue Frederic was having, and it seems to be fixed when > you > flush the rules and states after disabling PF. Hmm, could be an issue as well. It looks like disabling pf does not clear out all states etc. > @Russell > I think either > > pass quick proto carp keep state (no-sync) > > or > > pass quick proto carp no state > > is more appropriate, as it also takes into account pfsync presence and saves > you from debugging issues like the one I was having. As it trips up many people maybe pfctl and/or pf should apply "no-sync" automatically for carp.
Re: Problem filtering CARP in PF
On 1-3-2012 18:20, Camiel Dobbelaar wrote: > On 1-3-2012 18:10, Marios Makassikis wrote: >> Here you go: >> carp: >> 45808 packets received (IPv4) >> 74835 packets received (IPv6) >> 0 packets discarded for bad interface >> 0 packets discarded for wrong TTL >> 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 >> 32062 discarded for unknown vhid >> 0 discarded because of a bad address list >> 1582 packets sent (IPv4) >> 1582 packets sent (IPv6) I just thought of something that bit me recently as well. With a real IPv6 address CARP will send out advertisements via IPv4 _and_ IPv6. It's the same CARP message so if either one reaches the backup it's ok. Your block rule had "inet" so you were probably blocking IPv4 only. But because of the send errors (due to pf blocking) fw1 started to demote itself. Anyway, you have to block inet6 too if you want to block carp completely. Does that explain it? -- Cam
Re: Problem filtering CARP in PF
On 1-3-2012 18:10, Marios Makassikis wrote:
> Here you go:
> carp:
> 45808 packets received (IPv4)
> 74835 packets received (IPv6)
> 0 packets discarded for bad interface
> 0 packets discarded for wrong TTL
> 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
> 32062 discarded for unknown vhid
> 0 discarded because of a bad address list
> 1582 packets sent (IPv4)
> 1582 packets sent (IPv6)
> 0 send failed due to mbuf memory error
> 923 transitions to master
>
> The unknown vhid is because there another set of hosts using CARP
> on the same link. The fw1 and fw2 are using the same vhid.
Ok.
>> If I look at the code netinet/ip_carp.c:
>>
>>> error = ip_output(m, NULL, NULL, IP_RAWOUTPUT,
> &sc->sc_imo,
>>> NULL);
>>> if (error) {
>>> if (error == ENOBUFS)
>>> carpstats.carps_onomem++;
>>> else
>>> CARP_LOG(LOG_WARNING, sc,
>>> ("ip_output failed: %d", error));
>>> sc->sc_if.if_oerrors++;
>>> if (sc->sc_sendad_errors < INT_MAX)
>>> sc->sc_sendad_errors++;
>>> if (sc->sc_sendad_errors ==
> CARP_SENDAD_MAX_ERRORS(sc))
>>> carp_group_demote_adj(&sc->sc_if, 1,
>>> "> snderrors");
>>
>>
>> Either the "send failed due to mbuf memory error" counter should be
>> increasing, or an "ip_output failed" error should appear in the log.
>>
>
> As I said before, there's nothing besides state transitions and the snderrors
> I pasted and incorrectly interpreted. From your input, I take it the
> first demotion
> was because I put a 'block all', and as such the CARP packets were
> correctly blocked.
> The value going back to one is most likely due to the fact I reloaded
> PF with a rule
> to let CARP traffic pass. However, that doesn't explain why it isn't
> going back to 0.
Sorry, you need to bump net.inet.carp.log even more to see the
ip_output() error. Can you try net.inet.carp.log=6 ?
It's probably pf blocking the carp packets indeed, but maybe another
error will show up as well.
Re: random nat, ftp clients and 425: Securiy: Bad IP connecting
On 1-3-2012 16:43, Hrvoje Popovski wrote: > On 28.2.2012. 14:23, Stuart Henderson wrote: >>> >>> There is no such option in ftp-proxy. >>> >>> What _might_ work is to run one ftp-proxy per IP (30 in your case) and >>> use "random" on the divert-to. >>> >>> <5 minutes later> >>> >>> I just tried it, and it does not work... divert-to does not support >>> random like rdr-to does. >>> >>> -- >>> Cam >>> >>> >> >> *not* tested but you could probably run a couple of ftp-proxy >> instances on different ports and use 'probability' rules to hit the >> right one. >> >> btw: that random stuff, at least without source-tracking, is >> likely to break bank websites etc. >> > > hello, > > i really don't know how to test camiel's suggestion. it's very likely > that i'm doing something very wrong. camiel could you post some config > just to guide me? i'm willing to test it and post results. > > stuart's suggestion is working. i'm aware that random stuff breaks > things and for that reason users are in other vlan with other nat. I already said that my suggestion was not working. :-)
Re: Problem filtering CARP in PF
On 1-3-2012 16:32, Marios Makassikis wrote:
> Bumping net.inet.carp.log value only reports the demotion:
> carp:carp0 demoted group carp by 1 to 2 (> snderrors)
> carp:carp1 demoted group carp by 1 to 2 (> snderrors)
>
> And then, a few state transitions later:
> carp: carp0 demoted group carp by -1 to 1 (< snderrors)
>
> which corresponds to me trying to reset the demote counter back to 0.
No, that's not from your manual commands. It says there are send errors
when sending out the carp packets.
> 'netstat -sp carp' doesn't give any information I consider useful, besides
> the
> number of IPv4/IPv6 packets sent and received, as well as the number of
> transitions to master.
Just paste the output instead of interpreting...
If I look at the code netinet/ip_carp.c:
> error = ip_output(m, NULL, NULL, IP_RAWOUTPUT, &sc->sc_imo,
> NULL);
> if (error) {
> if (error == ENOBUFS)
> carpstats.carps_onomem++;
> else
> CARP_LOG(LOG_WARNING, sc,
> ("ip_output failed: %d", error));
> sc->sc_if.if_oerrors++;
> if (sc->sc_sendad_errors < INT_MAX)
> sc->sc_sendad_errors++;
> if (sc->sc_sendad_errors ==
> CARP_SENDAD_MAX_ERRORS(sc))
> carp_group_demote_adj(&sc->sc_if, 1,
> "> snderrors");
Either the "send failed due to mbuf memory error" counter should be
increasing, or an "ip_output failed" error should appear in the log.
--
Cam
Re: Problem filtering CARP in PF
On 1-3-2012 10:08, Marios Makassikis wrote: > Hello, > No, I'm using hardware machines. > > I tested what Imre suggested, i.e.: flushing PF states with > 'pfctl -F states'. > With a freshly booted machine, CARP packets are allowed to pass. > I then disabled pf, flushed the states and reloaded pf with the > 'block log' rule. At this point, CARP is effectively blocked, and > remains so until a reboot happens: adding a pass rule, clearing states > or even completely disabling pf had no effects. > > I tried using the following rule to let CARP pass: > pass quick log inet proto carp no state > > which leads me to a very odd CARP configuration: fw2 remains master > although it should go back to backup state. advskew on fw1 is 50, and > 100 on fw2. > A closer look at tcpdump revealed that CARP packets sent by fw1 have a > demote value of 1, which explains why fw2 remains master as its demote > value is 0. > What I can't explain is this: > > fw1~# ifconfig -g carp > carp: carp demote count 0 > > In other words, fw1 says it's demotion counter is null, but the messages > sent have a demote value of 1. At the same time, fw1 transitions from > backup to master and back again repeatedly, as I saw in > /var/log/messages. Are you sure that fw1 is sending and not receiving those? The only way to be really sure is to use "tcpdump -D out". > I tried setting the demotion counter to a higher value, say 10, using > 'ifconfig -g carp carpdemote 10' and then I get the expected behavior: > fw2 remains master, fw1 remains backup and the demote value displayed by > ifconfig is the same as the one that is sent to the other machine. Not sure what's going on yet, but the following may provide more hints: - bump net.inet.carp.log to 3 - check "netstat -s -p carp" - if you use pfsync, use "no-sync" on the carp pass rules
Re: Problem filtering CARP in PF
On 29-2-2012 23:01, Fridiric URBAN wrote: > Hello, > > Confirmed on a fresh and very simple virtual environnement with 2 > firewall using latest snapshot (amd64). > pf.conf containt a single line "block log", nothing is logged on pflog > and the other firewall on the sharing the link layer still catch carp > advertisement ! Virtual eh? I was wondering where the dmesg was. :-) If this is esxi you have to allow promiscious mode on the vswitch. Marios, are you using virtual machinery too? Can you post a dmesg otherwise? -- Cam
Re: random nat, ftp clients and 425: Securiy: Bad IP connecting
On 27-2-2012 22:22, Hrvoje Popovski wrote: > i'm having problem with ftp communication. when ftp client behind > openbsd 5.0 firewall connects to ftp server or servers > they see 425: Securiy: Bad IP connecting. > > openbsd has random nat with pool of /27 public addresess and inside > hosts connect through that pool. > when ftp-proxy is enabled or nat is configured without random nat > option, everything is working like charm. problem is that i need that > crazy random stuff :) > is there any option to rotate ip adrese per ftp session? There is no such option in ftp-proxy. What _might_ work is to run one ftp-proxy per IP (30 in your case) and use "random" on the divert-to. <5 minutes later> I just tried it, and it does not work... divert-to does not support random like rdr-to does. -- Cam
Re: PF: table sync
On 6-2-2012 10:52, Armin Wolfermann wrote: > * Camiel Dobbelaar [05.02.2012 20:19]: >> I'm not sure that pftabled is still maintained though. > > It is. > >> I reported a big flaw to the author in 2010 and it was never fixed. > > Aborting on a failure condition is not a flaw. Come on... it's a network daemon. It should be robust: able to handle wrong inputs and temporary failures. Right now, the daemon aborts when the table is not known: $ ./pftabled-client 127.0.0.1 56789 nonexist add 1.1.1.1 Server: $ sudo pftabled pftabled: ioctl: Invalid argument Or when I supply a wrong netmask (I modifed pftabled-client to allow it, the server should not trust clients to be well behaved): $ ./pftabled-client 127.0.0.1 56789 test add 1.1.1.1/33 There's probably more. pftabled should sanitize that stuff before feeding it into the kernel. AND be prepared to handle failure. > I told you in my reply > to your code review that pftabled is running on high-volume sites > doing several inserts per second without a single observation of > this condition. Sure, it may work great for you and a temporary failure may even be very hard to trigger. But why not just handle it instead of aborting? > However, your suggestion is on my list and will be > included in the next release. Ok good to hear it. -- Cam
Re: PF: table sync
On 5-2-2012 16:01, OSN | Marian Fischer wrote: > Am 05.02.2012 11:32, schrieb Maxim Bourmistrov: >> On Feb 5, 2012, at 10:47 AM, Otto Moerbeek wrote: >> >>> pfsync does not sync pf tables. >> Exactly, but it would be nice to have. >> >> //maxim >> > Hi, > > you should also take a look at wolfermann.org/pftabled.html > > Maybe that works out for you ... Syncing pf tables with a userland daemon could definitely work. I'm not sure that pftabled is still maintained though. I reported a big flaw to the author in 2010 and it was never fixed. -- Cam
Re: CARP strangeness after 5.0 upgrade
On 2-2-2012 17:34, Matt Hamilton wrote: > Camiel Dobbelaar sentia.nl> writes: > >> Can you post the output of "netstat -m" and a dmesg? > > # netstat -m > 94 mbufs in use: > 88 mbufs allocated to data > 3 mbufs allocated to packet headers > 3 mbufs allocated to socket names and addresses > 87/938/8192 mbuf 2048 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 4096 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 8192 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 9216 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 12288 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 16384 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 65536 byte clusters in use (current/peak/max) > 2308 Kbytes allocated to network (8% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines That looks ok. What is the carpdev of carp1 ? -- Cam
Re: CARP strangeness after 5.0 upgrade
On 2-2-2012 16:38, Matt Hamilton wrote: > Camiel Dobbelaar sentia.nl> writes: > >> Can you show the output of: >> - ifconfig carp >> - ifconfig -g carp >> - netstat -s -p carp >> - sysctl net.inet.carp > > Ahhh... actually, I noticed mbuf memory error with one of these: > > # netstat -s -p carp > carp: > 3112793 packets received (IPv4) > 0 packets received (IPv6) > 0 packets discarded for bad interface > 0 packets discarded for wrong TTL > 0 packets shorter than header > 0 discarded for bad checksums > 0 discarded packets with a bad version > 1347685 discarded because packet too short > 0 discarded for bad authentication > 0 discarded for unknown vhid > 0 discarded because of a bad address list > 4512672 packets sent (IPv4) > 0 packets sent (IPv6) > 8589 send failed due to mbuf memory error > 391 transitions to master > > And also increasing the carp logging I now see: > > Feb 1 13:50:02 fw1 /bsd: carp: carp1 demoted group carp by -1 to 0 (< > snderrors) > Feb 1 13:50:04 fw1 /bsd: carp0: state transition: BACKUP -> MASTER > Feb 1 13:56:48 fw1 /bsd: carp: carp1 demoted group carp by 1 to 1 (> > snderrors) > Feb 1 13:56:48 fw1 /bsd: carp0: state transition: MASTER -> BACKUP > > So how do I go about debugging this? Can you post the output of "netstat -m" and a dmesg?
Re: CARP strangeness after 5.0 upgrade
On 25-1-2012 18:23, Matt Hamilton wrote: > I'm also getting strange weirdnesses with carp on 5.0. I too upgraded > from quite an old 4.x version (4.6 IIRC). > > The main thing I'm seeing is my master and backup switching back and > forth quite a few times. This is a pair of firewalls with carp > running on both the inside and outside firewall interfaces. > > According to tcpdump I can see advertisements from the master being > broadcast, but I never see any broadcast from the backup (I can't > work out if that is correct behaviour or not). > > My PF rules allow the CARP packets through: > > pass in quick on $ext_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_out > pass in quick on $int_if proto carp from $fw_int_ips to 224.0.0.18 > queue carp_in > pass out quick on $ext_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_out > pass out quick on $int_if proto carp from $fw_ext_ips to 224.0.0.18 > queue carp_in > > And according to pfctl -sr -vv I can see that those rules are indeed > matching packets. > > The very odd thing is that on FW1: > > carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 10 > > and on FW2: > > carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 200 > > I don't understand why the master is the one with the highest > advskew. This is the same on the inside carp interface too. Can you show the output of: - ifconfig carp - ifconfig -g carp - netstat -s -p carp - sysctl net.inet.carp Do you use pfsync? If yes, can you try adding "keep state (no-sync)" to the carp rules? -- Cam
Re: how to find dependencies when building a new kernel
On 29-11-2011 13:00, Otto Moerbeek wrote: > On Tue, Nov 29, 2011 at 12:29:28PM +0100, Camiel Dobbelaar wrote: > >> On 29-11-2011 11:38, T. Valent wrote: >> >>>>> dmassage -t >>> >>>> i might be wrong, but is this really aggressive auto spelling >>>> corrector for "dmesg"? >>> >>> I found an example usage of dmassage on the web, but could not find the >>> program. So I thought the same way as you did. >>> >>> It's not part of the official OpenBSD or the ports tree. And it does not >>> do much more than providung a different view to what dmesg provides you >>> with. >>> >>> Maybe people woule recognize this tool if it just got a not so silly name. >> >> >> I wrote it 10 years ago, it's getting pretty obsolete now. I really >> think the name is the best part about it though! :-) > > I alwast undestood it as a reference to inspector Clouseau and his > pronunciation of the word message. Now I wonder if that association > was intended or not. > > http://www.imdb.com/title/tt0084814/quotes > > You got read it with a thick french accent. Hehe, no, it's simpler then that. It's about massaging the system (and hence the dmesg) into shape. I'm pretty sure that back then google also gave "exotic" hits for the word "dmassage" from page 2 onwards. Which I thought was funny as well. :-)
Re: how to find dependencies when building a new kernel
On 29-11-2011 11:38, T. Valent wrote: >>> dmassage -t > >> i might be wrong, but is this really aggressive auto spelling >> corrector for "dmesg"? > > I found an example usage of dmassage on the web, but could not find the > program. So I thought the same way as you did. > > It's not part of the official OpenBSD or the ports tree. And it does not > do much more than providung a different view to what dmesg provides you > with. > > Maybe people woule recognize this tool if it just got a not so silly name. I wrote it 10 years ago, it's getting pretty obsolete now. I really think the name is the best part about it though! :-)
Re: problem with trunkproto lacp and carppeer
On 10-11-2011 23:02, Ben Franklan wrote: > Hi all, > I set up FW1 and FW2 with trunk and CARP - If I set up the trunk > interface using trunkproto lacp and also specify a carppeer FW1 carp > interface does not return to master upon reboot and FW1 has 'carp > demote count 1'. I tried with various switch settings (lacp/active, > passive), em and bge interfaces, and the hosts plugged directly into > each other(no other switches to test with). I could bring everything > back to normal by doing carpdemote 100 on FW2. > > I finally starting mucking around with the start up scripts and this > ineloquently 'fixes' the issue for me. > # diff -u -b /etc/netstart.orig /etc/netstart > --- /etc/netstart.orig Thu Nov 10 12:39:22 2011 > +++ /etc/netstart Thu Nov 10 13:31:02 2011 > @@ -263,7 +263,9 @@ > # The trunk interfaces need to come up first in this list. > # The (s)vlan interfaces need to come up after trunk. > # Configure all the carp interfaces which we know about before default route. > -ifmstart "trunk svlan vlan carp" > +ifmstart "trunk" > +sleep 10 > +ifmstart "svlan vlan carp" You can put that sleep in the hostname.trunk file using "!sleep 10". It's not uncommon to use a sleep to wait for layer 2 protocols to settle. I sometimes use a sleep on the "last" physical interface if any of the interfaces are connected to a switch where spanning tree has to enable forwarding on the port. This prevents carp problems where the booted system becomes master for a while, because the link is up but the carp traffic is not forwarded yet. -- Cam
Re: pfsync states growing on carp backup firewall
I did not commit the fix for this bug in pfsync yet, but very soon now. On 9-11-2011 10:30, Maxim Bourmistrov wrote: > You might test to pull down if_pfsync.c from -current > or > flush states much sooner on failover with pf.conf (adaptive.start > adaptive.end) > > //maxim > > On Nov 9, 2011, at 9:49 AM, ML mail wrote: > >> Hi, >> >> I am running OpenBSD 5.0 amd64 on two firewalls using CARP (one master >> and one backup) for redundancy/fail-over purpose. Now on the backup firewall > I >> noticed that the states synchronised using pfsync on a dedicated NIC with a >> cross-over cable are at least double as much as on the master firewall. So > for >> example right now there are 15k states on the master firewall and 40k on > the >> backup firewall. From my understanding these numbers should pretty much >> correlate. >> >> I don't have the feeling I've been doing anything wrong neither as >> I have documented myself about how configuring CARP and have been running > it >> successfully before using OpenBSD 4.4 (I just re-installed with OpenBSD > 5.0). >> Just in case here are the relevant hostname.* config files: >> >> # >> /etc/hostname.em7 (master fw) >> inet 10.10.10.1 255.255.255.0 >> >> # >> /etc/hostname.em7 (backup fw) >> inet 10.10.10.2 255.255.255.0 >> >> >> # >> /etc/hostname.pfsync0 (master fw) >> up syncpeer 10.10.10.2 syndev em7 >> >> # >> /etc/hostname.pfsync0 (backup fw) >> up syncpeer 10.10.10.1 syndev em7 >> >> Could it >> be that my cross-over cable is somehow faulty? or my config is wrong? >> >> Thanks >> for the feedback. >> >> Regards, >> ML
Re: limit ftp download
You can only start one ftp-proxy with rc.conf. Just start the other one like this in /etc/rc.local (example from my own system, where I bind them to other addresses, you just need the -q and the -p): # Add your local startup actions here. echo -n ' ftp-proxy' /usr/sbin/ftp-proxy -D6 -a Y -p 8022 -r /usr/sbin/ftp-proxy -D6 -a Z -p 8023 -r On 3-11-2011 12:23, Wesley M. wrote: > I tried this : > added a second ftpproxy_flags in my /etc/rc.conf.local > > So in the file, we have : > ftpproxy_flags="-q ilimit" # Listen by default on 8021 > ftpproxy_flags="-q istd" # > > It doesn't work, it use the last line in /etc/rc.conf.local : istd queue > I suppose that it doesn't listen on the same port 8021 for 2 queue. > > So i try this, add this line to /etc/rc.local : > ftpproxy_flags="-q istd -p8022" > And in my /etc/rc.conf.local : > ftpproxy_flags="-q ilimit" > Restart the box, and do : netstat -anf inet > Listen on 127.0.0.1:8021 and 127.0.0.1:8022, seem to work > But the limit user download now 10Ko/s instead of 20Ko/s. > > I think, it is not the right way to do it. > Is there someone who have a sample ? using -T option for ftp-proxy ? > Thank you very much. > > Wesley. > >> On Thu, 03 Nov 2011 09:02:32 +0100, Camiel Dobbelaar > wrote: > >> Run two ftp-proxies: one with the -q ilimit and one with the -q istd. >> >> Then redirect the limited user to one proxy and the rest to the other.
Re: limit ftp download
On 3-11-2011 9:01, Wesley M. wrote: > Thank you for your reply. > I read the man page of ftp-proxy. > There's an option like you said, "-q queue". > But in my way, i have 2 queue : ilimit and istd > ilimit : bandwidth -> 20Ko/s > istd : bandwidth -> 128 Ko/s > > So i just modified to my /etc/rc.conf.local : > ftpproxy_flags="" to ftpproxyflags="-q ilimit" > Restart the box. > > Now, when this limited user download files using ftp, it downloads at > 20Ko/s. > But the others download also at 20Ko/s ; How can i fix the others to > download files at 128 Ko/s ? > How can i have 2 ftp stream like one 20Ko/s and 128 Ko/s ? Run two ftp-proxies: one with the -q ilimit and one with the -q istd. Then redirect the limited user to one proxy and the rest to the other.
Re: limit ftp download
On 3-11-2011 6:07, Wesley M. wrote: > I suppose it is because traffic are redirect to 127.0.0.1 (ftpproxy) > > sample of my pf.conf: > ... > anchor "ftp-proxy/*" > pass in on $lan inet proto tcp from $limithost \ > to port 21 divert-to 127.0.0.1 port 8021 queue ilimit > ... > > Is there a way to solve this problem? ftp-proxy has a '-q' option to set a queue.
Re: PFSYNC - pf.conf best practice
On 26-10-2011 20:32, Maxim Bourmistrov wrote: > The side question, after observing 'systat -s1 states', is WHY "failover"-side > doubles exp. time?? > I'm more expected to have it like a "copy" of the current state of the > master. Yes, the number of states should be roughly in sync on both firewalls. I'd keep pf.conf in sync too (including all settings). Is the backup firewall really idle on all interfaces? Does it happen without the pfsync mtu changes too? What does "netstat -s -p pfsync" say? What do you see if you capture "pfctl -ss | sort" on both firewalls (at the same time) and diff the outputs?
Re: PF with gigabit voice/video streams
On 4-6-2011 0:04, Stuart Henderson wrote: > On 2011-06-03, Eric K. Miller wrote: >>> Are you running -current? There have been some massive tweaks in >> networking performance in -current. Try out and report back. >> >> We were running 4.7 amd64 version (GENERIC.MP). Also tried the single >> processor version. >> >> Intel Pro/1000 MT cards were used. >> >> I should mention that we had a large number of virtual interfaces (300+) >> for routing traffic among these VLANs. So maybe this was the cause. > > after 4.9 we switched to an RB tree for local address lookups, > I think this is likely to help that situation. > > there is also a hash and sequentially-searched list used for vlan > tag lookup; dlg looked at replacing it with an RB tree before, iirc > it made things worse on some machines (probably those with microscopic > caches) but it's probably worth re-checking that... A simpler option may be to bump the hash size (TAG_HASH_SIZE) which only has 32 buckets now. Maybe even to 4096.
Re: ftp-proxy on a nat firewall
(private) HKS wrote: > Without -r things work just fine, but the shittiest ftp client I have > to test this is Windows 2003's native. What clients are known to > require the -r flag? I think I implemented -r for someone with an old VMS system. Most FTP clients work fine, don't use -r unless you're sure you need it. Is there some documentation floating on the web that suggests -r? I think the manpage pretty much discourages usage: -r Rewrite sourceport to 20 in active mode to suit ancient clients that insist on this RFC property. -- Cam
Re: ftp-proxy on a nat firewall
Camiel Dobbelaar wrote:
> (private) HKS wrote:
>> On Fri, Jan 23, 2009 at 3:06 PM, (private) HKS wrote:
>>> On Fri, Jan 23, 2009 at 8:49 AM, Daniel A. Ramaley
>>> wrote:
>>>> I've gotten a couple of off-list replies with suggestions to try. I
>>>> greatly appreciate any ideas, but still have not had any luck so far.
>>>> I've trimmed my ruleset and adjust some of it to be more permissive.
>>>> Any ideas as to why ftp-proxy still doesn't work?
>>>>
>>>>
>>>>
>>>> ext_if = "vr0"
>>>> int_if = "fxp0"
>>>>
>>>> icmp_types = "{ echoreq, unreach }"
>>>>
>>>> # options
>>>> set block-policy return
>>>> set loginterface $ext_if
>>>> set skip on lo
>>>>
>>>> # packet hygiene
>>>> scrub in all fragment reassemble
>>>>
>>>> # nat
>>>> nat on $ext_if from !($ext_if) -> ($ext_if)
>>>> nat-anchor "ftp-proxy/*"
>>>> rdr-anchor "ftp-proxy/*"
>>>> rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
>>>>
>>>> # filter rules
>>>> #block in all
>>>> #block quick inet6 all
>>>> anchor "ftp-proxy/*"
>>>> pass out keep state
>>>>
>>>> pass out quick proto tcp from lo to any port ftp
>>>>
>>>> pass in inet proto icmp all icmp-type $icmp_types keep state
>>>> #pass from !($ext_if) to any keep state
>>>> pass from any to any keep state
>>> Running ftp-proxy with the args "-r -d -D 6", can you do a packet
>>> capture when you run ls? You'll want to find all packets that involve
>>> the internal host, and all packets that involve your external
>>> destination, so you'll probably need to do two separate captures. This
>>> should at least give an idea of what's breaking.
>>
>>
>> Something is definitely amiss. Does anybody have a working
>> nat/ftp-proxy setup with 4.4? If so, can you post your rules and
>> ftp-proxy flags?
>>
>> My 4.3 router is working fine, but when I try this on 4.4 I get some
>> very weird behavior. The anchor rules and such are all inserted
>> correctly and ftp-proxy -vv logs the following (munged for clarity)
>> repeatedly until I kill the connection or it times out:
>>
>> 11:42:32.540840 rule 331.19328.1.0/(match) pass in on $ext_if:
>> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
>> (DF)
>> 11:42:32.540892 rule 331.19328.1.1/(match) pass out on $int_if:
>> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
>> (DF)
>> 11:42:32.540911 rule 331/(match) pass out on $ext_if: $ext_ip >
>> $server: icmp: host $ext_ip unreachable
>>
>>
>> The second log entry refers to traffic that was supposedly passed, but
>> my packet sniffer on $int_if never saw it (I tested with tcpdump
>> filters 'host $client_private' and 'host $server'). The anchor
>> information is in there:
>>
>> # pfctl -a ftp-proxy/19328.1 -s rules
>> pass in log (all) quick inet proto tcp from $server to $client_private
>> port = 1830 flags S/SA keep state (max 1) rtable 0
>> pass out log (all) quick inet proto tcp from $server to
>> $client_private port = 1830 flags S/SA keep state (max 1) rtable 0
>> # pfctl -a ftp-proxy/19328.1 -s nat
>> nat inet proto tcp from $server to $client_private port = 1830 rtable
>> 0 -> 129.128.5.191 port 20
>> rdr inet proto tcp from $server to $ext_ip port = 63607 rtable 0 ->
>> 10.2.0.13 port 1830
>>
>>
>> The only block in pf.conf is a "block all" at the top. Aside from a
>> bunch of other pass statements, it looks very similar to what Daniel
>> posted before.
>>
>> Running ftp-proxy with: ftp-proxy -r -dvvD 7
>>
>> Can anyone else replicate this?
>
> Yes, I can reproduce it. It looks like '-r' is the culprit.
>
> That's an option I would not recommend anyway, except if you have hosts
> that really need it. Can you try again without -r ?
>
> Very little changed in ftp-proxy itself between 4.3 and 4.4 so I suspect
> the substantial changes in pf itself may have caused this to break.
-r fails on -current too, I see this with loud pf logging:
Jan 30 13:14:43 donder /bsd: pf: stack key attach failed on all: TCP out
wire: 192.168.42.41:5001 213.130.162.6:20 stack: 192.168.42.41:5001
213.130.162.6:20 [lo=3117847903 high=3117847905 win=16384 modulator=0]
[lo=0 high=1 win=1 modulator=0] 2:0
Re: ftp-proxy on a nat firewall
(private) HKS wrote:
> On Fri, Jan 23, 2009 at 3:06 PM, (private) HKS wrote:
>> On Fri, Jan 23, 2009 at 8:49 AM, Daniel A. Ramaley
>> wrote:
>>> I've gotten a couple of off-list replies with suggestions to try. I
>>> greatly appreciate any ideas, but still have not had any luck so far.
>>> I've trimmed my ruleset and adjust some of it to be more permissive.
>>> Any ideas as to why ftp-proxy still doesn't work?
>>>
>>>
>>>
>>> ext_if = "vr0"
>>> int_if = "fxp0"
>>>
>>> icmp_types = "{ echoreq, unreach }"
>>>
>>> # options
>>> set block-policy return
>>> set loginterface $ext_if
>>> set skip on lo
>>>
>>> # packet hygiene
>>> scrub in all fragment reassemble
>>>
>>> # nat
>>> nat on $ext_if from !($ext_if) -> ($ext_if)
>>> nat-anchor "ftp-proxy/*"
>>> rdr-anchor "ftp-proxy/*"
>>> rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
>>>
>>> # filter rules
>>> #block in all
>>> #block quick inet6 all
>>> anchor "ftp-proxy/*"
>>> pass out keep state
>>>
>>> pass out quick proto tcp from lo to any port ftp
>>>
>>> pass in inet proto icmp all icmp-type $icmp_types keep state
>>> #pass from !($ext_if) to any keep state
>>> pass from any to any keep state
>>
>> Running ftp-proxy with the args "-r -d -D 6", can you do a packet
>> capture when you run ls? You'll want to find all packets that involve
>> the internal host, and all packets that involve your external
>> destination, so you'll probably need to do two separate captures. This
>> should at least give an idea of what's breaking.
>
>
>
> Something is definitely amiss. Does anybody have a working
> nat/ftp-proxy setup with 4.4? If so, can you post your rules and
> ftp-proxy flags?
>
> My 4.3 router is working fine, but when I try this on 4.4 I get some
> very weird behavior. The anchor rules and such are all inserted
> correctly and ftp-proxy -vv logs the following (munged for clarity)
> repeatedly until I kill the connection or it times out:
>
> 11:42:32.540840 rule 331.19328.1.0/(match) pass in on $ext_if:
> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
> (DF)
> 11:42:32.540892 rule 331.19328.1.1/(match) pass out on $int_if:
> $server.20 > $client_private.1830: S 67547520:67547520(0) win 16384
> (DF)
> 11:42:32.540911 rule 331/(match) pass out on $ext_if: $ext_ip >
> $server: icmp: host $ext_ip unreachable
>
>
> The second log entry refers to traffic that was supposedly passed, but
> my packet sniffer on $int_if never saw it (I tested with tcpdump
> filters 'host $client_private' and 'host $server'). The anchor
> information is in there:
>
> # pfctl -a ftp-proxy/19328.1 -s rules
> pass in log (all) quick inet proto tcp from $server to $client_private
> port = 1830 flags S/SA keep state (max 1) rtable 0
> pass out log (all) quick inet proto tcp from $server to
> $client_private port = 1830 flags S/SA keep state (max 1) rtable 0
> # pfctl -a ftp-proxy/19328.1 -s nat
> nat inet proto tcp from $server to $client_private port = 1830 rtable
> 0 -> 129.128.5.191 port 20
> rdr inet proto tcp from $server to $ext_ip port = 63607 rtable 0 ->
> 10.2.0.13 port 1830
>
>
> The only block in pf.conf is a "block all" at the top. Aside from a
> bunch of other pass statements, it looks very similar to what Daniel
> posted before.
>
> Running ftp-proxy with: ftp-proxy -r -dvvD 7
>
> Can anyone else replicate this?
Yes, I can reproduce it. It looks like '-r' is the culprit.
That's an option I would not recommend anyway, except if you have hosts
that really need it. Can you try again without -r ?
Very little changed in ftp-proxy itself between 4.3 and 4.4 so I suspect
the substantial changes in pf itself may have caused this to break.
--
Cam
Re: ftp-proxy and IP alias
Chris Smith wrote: > On Wed, Oct 22, 2008 at 11:52 PM, Chris Smith <[EMAIL PROTECTED]> wrote: >> Was finally able to test the reboot scenario and two instances of >> ftp-proxy do not get started from rc.conf.local. Needed to run the >> second instance from rc.local. > > Just wondering whether or not it's more proper to start the second > instance of ftp-proxy in rc.local (which I'm doing now) or to start it > in rc.securelevel ? rc.local is fine. -- Cam
Re: FTP-Proxy swallows 221 Message (MS FTP-Service)
Michael Hoffrath wrote: > Same problem here Running OpenBSD 4.2 (GENERIC) #375 i386. > > It seems not only being a problem of Microsoft, I've found that problem also > on VSFTPd (centos) and Filezilla (Windows 2003 Server). > > Both are sending "221 Goodbye" but ftp-proxy seems to swallow that from time > to time. It sounds like a race condition, where the server FIN reaches the proxy before the final data is sent out to the client. I'd have to dig into it a bit more. Does it cause a real problem? (in other words: how urgent is the fix?) -- Cam
Re: Flexibility of pf rules created by ftp-proxy?
Dave Anderson wrote: > I've been working on the pf configuration for my home firewall, > including setting up ftp-proxy. I've noticed that the command is > getting cluttered with options to adjust the rules it creates to the > needs of different pf configurations. Has any thought been given to > allowing arbitrary nat, rdr and pass rules to be specified in a > configuration file (in the same syntax as for pf.conf) with macros > defined for the server, client and proxy addresses (as in the examples; > also, perhaps, a few other macros -- such as for the interfaces through > which the client and server are reachable)? > > I'm not asking (let alone demanding) that anyone implement this, but > would like to know if it's been considered and rejected for some > reason, is on someone's to-do list, has never been thought about, or > whatever. It seems to me to be a good way both to avoid needing more > and more options to tweak the generated rules and to avoid the delay > involved in modifying the program whenever someone comes up with a new > need. Now that the 'tag' option is available I don't expect ftp-proxy to gain any more options wrt. to the pf rules it creates, because you can implement those yourself using 'tagged'. The history behind the current implementation is that I wanted it to be simple. Having a configuration file with pf rules means that you either have: - embed a full parser, which is a lot of code - run pfctl, which makes it harder to chroot Also, the FTP protocol is complex. Having the nat and rdr rules under user control would easily break things. So it would be a lot of extra code for not much gain. -- Cam
Re: openbsd 4.2 + ftp-proxy -T + pf +tag/tagged not working
S. Scott Sima, CISA, CISM wrote:
> Using openbsd 4.2, pf and ftp-proxy.
>
> ftp-proxy -T is not being recognized by pf.conf ruleset. In the
> NOT WORKING (snip) below, the tcpdump shows the ftp-proxied packets
> being ignored by the tagged pass rule and hitting on the final block all
> rule.
>
> ftp-proxy invoked as
> /usr/sbin/ftp-proxy -TOKFTP
>
> pf.conf
>
> WORKING using "user"
> (snip)
> rdr log on inside inet proto tcp \
> from (inside:network) to any port {ftp} -> 127.0.0.1 port 8021
> # -
> pass out quick log on outside inet proto tcp \
> user proxy modulate state queue( qlow, qhi)
> # -
> block drop log all
> # - EOF pf.conf
> (snip)
>
> NOT WORKING using tagged (snip)
> rdr log on inside inet proto tcp \
> from (inside:network) to any port {ftp} -> 127.0.0.1 port 8021
> # -
> pass out quick log on outside inet proto tcp \
> tagged OKFTP modulate state queue( qlow, qhi)
> # -
> block drop log all
> # - EOF pf.conf
> (snip)
I don't see the anchors, you need those with tagging too. Other then
that, it may still not work as expected, see:
http://marc.info/?l=openbsd-misc&m=119729395125104&w=2
Re: ftp-proxy feature request / tags
Bryan S. Leaman wrote: > OK, I'm trying to accomplish this with tags. However, ftp-proxy is > always putting "quick" in the rules, so no further processing is done > and my reply-to tagged rule (located after the anchor) is never matched. > > Would it make more sense to not use quick when -T option is > used with ftp-proxy? Or am I not understanding how these tags are to be > used? > > To test my theory, I modified filter.c in ftp-proxy and set > pfr.rule.quick=0, and now my tagged rule matches and the reply-to works. What you describe is exactly how it should work (ftpsesame, the other FTP proxy that I wrote already does it like that). I'll look into a fix for ftp-proxy. > On Tue, 4 Dec 2007, Camiel Dobbelaar wrote: > >> Bryan S. Leaman wrote: >>> I have a multiple ISP router/firewall running 4.2. To make FTP work >>> properly over both gateways, I found and applied the following patch to >>> ftp-proxy **see link below** and it's working great (apparently pftpx is >>> very similar to ftp-proxy). Without this fix, my second ftp-proxy >>> process (for ISP2) allows the incoming data connection but incorrectly >>> tries to respond over the firewall's default gateway (ISP1). This fix >>> adds a "reply-to" argument to the dynamic inbound rule and makes >>> everything work. I believe it also adds "route-to" when using passive >>> FTP. I have an explicit pf route-to rule to handle the initial outbound >>> FTP connection coming from the ftp-proxy. >>> >>> Is there any chance that this feature could be added to the OpenBSD >>> code? Or is there some other way to properly route FTP over multiple >>> gateways with the existing ftp-proxy? Seems like something that others >>> may find to be useful. >> >> I think I helped create part of that route-to diff, but I don't think it >> belongs in base ftp-proxy. A userland daemon should not control routing >> like that. >> >> Maybe the new 'tag' option can be used for this? (or else the tag >> option needs work ;-) )
Re: ftp-proxy feature request
Bryan S. Leaman wrote: > I have a multiple ISP router/firewall running 4.2. To make FTP work > properly over both gateways, I found and applied the following patch to > ftp-proxy **see link below** and it's working great (apparently pftpx is > very similar to ftp-proxy). Without this fix, my second ftp-proxy > process (for ISP2) allows the incoming data connection but incorrectly > tries to respond over the firewall's default gateway (ISP1). This fix > adds a "reply-to" argument to the dynamic inbound rule and makes > everything work. I believe it also adds "route-to" when using passive > FTP. I have an explicit pf route-to rule to handle the initial outbound > FTP connection coming from the ftp-proxy. > > Is there any chance that this feature could be added to the OpenBSD > code? Or is there some other way to properly route FTP over multiple > gateways with the existing ftp-proxy? Seems like something that others > may find to be useful. I think I helped create part of that route-to diff, but I don't think it belongs in base ftp-proxy. A userland daemon should not control routing like that. Maybe the new 'tag' option can be used for this? (or else the tag option needs work ;-) ) -- Cam
Re: ftp-proxy and no route to host issue
On Tue, 2 Oct 2007, Falk Brockerhoff wrote: > When I try to connect a ftp daemon "behind" the firewall I can see the > following entry in /var/log/messages > > /var/log/messages.2.gz:Oct 2 09:58:32 buffy ftp-proxy[21285]: #478593 > proxy cannot connect to server 195.225.xx.yy: No route to host > > I can try this several times, same result. In the meantime I'm able to > ping the target host on the cli of the firewall. A better test would be to try if you can "nc 21" from the firewall. > > I'd guess that pf is blocking the control (port 21) connection for some > > reason. Do you have limits on states, either globally or per rule? > > Maybe the limitations exists in ftp-proxy and not the firewall? > /etc/rc.conf.local says: > ftpproxy_flags="-a -m 500" Please don't edit the information... Did you use "127.0.0.1" or some other IP that's not routable for the loopback-ip ? > What will happen when the maximum of 500 sessions is arrived? "No route > to host" seems not to be the expacted message :) That's not it. If you reach the maximum you'll see something like "client limit reached". Can you show your NAT rules? And the information of "pfctl -si" when the problem happens? -- Cam
Re: ftp-proxy and no route to host issue
On Tue, 2 Oct 2007, Falk Brockerhoff wrote: > I'm using pf and ftp-proxy on an OpenBSD 4.2 GENERIC#374 i386 box. Most > the time everything works fine, but sometimes ftp-proxy reports a "no > route to host" in /var/log/messages. I can reproduce this behaviour, but > I'm able to ping the target ftp host on the cli at the same time > ftp-proxy reports the missing route. > > The target is reachable via a carp-interface on a dot1q tagged vlan > interface. > > Are there any known issues? Is there anything I can do to provide more > details? What does the logging say exactly? How do you reproduce it? I'd guess that pf is blocking the control (port 21) connection for some reason. Do you have limits on states, either globally or per rule? The carp interface is master the whole time? -- Cam
Re: ftp-proxy fxp transfers
On Sun, 1 Jul 2007, Chris Cohen wrote: > according to http://www.openbsd.org/faq/pf/ftp.html i've setup ftp-proxy and > changed my pf.conf. A client on the extern interface of the firewall can > upload files, use passive and active mode. But fxp transfers (server to > server) doesn't work. My ftpserver (vsftpd) on the host behind the firewall > doesn't tell me anything but: > Sun Jul 1 18:11:27 2007 [pid 3929] [chris] FAIL UPLOAD: > Client "10.1.3.1", "/home/chris/README.MIRRORING-US", 0.00Kbyte/sec > Doesn't ftp-proxy support fxp transvers in reverse mode? No, this entry in the manpage CAVEAT section applies: The negotiated IP address for active modes is ignored for security reasons. This makes third party file transfers impossible. I do have plans to make ftp-proxy optionally allow negotiated IP addresses, but I'm a bit busy at the moment, so don't hold your breath. -- Cam
Re: ftp-proxy binat design -- Was: Re: binat questions
On Sun, 1 Jul 2007, Karl O. Pinc wrote: > On 03/22/2007 03:17:00 PM, Stuart Henderson wrote: > > > One thing to watch out for with binat: you can't use it with > > ftp-proxy(8), since binat is of higher priority than the rdr or > > nat rules which are added to the anchor. The workaround there > > is to list nat and rdr separately. > > I just figured this out myself. > > binat + ftp-proxy => passive ftp broken > > It seems a bit clunky to work-around this in pf.conf > by doing both an rdr and a nat, and having double the > states in consequence. > > Instead, how does the design below sound? > > The basic idea is to modify ftp-proxy so it adds binat > rules to it's anchors. > > ftp-proxy adds a binat rule for every nat rule > added to its anchors. Like so (based on the man page): > > --- > In case of passive mode (PASV or EPSV): > > binat from $client to $server port $port -> $proxy You cannot use port in binat rules, so that would not work. An alternative would be to use a no binat from $client to $server so the nat rule in the ftp-proxy can take effect. But that would disable binat completely from $client to $server which is unacceptable, even for a short while. I think this problem can only be fixed in pf itself, by not prioritizing binat and just use the order in which all NAT rules are configured. That could subtly break some rulesets though, and it might be quite a lot of work. So rewriting binat to nat+rdr for hosts that need proxied FTP remains the only solution. -- Cam
Re: Using ftp-proxy(8) to proxy both internal and external FTP connections
On Fri, 22 Jun 2007, Damon McMahon wrote: > I'm trying to configure ftpd(8) to work on my OpenBSD 4.1 firewall > which currently proxies without issue client FTP connections to > outside FTP servers via ftp-proxy(8). You cannot proxy FTP from/to the firewall itself. pf user/group rules (user _ftpd) might be the way to go.
Re: FTP/ftp-proxy/pf issue.
On Tue, 10 Apr 2007, Steve Mertz wrote: > I'm trying to setup a firewall that allows FTP in to a server that is NATd on > the other side. But that only allows access from one address outside the > firewall. > > Something like: > > Machine -> Internet -> Firewall/NAT -> FTP server > > I realize I need to use ftp-proxy to get through the NAT part of the firewall, > but I'm not having much luck with it so far. > > Here is what I have: > /usr/sbin/ftp-proxy -R 10.10.11.10 > > pf.conf: > > $dev_addr = machine that has access to ftp to this server. > $proxy_addr = "127.0.0.1" > > > nat-anchor "ftp-proxy/*" > rdr-anchor "ftp-proxy/*" > rdr pass on $wan_if proto tcp from $dev_addr to $wan_if port ftp -> > $proxy_addr port 8021 > > block in all > block out all > anchor "ftp-proxy/*" > pass in proto tcp from $proxy_addr to any port 21 keep state This last rule is the problem. You need to pass _out_ from the firewall, and not using the 127.0.0.1 address, but the address that the kernel will pick for the connection to the server (10.10.11.1?). Or you can try this: pass out proto tcp from any to port 21 keep state user proxy -- Cam
Re: reverse ftp-proxy and reply-to?
On Sat, 17 Mar 2007, Sebastian Reitenbach wrote: > I use ftp-proxy on my firewall as a reverse proxy for a host on the dmz. The > incoming connections come in on one of the the external interfaces, which is > not the default gateway of the firewall. Therefore I use reply-to statements > on the pass in rules to make sure the answer packets are leaving the > firewall via this interface. The packets are redirected to the locally > running ftp-proxy. The control connection works fine for passive and active > ftp, but the data connection leaves the network on the wrong external > interface, following the default route, ignoring the reply-to statement when > they come in. ftp-proxy does not add route-to and reply-to to the rules it adds to the anchors to allow the data connections, so those will always be routed "normally". I once did some preliminary work on it though, after which Bill Marquette picked it up. Those patches are here: http://pfsense.com/cgi-bin/cvsweb.cgi/tools/pfPorts/pftpx-routeto/files/ (ftp-proxy used to be called pftpx) I'm not too fond of reply-to / route-to to be honest, so I never merged this into ftp-proxy proper. -- Cam
Re: ftp-proxy problem using active ftp
On Fri, 16 Feb 2007, [EMAIL PROTECTED] wrote: > #1 client: PORT 192,168,1,56,9,96\r\n > #1 proxy: PORT 193,172,163,50,235,99\r\n 193.172.163.50 is the correct external IP ? Does the firewall have more then one external IP? > #1 server: 200 PORT command successful - not using PASV eh?\r\n > #1 active: server to client port 2400 via port 60259 > #1 client: NLST\r\n This looks fine. At the point where it says "active" it has inserted the rules. You can check those like this: # pfctl -sA -v ftp-proxy ftp-proxy/27568.13 # pfctl -a ftp-proxy/27568.13 -sr pass in quick inet proto tcp from 129.128.5.191 to 192.168.28.28 port = 58202 flags S/SA keep state (max 1) rtable 0 pass out quick inet proto tcp from 129.128.5.191 to 192.168.28.28 port = 58202 flags S/SA keep state (max 1) rtable 0 and with -sn for the nat rules. Do those look correct? > My PF log isn't showing anything useful regarding ftp. Make sure all the rules have the log option set, especially the block rules. You can also try tcpdump on the external interface to check if the SYN packets of the active connection are coming in. If nothing comes in, someone upstream may be blocking. -- Cam
Re: Multiple ftp servers behind nat using pf-proxy?
On Mon, 22 Jan 2007, Satadru Pramanik wrote: > /usr/sbin/ftp-proxy -r -R 192.168.19.4 -p 21 -b externalip1 > /usr/sbin/ftp-proxy -r -R 192.168.19.122 -p 21 -b externalip2 > > Connections to externalip1 work just fine using ftp. > > Am I doing something wrong or is this just an unsupported configuration? You must use an rdr to redirect control (port 21) connections into ftp-proxy. Didn't the ftp-proxy logging warn you about that? I prefer ftp-proxy to listen on 127.0.0.1, and just change the listen port to be able to run more of them, like so: /usr/sbin/ftp-proxy -R 192.168.19.4 /usr/sbin/ftp-proxy -R 192.168.19.122 -p 8022 Then the redirects look like this: rdr pass on $ext_if proto tcp \ from any to $externalip1 port 21 -> 127.0.0.1 port 8021 rdr pass on $ext_if proto tcp \ from any to $externalip2 port 21 -> 127.0.0.1 port 8022 -- Cam
Re: dying ftp-proxy
Please try this diff: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ftp-proxy/ftp-proxy.c.diff?r1=1.10&r2=1.11 On Wed, 17 Jan 2007, Stefan Olsson wrote: > Hello, > > ftp-proxy starts up and runs fine for most of the time on one of my firewalls, > but sometimes and intermittently it just silently dies without any trace in > the daemon-log or messages. It is easy enough to just start it again, but it > is a bit annoying. I suppose I should start with upping the logging to max on > the daemon, but are there any suggestions straight away what could cause it to > die, or what files/logs to check? > > $ uname -a > OpenBSD here.some.where 4.0 GENERIC#1107 i386 > > /S
Re: ftp-proxy and old ftp-proxy co-mingling
On Thu, 11 Jan 2007, Ryan Corder wrote: > However, the 4.0 ftp-proxy and the 3.8 ftp-proxy don't seem to like > working with each other. When I attempt to ftp from the inside network > all the way out to the internet, I can get connected, but if I attempt > to do a transfer I receive a 'connection refused'. Here is the output > of 'ftp': The old ftp-proxy is not transparent. It directs the data connections to and from the firewall itself, instead of the real endpoint FTP server. The new ftp-proxy does not accept that. (it behaves like a 'strict' ftp client itself). Workarounds are as follows - run old ftp-proxy on both 3.8 and 4.0 - run new ftp-proxy on both 3.8 and 4.0 - run old ftp-proxy with -n so that at least passive mode works An option for new ftp-proxy to accept data connections to another IP then that of the control connection is on my TODO... but that's it. -- Cam
Re: VPN/IPSEC trouble with Checkpoint
If you are willing to try ipsec.conf instead of isakmpd.conf. I use the following for a VPN with a Checkpoint NG. ike esp from a.a.a.a/24 to b.b.b.b/20 \ local x.x.x.x peer y.y.y.y \ main auth hmac-md5 enc 3des group grp2 \ quick auth hmac-md5 enc 3des group none \ psk secretsecret The only thing special here is the "group none" in the quick line. This disables Perfect Forward Secrecy (pfs). That was needed for a succesful VPN setup together with a Checkpoint. -- Cam On Thu, 11 Jan 2007, Olivier Horn wrote: > Hi all! > I have a problem with a VPN tunnel. > > The VPN is set between an OpenBSD 4.0 GENERIC and a Checkpoint NG FP3. > When I etablish the tunnel all is okay for a while. But after a moment > (variable) the tunnel break because a NO_PROPOSAL_CHOSEN. The problem > appear to come from the OpenBSD side (see log below) and that for 3.9 and > 4.0. The isakmpd config file are very basic. > > I have to kill the isakmpd process and start it again (for a variable > moment only until a new NO_PROPOSAL_CHOSEN). > > From the log : > Dec 28 14:56:28 uranium isakmpd[21562]: attribute_unacceptable: > AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG > Dec 28 14:56:28 uranium isakmpd[21562]: ike_phase_1_validate_prop: > failure > Dec 28 14:56:28 uranium isakmpd[21562]: message_negotiate_sa: proposal 1 > failed > Dec 28 14:56:28 uranium isakmpd[21562]: message_negotiate_sa: no > compatible proposal found > Dec 28 14:56:28 uranium isakmpd[21562]: dropped message from > xxx.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN > > The Checkpoint side has 3DES/SHA/GRP2 with PRE-SHARED Secret for Phase 1 > and 3DES/SHA for Phase2 enabled. > > As somebody encoutered the same problem or have a tip to resolve this ? > > Thanks a lot in advance. > > Olivier > -- > > isakmpd.conf > > [General] > Retransmits= 5 > #Exchange-max-time= 120 > Exchange-max-time= 20 > Check-interval= 10 > Listen-on= xxx.xxx.xxx.xxx > #Default-phase-1-lifetime= 86400 > #Default-phase-2-lifetime= 3600 > DPD-check-interval= 20 > > [Phase 1] > Other= ISAKMP-peer-node-Other > > [Phase 2] > Connections= IPsec-Conn-Home-Other > > # ISAKMP Phase 1 peer sections > > [ISAKMP-peer-node-Other] > Phase= 1 > Address= XXX.XXX.XXX.XXX > Configuration= Default-main-mode > Authentication= TheGreatSecret > > # IPsec Phase 2 sections > > [IPsec-Conn-Home-Other] > Phase= 2 > ISAKMP-peer= ISAKMP-peer-node-Other > Configuration= Default-quick-mode > Local-ID= MyNet > Remote-ID= OtherNet > > # Client ID sections > > [MyNet] > ID-type= IPV4_ADDR_SUBNET > Network= 192.168.1.0 > Netmask= 255.255.255.0 > > [OtherNet] > ID-type= IPV4_ADDR_SUBNET > Network= 192.168.2.0 > Netmask= 255.255.255.0 > > # Main mode description > > [Default-main-mode] > DOI= IPSEC > EXCHANGE_TYPE= ID_PROT > Transforms= 3DES-SHA-GRP2 > > # Quick mode description > > [Default-quick-mode] > DOI= IPSEC > EXCHANGE_TYPE= QUICK_MODE > Suites= QM-ESP-3DES-SHA-SUITE > > --- > isakmpd.policy > > KeyNote-Version: 2 > Comment: This policy accepts ESP SAs from a remote that uses the right > password > $OpenBSD: policy,v 1.6 2001/06/20 16:36:19 angelos Exp $ > $EOM: policy,v 1.6 2000/10/09 22:08:30 angelos Exp $ > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && > esp_present == "yes" && > esp_enc_alg != "null" -> "true";
Re: ftp-proxy clarification
On Tue, 28 Nov 2006, Mark Freeze wrote: > I also have a question regarding ftp proxy. My situation is that we > have our firewall running, and I can connect and upload files to ftp > sites from any of my workstations. The problem occurs when we are > trying to download files. When I connect my machine will negotiate > the connection and get a directory listing, but crash when I try to > download files from the site. I know that it's the firewall because > my machines connect and download when the fw is taken out of the > process. I thought that maybe it was crashing when moving to an upper > port? And, if that is the case how do I correct it? > > What in my rule set would allow me to ftp upload a file, but crash on > the ftp download? Please start a new thread the next time. If you run ftp-proxy with "-d -D6" do you see anything interesting in the logging? If that doesn't help, can you try to catch the control and data connections on both sides of the firewall with tcpdump (snaplen 1500) ? ftp-proxy doesn't touch the data connections itself... it only commits rules into the anchors to let them pass. It does proxy the control connection, so it may buffer some lines that the FTP server is sending to the client and send them together. That's perfectly legal though. Which client are you using?
Re: ftp-proxy clarification
On Tue, 28 Nov 2006, Ryan Corder wrote: > While the PF User Guide is truly an excellent document, it seems to > assume that you allow all outound traffic, so it only instructs you to > add a couple of anchors and a redirect rule. Do I need an additional > outbound 'pass' rule for FTP high ports, or does ftp-proxy handle all of > that via the anchors? ftp-proxy handles all the data connections (passive and active) via the anchors. You don't need to add extra rules. That _should_ become clear from the manpage... if not improvements are always welcome. :-) -- Cam
demystify enc interface
I'm trying to figure out how the enc interface works, and especially how to filter it using pf. This is what enc(4) says: The enc interface allows an administrator to see outgoing packets before they have been processed by ipsec(4), or incoming packets after they have been similarly processed, via tcpdump(8). The ``enc0'' interface inherits all IPsec traffic. Thus all IPsec traf- fic can be filtered based on ``enc0'', and all IPsec traffic could be seen by invoking tcpdump(8) on the ``enc0'' interface. I think this tells me that I can see unencrypted/unencapsulated traffic on enc0. However, with tcpdump I see this: 14:09:27.894326 (authentic,confidential): SPI 0x728aafc9: 86.90.xx.xx > 62.58.xx.xx: 192.168.2.3.1264 > 192.168.1.7.8194: . [tcp sum ok] ack 139 win 64431 (DF) (ttl 128, id 45685, len 40) (ttl 118, id 45685, len 60) 14:09:27.915205 (authentic,confidential): SPI 0x021e1fcd: 62.58.xx.xx > 86.90.xx.xx: 192.168.1.131.3389 > 192.168.2.3.1182: . [tcp sum ok] ack 177 win 65075 (ttl 127, id 59080, len 40) (ttl 64, id 46361, len 60, bad cksum 0!) The encapsulation is included... that's pretty cool and handy, but I'm not sure if that's what the manpage says. And it looks like pf has its tentacles elsewhere in the stack, here's what I see if I log what gets passed on enc0: 09:00:21.390463 rule 514/(match) [uid 0, pid 15450] pass in on enc0: 84.104.xx.xx > 62.58.xx.xx: 192.168.28.28.46259 > 192.168.42.10.993: [|tcp] (DF) (ttl 63, id 9133, len 64) (ttl 55, id 6610, len 84, bad cksum a754!) 09:00:21.390541 rule 514/(match) [uid 0, pid 15450] pass in on enc0: 192.168.28.28.46259 > 192.168.42.10.993: S 1525235396:1525235396(0) win 16384 (ttl 63, id 9133, len 64, bad cksum 5094!) 14:15:32.553135 rule 515/(match) [uid 0, pid 23431] pass out on enc0: 192.168.42.10.24605 > 192.168.28.28.22: [|tcp] [tos 0x10] (ttl 63, id 33734, len 64) So inbound traffic passes twice: first with encapsulation, and the second time without. However, outbound traffic only passes _once_, without the encapsulation. So I think the pf rules for filtering on enc0 should look like this: # pass encapsulated traffic pass in quick log on enc0 proto ipencap from $ext_peer_ip to $ext_if keep state (other.single 3600) # rules on decrypted traffic pass in quick on enc0 from 192.168.28.28 to 192.168.42.10 port 993 keep state block in quick on enc0 All in all: - the bpf view is different from the pf view - the inbound pf view is different from outbound Should pf even see the inbound ipencap traffic? Nothing much that can be done with it, that cannot also be done on the physical interfaces... Shouldn't enc just carry the unencrypted/unencapsulated traffic like the manpage says? That would make it behave far more like a "normal" interface. -- Cam
Re: Failover with carp and pfsync issue
I see one possible flaw in your setup:
On Fri, 17 Nov 2006, Dominique Goncalves wrote:
> fw1:
> pf.conf:
> scrub in all
> nat on fxp0 from !(fxp0) to any -> (fxp0)
> pass quick on vr0 proto pfsync
Your pfsync interface is vr1, not vr0. I tend to use "set skip" for the
pfsync interface.
> pass quick on { fxp0 , vr1 } proto carp
So here vr1 should be vr0.
> pass all keep state
But you pass everything anyway, so I'm not sure it will fix your problem.
--
Cam
Re: router wont stop sending icmp redirects
On Thu, 16 Nov 2006, Andrew Smith wrote: > net.inet.ip.redirect = 0 > > Means that the machine will not "honour" redirects. > > The value is used to ignore redirects sent by routers not to disable sending > of redirects if you happen to be running as a router. No, you're talking about net.inet.icmp.rediraccept net.inet.ip.redirect should be the right button to control the sending of icmp redirects.
Re: ftp-proxy issues
On Tue, 14 Nov 2006, Camiel Dobbelaar wrote:
> On Tue, 14 Nov 2006, Marc Peters wrote:
> > > What I wanted to say: notice how failinghost shrinks the TCP window to
> > > just
> > > 46 bytes ("win 46"). That's not enough to fit the long path of the
> > > directory change, so that stays in the network buffers of the firewall
> > > waiting for failinghost to send an ACK with a bigger window size ("opening
> > > up the window").
> > >
> > > Looks like failinghost is responsible for the stalled TCP connection.
> >
> > but i wonder, why it is working from the firewall-host (without proxy),
> > from a
> > host in the dmz or if i bypass ftp-proxy from the internal lan.
>
> Yes, I wonder about that as well.
>
> Can you tcpdump those working connections to failinghost?
For the archives.
It turns out that failinghost negotiated window scaling (wscale 7) during
the threeway handshake. So the windowsize of 46 was actually (46 << 7)
=> 5888 bytes.
However, state on this connection was not created on the initial SYN
packet so pf missed the windowscaling option as well.
So the fix was to add a proper keep state rule to pf.conf that created
state on the SYN packet.
Changes went into -current lately to prevent exactly this type of
problem. From OpenBSD 4.1 on, "keep state flags S/SA" will be the
default:
[EMAIL PROTECTED] $ echo "pass all" | pfctl -nvf -
pass all flags S/SA keep state
Re: ftp-proxy issues
On Tue, 14 Nov 2006, Marc Peters wrote:
> > What I wanted to say: notice how failinghost shrinks the TCP window to just
> > 46 bytes ("win 46"). That's not enough to fit the long path of the
> > directory change, so that stays in the network buffers of the firewall
> > waiting for failinghost to send an ACK with a bigger window size ("opening
> > up the window").
> >
> > Looks like failinghost is responsible for the stalled TCP connection.
>
> but i wonder, why it is working from the firewall-host (without proxy), from a
> host in the dmz or if i bypass ftp-proxy from the internal lan.
Yes, I wonder about that as well.
Can you tcpdump those working connections to failinghost?
Re: ftp-proxy issues
On Mon, 13 Nov 2006, Camiel Dobbelaar wrote:
> Ok, I think I found something in your original tcpdump:
>
> Nov 11 15:15:04.389556 failinghost.domain.com.ftp >
> ftp-proxy.domain.com.48293: P 202:233(31) ack 56 win 46
^^
> (DF) [tos 0x10]
>: 4510 0053 7066 4000 4006 0292 c2f5 20b4 [EMAIL PROTECTED]@...C5 B4
>0010: c2f5 20fe 0015 bca5 48d1 b99c bc2d 18c1 C5 C>..B0020: 8018 002e b0fa 0101 080a 0a4a e6fd B0C:...JC&C=
>0030: d86c 040d 3235 3720 222f 2220 6973 2063 C l..257 "/" is c
>0040: 7572 7265 6e74 2064 6972 6563 746f 7279 urrent directory
>0050: 2e0d
Whoops, and then pine dumped core on me.
What I wanted to say: notice how failinghost shrinks the TCP window to
just 46 bytes ("win 46"). That's not enough to fit the long path of the
directory change, so that stays in the network buffers of the firewall
waiting for failinghost to send an ACK with a bigger window size
("opening up the window").
Looks like failinghost is responsible for the stalled TCP connection.
--
Cam
Re: ftp-proxy issues
Ok, I think I found something in your original tcpdump: Nov 11 15:15:04.389556 failinghost.domain.com.ftp > ftp-proxy.domain.com.48293: P 202:233(31) ack 56 win 46 (DF) [tos 0x10] : 4510 0053 7066 4000 4006 0292 c2f5 20b4 [EMAIL PROTECTED]@...C5 B4 0010: c2f5 20fe 0015 bca5 48d1 b99c bc2d 18c1 C5 C>..B
Re: ftp-proxy issues
On Mon, 13 Nov 2006, Marc Peters wrote: > 60 seconds, and the client gives me this message: > 421 Service not available, remote server timed out. Connection closed (mac osx > command line ftp-client) > > That CWD line did not pass out on the DMZ interface? > > > > no it didn't. it is everytime the same, that CWD line didn't pass the dmz > interface and so the server didn't recieve the command. Because ftp-proxy can log the line, it has completely received it and will try to pass it out again. I can think of two things that may happen: (1) it's getting blocked (check pflog) (2) libevent may be holding it (can you try setting "export EVENT_NOKQUEUE=1" and restart ftp-proxy from that shell? "top" should report "select" instead of "kqueue" in the WAIT column) What happens if you remove the rdr for ftp-proxy? Does the control (port 21) connection work ok then?
Re: Passive FTP support on a workstation running PF
The "user" and "group" features of pf are useful for this.
See also:
http://marc.theaimsgroup.com/?l=openbsd-misc&m=115202430208726&w=2
On Thu, 21 Sep 2006, Tom Fitzhenry wrote:
> Hi,
>
> I'm going to university in one week and the university explicitly says
> that only one computer (including hardware routers/firewalls) may be
> connected to their network; hence, I must run PF on my workstation.
>
> I'm running default deny for both outgoing and incoming packets.
>
> The problem is that PF cannot determine which port is going to be used
> as the data port for the FTP transfer (i.e. which port has been
> negotiated by my FTP client, ftp, and the servers FTP server).
>
> I know ftp-proxy is used usually for firewalls, but ftp-proxy doesn't
> allow me to do something such as:
> rdr proto tcp from 127.0.0.1 to any port ftp -> 127.0.0.1 port 8021
>
> The solution I've used is to just open all ports from porthifirst to
> porthilast for outgoing connections, but I'd much rather only the
> needed port is opened.
>
> I know iptables solves this by reading the PORT verb and determining
> which port is going to be used for data transfer.
>
> Does anybody know of any solution I can use on OpenBSD which only
> requires the required port being opened for outgoing connections?
>
> Tom
>
> PS. Here's my pf.conf:
> #
> # --- MACROS ---
> #
> ext_if="nfe0"
> int_if="lo0"
> tcp_services = "{ ssh, smtp, domain, www, pop3, auth, pop3s, 6667, 443,
> 21 }"
> udp_services = "{ domain }"
> icmp_types="echoreq"
> ftp_ports = "{ 4 >< 65535 }"
>
> #
> # --- OPTIONS ---
> #
> set block-policy drop
> set loginterface $ext_if
> set skip on lo0
>
> #
> # --- TRAFFIC NORMALIZATION ---
> #
> scrub in all
>
> #
> # --- TRANSLATION ---
> #
>
> #
> # --- FILTERING ---
> #
> block log all
>
> antispoof for $ext_if
> antispoof for $int_if
>
> pass out proto tcp to any port $tcp_services modulate state
> pass proto udp to any port $udp_services keep state
>
> # For outgoing pings
> pass out inet proto icmp all icmp-type $icmp_types keep state
>
> # For FTP
> pass out proto tcp to any port $ftp_ports keep state
Re: ftp-proxy
On Thu, 14 Sep 2006, Steve Welham wrote: > I agree with you and I think the man page is missing a line - at least > for passive mode which is all that I tested (running ftp-proxy with no > options) . It does appear that 2 translation rules are added for PASV - > an rdr and a nat: > > It looks like that rdr rule is added in order to achieve the port > rewriting noted in the code comments: > * 3) Source and destination ports are rewritten to minimize > * port collisions, to aid security (some systems pick weak > * ports) or to satisfy RFC requirements (source port 20). > > I think this is explained when you consider the 4 rules together, so for > my test: > > 1) Inbound translation: > Packet: "192.168.0.10 to A.B.C.D:57239" > Action: rdr matches and packet becomes "192.168.0.10 to A.B.C.D:26703" > > 2) Inbound filter: > Packet: "192.168.0.10 to A.B.C.D:26703" > Action: Matches first filter rule. > > 3) Outbound translation... matches the NAT rule > > 4) Outbound filter... matches the 2nd filter rule > > HTH, my understanding is a lot clearer if this is all correct. Hopefully > someone else can confirm. Yes, all correct. The rules in the manpage are very much simplified, to clarify what the proxy does. Listing the exact rules with the port rewriting would make them a lot more complicated (ie. not suitable for a manpage). -- Cam
Re: Tuning OpenBSD network throughput
On Tue, 8 Aug 2006, Matthew R. Dempsky wrote: > Then, I substituted out the 266MHz machine and replaced it with the > 600MHz machine (i.e., faster processor, more ram, and better software), > but running ``iperf -c 192.168.10.1'' under OpenBSD reported a mere > 3.8 Mbits/sec---nearly two orders of magnitude less! > > Can anyone explain the huge discrepancy here? Can I do anything to get > OpenBSD to achieve at least 150 Mbits/sec? I never got any meaningful numbers out of iperf v2.x either, v1 works better.
Re: ftp-proxy problem on firewall
On Thu, 13 Jul 2006, Jure Zbontar wrote: > I think the problem might be that ftp traffic from my firewall machine > doesn't go through the proxy at all, so ftp-proxy doesn't create any > rules for it. That's right, you cannot rdr to the proxy on the firewall itself. See also this thread: http://marc.theaimsgroup.com/?l=openbsd-misc&m=115201928525375&w=2
Re: Redirect to ftp-proxy when client is on localhost?
On Tue, 4 Jul 2006, [EMAIL PROTECTED] wrote: > I like the 3.9 ftp-proxy so much I'm thinking "wouldn't it be nice if, > in addition to the clients inside my lan, ftp connections from this very > openbsd machine went through it also". > > Is this just a silly idea? Is this possible, trivial, tricky? Done > before? I don't think it can be reliably done. It would only be possible if pf(4) supported rdr on outbound packets, which it does not (which is a good thing IMHO; it would create far more problems then it would solve). To use FTP on the local machine rules like below will be prove far more robust (note the "group staff", adjust as needed): pass in on $ext_if from any to $ext_if port > 49151 group staff keep state pass out on $ext_if from $ext_if to any port > 1023 group staff keep state That does not enforce that the FTP protocol is used, but hey, a machine firewalling for a local lan can not have that many untrusted ftp'ing users now can it? :-) -- Cam
Re: ftp-proxy does not work in secure level 2
On Mon, 3 Jul 2006, c.s.r.c.murthy wrote: > We have configured a firewall with pf on openbsd-3.9. It is found that > ftp-proxy is unable to operate when system is put in secure level 2. > This is due to the fact that ftp-proxy can't add/delete rules in pf in > secure level 2. But for security reasons we would like to have the > system running in secure level 2. Is there a soultion to have the > ftp-proxy working in secure level 2? I don't think so. Securelevel 2 makes sure that userland can no longer modify pf rules. ftp-proxy is a userland program that modifies pf rules... both work that way by design. Those are clearly opposites so it's not something that can be fixed, short of changing the design. I'll add this to the CAVEATS section of the ftp-proxy manpage. -- Cam
Re: ftp-proxy and bridge
On Thu, 22 Jun 2006, Dylan Martin wrote: > Hi, I've got a bridge firewall protecting some FTP servers. In the > past I've used ftpsesame to let people on the internet use passive > connections to my FTP servers. I hear that ftp-proxy in 3.9 is > supposed to have the functionality of ftpsesame, so I'm trying to > figure out how to make that work. No, they're not equivalent. See http://marc.theaimsgroup.com/?l=openbsd-pf&m=112172929023243&w=2 In short, keep using ftpsesame for bridges. > >From looking at the man page, it looks like I redirect new ftp > connections to ftp-proxy, and "-R ip-addr" tells it how to behave. My > problem is that I have two FTP servers. Can I run two instances of > ftp-proxy without them clobbering eachother? That seams like the > answer, but I'm nervous they'll screw up eachother's rules in the > anchors. It was designed to allow exactly that. If you run "pfctl -sA -vv" you can see the sub-anchors that look like this (must have active FTP sessions): [EMAIL PROTECTED]:/home/camield $ sudo pfctl -sA -vv ftp-proxy ftp-proxy/18669.23768 The first number is the pid of the ftp-proxy that created that sub-anchor, the second is the session id (which you can match to the # number in the logging): Jun 23 07:41:53 qbert ftp-proxy[18669]: #23768 passive: client to server port 42708 via port 65144 So, you can run as many simultaneous proxies as you want. -- Cam
Re: state table, loopback and redirection
On Thu, 8 Jun 2006, sheda wrote: > There's a NAT box between the OpenBSD box and Internet, that's why I don't > need outgoing NAT rules. Then the ftp-proxy needs to run on the NAT box, because the private space address is used _inside_ the FTP protocol as well (in active mode). For bridges "ftpsesame" may be what you're looking for: http://www.sentia.org/projects/ftpsesame -- Cam
Re: state table, loopback and redirection
On Thu, 8 Jun 2006, uc.sheda wrote: > When 172.16.218.129 is trying to reach the port 21/tcp of 129.128.5.191, > here is what happen: > > * tcpdump -tei pflog0 port 21 or 8021: don't show anything You don't have "log" on your "rdr pass" line. > * tcpdump -tni bridge0 port 21 or 8021: just show the SYN coming from > 172.16.218.129, > nothing else. > * pfctl -ss show 2 states: >all tcp 127.0.0.1:8021 <- 129.128.5.191:21 <- 172.16.218.129:22585 >CLOSED:SYN_SENT >all tcp 172.16.218.129:22585 -> 127.0.0.1:8021 SYN_SENT:CLOSED > * netstat -anp tcp show that ftp-proxy is listening on 127.0.0.1:8021 but > don't > receive anything (no socket in a state !=LISTEN with port 8021). > > Is there something I'm missing? What is the exact meaning of the arrows seen > in the > pfctl -ss output? You can't connect to the internet with a private space (172.16) address. -- Cam
Re: pftpx
On Fri, 26 May 2006, Gaby vanhegan wrote: > I see. What about running them on separate IP addresses (both still > on the same machine)? Or do they need to be on different physical > interfaces? Should I use a separate package, such as ftpsesame? Is > there any way round this problem? Using rules with "user" and/or "group" is the only robust solution to this problem. ftpsesame may work but is raceable, especially if you run it on the same machine as the server. With raceable I mean that it may add a pass rule too late. (but if you only need it to make passive mode work, it's probably alright: the clients on the internet don't react that fast) > I'm curious though, what prevents them from being run on the same > machine? The NAT rules that ftp-proxy adds to the anchors don't work properly in this case. -- Cam
Re: pftpx
On Fri, 26 May 2006, Gaby vanhegan wrote: > When I type the ls command. is the same in each case, the > firewall, proxy and ftp server are running on the same machine. My > aim here is to not open a load of ports for ftpd, but to have the > pftpx part of ftp-proxy only open the ports on demand. Ah right, running the proxy and server on the same machine is not supported. What about using a rule like this (note the "group"): pass in on $ext_if from any to $ext_if port > 49151 group ftpusers
Re: pftpx
On Thu, 25 May 2006, Gaby vanhegan wrote: > Is there a working pf.conf that anyone can share with me? I can > connect to the server but PASV mode fails with the normal error that > it can't make the data connection. You have to run two instances of the proxy. One as normal that listens on the default port 8021 that your internal clients can use. And another one that you will force to one server. We'll pick port 8022 for this one, fill in $int_server_ip yourself: ftp-proxy -p 8022 -R $int_server_ip Then it the redirect section: rdr pass on $ext_if from any to $ext_server_ip port 21 -> 127.0.0.1 port 8022 -- Cam
Re: ftp-proxy isssues
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote:
> > pass in on $ext_if inet proto tcp from any \
> > to $ext_if port 55000 >< 57000 user proxy \
> > flags S/SA keep state
>
> C>You don't need this anymore.
>
> Ah, okay, how come i don't need this anymore, i must be missing and not
> understanding the matters properly.
You don't need it, because the proxy takes care of _all_ data connections
itself now, using the anchors. Your only job is to pass the control (port
21) connections, ftp-proxy takes care of the rest.
> C>Since you know about the anchors and therefore that ftp-proxy has
> C>changed
> C>I must ask: which documentation did you follow and what was unclear?
> C>Maybe that needs fixing.
>
> The page that triggered me was this one:
>
> http://www.openbsd.org/39.html
> "ftp-proxy has been rewritten, and a tftp version, tftp-proxy, has been
> added"
>
> Then i clicked to this link:
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=ftp-proxy&sektion=8
> The man page of ftp-proxy.
That was the right thing to do.
> Unclear from the man page was that i don't need the pass in's anymore as
> you mentioned before, i still don't understand why.
That should have become clear after the reading the DESCRIPTION section of
the man page. Can you read that again and tell me what might be
clarified?
> I also clicked on the pf.conf man page:
> http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current
>
>
> In the anchor section i saw this:
>
> ext_if = "kue0"
>block on $ext_if all
>anchor spam
>pass out on $ext_if all keep state
>pass in on $ext_if proto tcp from any \
> to $ext_if port smtp keep state
>
> Okay, but then, which rules fall under the anchor section spam and which
> don't, it would be more clear like this:
>
> ext_if = "kue0"
>block on $ext_if all
>anchor spam {
>pass out on $ext_if all keep state
>pass in on $ext_if proto tcp from any \
> to $ext_if port smtp keep state }
>
> That way i'd know that both two pass rules belongs to the anchor spam, but
> in the example i cannot conclude that.
No, those last two rules are not loaded into the anchor, you got that
wrong. Loading rules into an anchor can be done with the pfctl -a switch,
or with the "load anchor" statement in pf.conf. The ANCHORS section in
pf.conf(4) should make it clear.
> This longer example uses both a NAT and a redirection. The external
> in-terface has the address 157.161.48.183. On localhost, we are running
> ftp-proxy(8), waiting for FTP sessions to be redirected to it. The three
> mandatory anchors for ftp-proxy(8) are omitted from this example; see the
> ftp-proxy(8) manpage."
>
> Forgive the layout, i know it's a mess
> Here the three mandatory anchors are also mentioned, but i thought that the
> examples would lead to an error in my case because with the last anchor i
> would have no pass rule like this from the ftp-proxy man page:
Ok, pf.conf redirected you to ftp-proxy(8) again, which is good.
> "anchor "ftp-proxy/*"
>pass out proto tcp from $proxy to any port 21 keep state"
>
> I thought that with an anchor i would also need a rule attached to it.
Nope, as explained above, that's not how anchors work.
I think the only thing you missed that might have made things easier was
the upgrade document for 3.9 which Nick already pointed out:
http://www.openbsd.org/faq/upgrade39.html
But I think it's reasonable to expect people to read it, as it is
referenced from the release announcement.
--
Cam
Re: ftp-proxy isssues
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote: > rdr on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021 You need this. > pass in on $ext_if inet proto tcp from any \ > to $ext_if port 55000 >< 57000 user proxy \ > flags S/SA keep state You don't need this anymore. > How can i transform all this into the anchor stuff? > All rules within one anchor?? Since bracets aren't used in any example, how > do i know which rules are in an anchor and which aren't? > How to fit the pass in in the anchor? You just put the three anchors in pf.conf, literally: nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" anchor "ftp-proxy/*" It's the proxy's job to load rules in them, on the fly. > I don't need a pass out rule, since this is implicitly the case by the > floating policy and pass out statement i wouldnt need a anchor > "ftp-proxy/*" statement at all The manpage explicitly says that all anchors are mandatory. > this is how i understand it, seperate connections, not natting or > redirecting connections, because that wouldn't be proxying at all. > Or maybe it's not proxyied, i just don't know. It proxies the control connection, but not the data connections. Since you know about the anchors and therefore that ftp-proxy has changed I must ask: which documentation did you follow and what was unclear? Maybe that needs fixing. -- Cam
Re: FTP Issues
On Fri, 24 Mar 2006, Hutger H. wrote: > - Analysing the firewall's traffic, I could notice that the problem > happens when the FTP server try to make a new connection back to the > client using I high port. I got some tutorials explaining how to solve > this problem using ftp-proxy and some PF rules/rdr, but none of the them > seem to work for me. ftp-proxy has changed in 3.9, and your tutorial applies to the old one. See the configuration section in the ftp-proxy(8) manpage. (you need to setup a few anchors) -- Cam
Re: 3.8 bridge trouble
On Wed, 15 Feb 2006, Pailloncy Jean-Gerard wrote: > Second part of the test, I set up a bridgename.bridge0 file with the 2 nics up > with STP, and I restart the soekris. Few seconds after the end of the boot > (login prompt) immediate reboot of the soekris. > I stop it by, as soon as login prompt appears, to log in and put down the > bridge. > > In fact sometimes when there is a big storm the soekris reboots too. Is the watchdog timer (sysctl kern.watchdog) set? I've seen Soekrises reboot because of that when under high network load. -- Cam
Re: MAC filter Bridge
On Wed, 1 Feb 2006, Badbanchi Hossein wrote: > What is bothering me is the sentence: > Rules are processed in the order in which they were added to the interface, > and the first rule matched takes the action ... > > Does this really mean that no hash function is used? I mean if I have 2 > MAC Addresses and want to check **each packet** against this list serially, > I suppose I had better forget about it! Yes, that's correct. The bridge MAC address rules are implemented using a SIMPLEQ (list). The bridge routecache is hash based though. An alternative approach might be to turn off learning and discovery on the interface and add MAC addresses that are allowed to communicate statically. That way the bridge never sends traffic to unknown addresses. (the incoming traffic is still processed though, so the approach is a bit limited).
Re: Stripping vlan tag - libpcap and tcpdump - arpwatch on trunk
On Thu, 5 Jan 2006, Raphael wrote: > * My first try was to run one instance of arpwatch per configured > virtual vlan interface. This worked fine for up to 10 sessions, but not > more (maybe the amount of concurrent libpcap sessions is limited?). > Q: Is this a configurable parameter? >From man bpf(4): A separate device file is required for each minor device. If a file is in use, the open will fail and errno will be set to EBUSY. The number of open files can be increased by creating additional device nodes with the MAKEDEV(8) script. So: cd /dev && ./MAKEDEV bpf10 etc. -- Cam
Re: VLANs not isolated
On Thu, 24 Nov 2005, Jason Dixon wrote: > I'm testing PF on a proposed network design and experiencing some unexpected > behavior. With three vlan(4) interfaces on the interior of an OpenBSD > gateway, each of the clients on a segment is able to ping the gateway address > for at least one of the other VLAN gateways. I'm not sure whether this is a > bug with OpenBSD or my switch. I wouldn't be surprised that it's the fault of > this Dell PowerConnect 3024, but I'm still wondering why OpenBSD honors the > tagged packet on the wrong vlan(4) interface. I know the Dell PowerConnects > are crap, but it's what I have in my home for testing. The production network > will be running Catalyst 2950s. > > The clients are all connected to untagged VLAN ports on the switch. The > OpenBSD gateway is plugged into a port tagged with all 3 VLANs. > > vlan0: flags=8843 mtu 1500 >lladdr 00:d0:b7:bf:c6:95 >vlan: 2 parent interface: fxp0 >groups: vlan >inet6 fe80::2d0:b7ff:febf:c695%vlan0 prefixlen 64 scopeid 0x8 >inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > vlan1: flags=8843 mtu 1500 >lladdr 00:d0:b7:bf:c6:95 >vlan: 3 parent interface: fxp0 >groups: vlan >inet6 fe80::2d0:b7ff:febf:c695%vlan1 prefixlen 64 scopeid 0x9 >inet 10.10.10.1 netmask 0xff00 broadcast 10.10.10.255 > vlan2: flags=8843 mtu 1500 >lladdr 00:d0:b7:bf:c6:95 >vlan: 4 parent interface: fxp0 >groups: vlan >inet6 fe80::2d0:b7ff:febf:c695%vlan2 prefixlen 64 scopeid 0xa >inet 10.20.20.1 netmask 0xff00 broadcast 10.20.20.255 > > == > Test Summary > == > Client 10.0.0.50 > can ping 10.0.0.1 > can not ping 10.10.10.1 > can ping 10.20.20.1 > > Client 10.10.10.50 > can ping 10.0.0.1 > can ping 10.10.10.1 > can ping 10.20.20.1 > > Client 10.20.20.50 > can not ping 10.0.0.1 > can ping 10.10.10.1 > can ping 10.20.20.1 Your clients have the OpenBSD system as their gateway right? I think it's normal for a multi-homed BSD system to accept traffic for all it's IP addresses (even with forwarding turned off). That does not explain why some of your ping tests fail though. -- Cam
Re: bridge and Spanning Tree, WAS Re: Help with bridging firewall failover w/ CARP, OpenBSD 3.7
On Sun, 20 Nov 2005, Ramsey Tantawi wrote: > I set up failover of two redundant bridging firewalls using the > Spanning Tree Protocol options in bridge, and it worked great. > > However, when testing failover, it takes between 45 seconds to more > than 3 minutes for traffic to start flowing again. The interfaces > themselves change state in the expected timeframe, though. The entire > network is unmanged switches, and my guess is that the delay is due to > waiting for all the ARP caches to clear. Does this sound reasonable? Definitely the MAC (not ARP) caches of the bridges and the switches. STP devices can help speed up transitions by timing out entries sooner when a topology change is detected. I'm not sure if the OpenBSD bridge does that, the unmanaged switches definitely don't. In this case you'd be better off with hubs... > To help, I set the bridge cache to flush every 20 seconds instead of > the default 240. It seems to help somewhat. I'm concerned though--is > this too frequent? With a two port bridge it won't really hurt. -- Cam
Re: Help with bridging firewall failover w/ CARP, OpenBSD 3.7
On Sat, 19 Nov 2005, Ramsey Tantawi wrote: > > For a redundant bridge setup you need spanning tree. See "stp" in the > > brconfig(8) manpage. > > I'm using unmanaged switches that don't support STP, so for now I'm out of > luck. No, that's ok. You don't have to run STP on every device, only on the ones that might otherwise be able to create a loop.
Re: Help with bridging firewall failover w/ CARP, OpenBSD 3.7
On Fri, 18 Nov 2005, Ramsey Tantawi wrote: > I can't get failover of a bridging firewall to work using CARP and OpenBSD > 3.7. > > All the documentation + googling I've done leads me to believe it > *should* work. I think. But with everything setup all I get is a > flood of ARP requests that paralyze the network and the firewalls. Carp is meant to fail over addresses, not interfaces. For a redundant bridge setup you need spanning tree. See "stp" in the brconfig(8) manpage. -- Cam
Re: ftp-proxy upgrade instructions
On Wed, 16 Nov 2005, Moritz Grimm wrote: > Moritz Grimm wrote: > > Using the parameter ``-q "(q_med, q_pri)"'' does not result in any error > > message, however, I have no proof whether this works or not. Actually, > [...] > > Hm, and while I'm at it ... how can things like these be properly tested and > > debugged in the first place? Other than making educated guesses with > [...] > > Replying to myself here ... I found out that I can get the rules inserted by > ftp-proxy with > > pfctl -a ftp-proxy/x.y -vvsr > > and it looks like the queue statements were accepted. However, the ACKs > definitely don't end up in q_pri but my default queue (q_def). I compared that > to what happens when i use "-q q_low", and indeed, everything ends up there > with only one queue name as the argument. > > Now I'm just a bit confused, but at least I know that maybe, in theory, it > could work the way I want. :-) Your testing is correct. ftp-proxy does not understand the queue() syntax like pfctl does, so only one queue name for now. -- Cam
Re: inetd and netstat with parameters
netstat is already taken. [EMAIL PROTECTED] $ grep netstat /etc/services netstat 15/tcp On Fri, 24 Jun 2005, Karl-Heinz Wild wrote: > I try the following > > /etc/services > > netstat /tcp > > /etc/inetd > > netstat stream tcp nowait root/usr/bin/netstat netstat -natafinet > > $ nc localhost > > but I can get any result. > > then i tried starting inetd -d to get some infos > where the problem could be, but no result. > > My question is how to get this work or how to > debug. > > thanks > regards > Karl-Heinz
Re: spamd greylisting and server pools
On Tue, 21 Jun 2005, Heinrich Rebehn wrote:
> If a mail is sent via a server pool, it can take quite long until it happens
> to be sent 3 times from the same ip address and thus get whitelisted and
> delivered. With a big server pool this can take hours.
I use the attached very simple script to help spamd a little. Also
available at http://www.sentia.org/downloads/greyhelp.pl
This is just a work-around ofcourse, there were also patches to spamd to
whitelist entire /24's at a time on tech@ if I recall correctly.
--
Cam
#!/usr/bin/perl -w
#
# greyhelp scans the grey entries in the spamd database. If a
# sender/recipient tuple is tried from 3 (configurable) or more IP addresses
# in the same /24 network, then all the IP addresses are whitelisted. This
# helps receiving mail from providers with big SMTP server farms.
#
# Schedule this script in the _spamd crontab, every 15 mins.
#
use strict;
my $SPAMDB = "/usr/sbin/spamdb";
my $THRESH = shift || 3;
my %H;
open(FH, "$SPAMDB |") or die "cannot run spamdb: $!\n";
while () {
next unless m/^GREY/o;
my (undef, $ip, $from, $to) = split /:/;
# The sender/recipient tuple.
my $tuple = "$from - $to";
# /24 of the IP address.
my $net24 = $ip;
$net24 =~ s/\.\d+$//;
$H{$tuple}{$net24}{$ip}++;
}
close(FH);
foreach my $tuple (keys %H) {
foreach my $net24 (keys %{$H{$tuple}}) {
if (scalar keys %{$H{$tuple}{$net24}} >= $THRESH) {
# print "$tuple -- $net24/24\n";
foreach my $ip (keys %{$H{$tuple}{$net24}}) {
# print "\t$ip\n";
print `spamdb -a $ip`;
}
}
}
}
