Re: Question about IP
Akin Nomad wrote: > Which of these IP addresses you will not find allocated to PC, which > can work in internet through IP protocol? (you can choose only one > variant) > a: 192.168.0.3 > b: 230.30.3.3 > c: 2001:16c8:ffd7::b:33.255.3.2 > d: 2001:16d8:ffd7::405 > e: 10.40.20.0 > f: fe80::2c0:26ff:2001:16d8 > > Variants "a","c" and "d" seems fine to me, but I'm not certain which > of the rest - "e" (IPv4 ending with .0), "b" (IPv4 multicast) and "f" > (IPv6 link-local) - would be most correct answer to this question? It's a bad question (is it a Cisco certification by any chance?) I'm going to split hairs and guess the key word is "allocated" which infers "exclusive". So I'd choose (b), since the address represents a group which would be joined by zero or more hosts. As far as I can tell all of the other addresses are valid unicast. Weak question = Weak answer.
Re: Crash Report - Desired Info "Quality"?
>> Would this be acceptable for filing a crash report, or is this out of >> your scope? > > If you can type in the text, that should be fine. Don't expect multiple > developers to try and make head or tail of a .jpg though... > > As mentioned here recently, if the machine is rebooted rather than > power-cycled (type 'boot r' at ddb> prompt after tr/ps) you might find > the information still available in dmesg. (If you want to test whether > this is likely to work before asking someone to type things, reboot > yourself and see if you get two sets of startup messages displayed in > dmesg). > > Also a useful way to get textual screen output is to setup your system to use a serial console rather than VGA. Then provided you have another box you can just use your console emulator's copy or save options. http://www.openbsd.org/faq/faq7.html#SerCon SteveW
Re: ftp-proxy
> In the passive modes session, i counted 4 pf rules being added, as > also in the active modes. But reading ftp-proxy(8) i can see the > following reference: > > I.e., two rules for active mode and three for passive mode. I could > not understand what happened to the others listed in the source code. 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: So for PASV ftp to an ftp server at A.B.C.D I get the following # pfctl -a ftp-proxy/6145.2 -sn nat inet proto tcp from 192.168.0.10 to A.B.C.D port = 26703 -> 192.168.1.30 rdr inet proto tcp from 192.168.0.10 to A.B.C.D port = 57239 -> A.B.C.D port 26703 # pfctl -a ftp-proxy/6145.2 -sr pass in quick inet proto tcp from 192.168.0.10 to A.B.C.D port = 26703 flags S/FSRA keep state (max 1) pass out quick inet proto tcp from 192.168.1.30 to A.B.C.D port = 26703 flags S/FSRA keep state (max 1) 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). NB I haven't tested Active. > I could not understand why the first filter rules is necessary, since > after being natted, the proxy address is the only one to been seen by > pf. 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 > > thanks in advance for any clarifications. > HTH, my understanding is a lot clearer if this is all correct. Hopefully someone else can confirm. SteveW
Re: pf table confusion
> I'm stuck on some obvious pf table error but I can't see it.
> ## Tables (File content shown in brackets)
> table file "/etc/tAdmins" ( 192.168.0.3 )
> table file "/etc/tManagers" (192.168.0.2)
> table file "/etc/tOperators" (192.168.0.128)
> table file "/etc/tHttp-managers" (google.com)
> table file "/etc/tHttp-operators" (10.1.0.34)
> table file "/etc/tCustomers" ( )
> table file "/etc/tExtadmin" ( )
Use curly braces {} to define tables.
SteveW
Re: RDR and NAT Combination with a single interface
The painless way to do this is with webservers on non-routable addresses, NAT and two interfaces. Is that out of the question? In any case man pf.conf says: "Redirections cannot reflect packets back through the interface they arrive on, they can only be redirected to hosts connected to different interfaces or to the fire-wall itself." > The main difference is I want to do this with a single interface and I > want to use it as a load balancing solution. Using rdr to redirect > across a pool of web servers and using nat to translate the source > addresses so the addresses appear correct in the httpd logs rather > than having the source address of the interface that redirected the > traffic. All the IP addresses are on routable networks and the "load If your rules worked then I think they would they achieve the opposite of this. The rdr would match on inbound traffic and the nat would match outbound ensure the source address always appeared to be $loadbalancer to the webservers. I have some half-baked ideas on doing this with a single interface in obsd: 1) NAT load-balancing with a loopback adaptor 2) directed routing with pf. ... but neither are as a tidy as a simple NAT load-balancer. SteveW
Re: scrub reassemble tcp and nat causes problems with some sites
>> Get tcpdumps on both router interfaces with and without the "reassemble >> tcp" option. Do this for a similar file on both a working website and >> broken (ebay) website. > > On both router interfaces? Wouldn't the external if be enough? You're probably right. But my theory is that if you're going to go to the effort of getting some comparable captures you may as well get them all at the same time. Having both external and internal is helpful for debugging issues with your router itself - i.e. it would indicate if the packets arrived looking good and then, after pf, looked bad.
Re: Need help with dns/pf/tcpdump
> ns.foo.bar is a dns slave that makes AXFR zone transfer from my server > (mybox). Why is the traffic > blocked on the first lines? What kind of traffic is that? Perhaps I > don't understand DNS fully, > but I thought zone transfers were made using TCP only, and ordinary > queries UDP. Zone transfers are TCP. My guess is that the first 3 lines of the dump refer to a preliminary UDP SOA query. It's not clear from the information you've provided why this is being blocked though. > Here's the relevant part of my pf config: Other bits of pf.conf might be relevant. > # tcpdump -a -e -o -ttt -i pflog0 No need to complicate things - try tcpdump -enttti pflog0 -s 1500 Why? Name resolution might be misleading, OS fingerprint is a guess, and the [|proto] in your captures indicates you're truncating some information. SteveW
Re: scrub reassemble tcp and nat causes problems with some sites
> Unfortunately I cannot determine why only some sites have troubles > and that's why I seeking advice here on howto further diagnose > the problem. > > Any hints are appreciated! It's a stab in the dark but I would start with the assumption that some sites are using server load balancing and that "reassemble tcp" is breaking this somehow. Then I'd try and prove that assumption by looking at the tcpdumps specifically for how "reassemble tcp" changes may be interfering. Get tcpdumps on both router interfaces with and without the "reassemble tcp" option. Do this for a similar file on both a working website and broken (ebay) website. Tips on doing this: - be careful not to filter too much, you might miss an important icmp reply from an interim router - make sure tcpdump's snaplen is big enough to get all the headers - including http - try and replicate the issue with small html files so the packet captures aren't too busy - ensure that each capture sees the tcp handshake and FIN Then load the comparable captures into Ethereal/Wireshark and stare at them until it makes sense :-) Steve
Re: Change MTU size TCP/IP Packets for 'black hole routers' withi n B SD 3.8 possible ?
> so, the ping is ok when its not going trough the tunnel...but via the > tunnel, the MTU size > sinks to 1330 max. > > How to get that not to sink ? You probably can't - your VPN tunnel is adding IP and IPsec headers which cause packets to grow beyond the DSL provider's MTU. (BTW some DSL services may be based on PPPoE which could have an MTU lower than 1500 - I would check with your ISP before setting the modem MTU to something different.) The way to avoid this problem is to send packets over the link that are small enough to avoid exceeding the MTU when they are encapsulated with IPSec. Your main decision is whether you set the packet size at the clients (manually or by ensuring PathMTU is working) or do fragmentation at the router. IMO you should offload fragmentation to the clients by ensuring PathMTU works. So I suggest ensuring that your router interfaces have the correct MTU, check clients are receiving ICMP "packet too big" messages and use the scrub max-mss option in pf. SteveW
Re: To forward, or not to forward
> My goal with the bridge is to filter all traffic coming in from the > outside world, while allowing servers my servers behind the bridge > to connect freely even if their traffic has to travel out to the > router and back(keep state?). > > My point of confusion is whether or not to turn on forwarding. I > have heard arguments for both. I have a transparent bridging firewall setup in the same configuration on 3.8.. IP forwarding is not enabled and the two bridge interfaces pass traffic just fine. Don't enable IP forwarding - you don't need it or want it and it opens up the opportunity for misconfiguration elsewhere to break the security on your admin interface. The bridge interface will take care of all your forwarding needs. IP forwarding is required if you want your box to route IP packets using the routing table - this is not relevant to you because your firewall interfaces do not have IP addresses. Bridging uses a MAC forwarding database to forward Ethernet frames... IP doesn't even come into it.
Re: PF question : set block-policy drop : spoofed ip (NAT'ed) elicits icmp unreachable
> # tcpdump -n -i sis2 'icmp' > 19:21:05.848459 wan_if.ip > external.host: icmp: echo request > 19:21:05.868202 external.host > wan_if.ip: icmp: echo reply > 19:21:05.868499 wan_if.ip > external.host: icmp: host wan_if.ip unreachable > > I was obviously expecting the first two lines but I assumed that PF > would just drop the echo reply and not issue an ICMP host unreachable. The block policy only applies to the "block" rule. In this case the icmp unreachable is matching state since it is corresponding icmp traffic as noted in the PF FAQ http://www.openbsd.org/faq/pf/filter.html#state
Re: Transparent Bridge fail-over?
> I have never setup STP but if you were to use a hub you are only > moving the convegence problem to the devices on the end, be it a > router or clients. Instead of a few next hop mac updates between a > switch and the STP bridges , all the devices would need to update thus > increasing total convergence time. This could be true but I think it depends on the topology and what's trying to be achieved. For instance if you had a simple border network with a pair of bridging firewalls running STP and a hub on either side then the convergence would purely depend on the convergence of STP running on the bridging firewalls - the default timers would put this at 30-50 seconds. Obviously this could break pf state without change to STP or PF options. MAC forwarding tables on the bridges would be updated during the STP learning state. Using dumb switches will introduce delay with forwarding table updates. However if you have intelligent switches that run STP then you can move the failover function to the switches and perhaps take advantage of additional functionality such as Rapid Spanning Tree which might help you close the gap on the speed of a CARP failover. SteveW
Re: Transparent ISP proxy problem or PF problem
> I tried to connect the cable for the internet directly to one > of the client machines behind the firewall (Debian GNU/Linux > 3.1) and the site loads perfectly, so I came to the > conclusion that my PF rules are blocking the packets. So, I > left a minimal PF setup (pass all keep state + NAT), but the > problem remained. When you tried a basic "pass all + nat" ruleset, did you leave in the scrub rule? It's needed to allow NAT on IP fragments. > After some research I found a common problem with very > similar symptoms called Path MTU Discovery problem - the > packets sent from the server are larger than the Path MTU of > the route to the client and with DF flag set, but the server > (or some router) blocks the ICMP messages returned to the > server and does not get notified for the fact that it must > descrease the size of the packages. It does sound like a classic PathMTU problem... but something else might be up because although I can ping the site - with a full 1500B MTU - I can't access port 80. I googled and found something about this site being blocked outside Bulgaria. Also confusing is the fact you can access the server when using a directly connected host (or Freesco). And the proxy complicates things. > Unfortunately it seems that this is not the case. Descreasing > the MTU on the router interface should have fixed the > problem, but no luck. Not always - because the remote server might not listen to your ICMP packet-too-big messages. Often you can get around this by rigging the MSS (MTU-40) in the TCP handshake using the max-mss option to the scrub rule. You might try this and find things start working even though you don't know where the problem is. > Now, what I'm asking here is for some advice on how to > proceed from here in order to diagnose the problem. With any potential MTU issue I always start with something like "ping -vDs 1472 arenabg.com" from various hosts and routers. As you vary the sizes you should receive either an echo-reply or a packet-too-big (confirm with a packet sniffer). If you don't receive any reply you might have found why and where PathMTU is broken. Steve
Re: read-only storage media
Some hard disks have a write protect jumper. I've got an old Seagate Barracuda (ST3217N) that has this - although it's not something I've ever tried to use. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Garman Sent: 01 July 2005 16:06 To: OpenBSD Misc Subject: read-only storage media Is there any kind of storage media that can be set as read-only, and only reset to read and write by physical access? I'm thinking about something like the (seemingly ancient) 3.5" floppy disks that had that little "switch" you could use to set the disk to read only. Are there any hard drives that have a similar kind of feature? I'm thinking that this would be nice for a firewall machine: if the machine was compromised, it still couldn't be modified (i.e., volumes mounted read only can always be remounted read-write if the machine is root compromised). I'm thinking that I could burn a CD-R (and re-burn it whenever there's a configuration change), but it seems like the system might have a lot of latency and the CD-ROM drive might prematurely fail. Any thoughts? Thanks, Matt -- Matt Garman email at: http://raw-sewage.net/index.php?file=email
