On 05Apr2013 11:34, Daniel Hartmeier <dan...@benzedrine.cx> wrote: | On Fri, Apr 05, 2013 at 07:03:52PM +1100, Cameron Simpson wrote: | > I was imagining NATing on an internal virtual interface to a private | > address on some kind of internal virtual interface; this might keep | > the necessary state without being the outmost layer. | > And then to do stateless filtering of RSTs on the real physical | > external interface [...] | | I guess you have already considered the obvious solution of adding a | second device (stateless filtering bridge) justs to drop the RSTs.
Yes, but I have failed utterly to make it work. I have an OpenBSD 5.1 VM on my mac for trying these things and can't even construct what I think might be needed, so clearly I do not properly understand the vether, vlan and bridge devices (not least because I don't understand why I get the errors I do). I was thinking something like: if_sat:br0:vether0 to do some stateless filtering, and: vether1:br1:if_lan to do the NAT etc in a conventional fashion. However, I don't know how to interconnect vether0 and vether1 to pass packets between them (to get the flow to be if_sat>vether0>vether1>if_lan) so as to get two runs through PF, and in fact I get errors trying to attach a vether to a br device. My reading of the vlan man page suggests it is not what I want; it seems to be a packet encapsulation, not a local virtual network. I'll try to reproduce these errors so people can point fingers at my conceptual errors. | While it may seem a waste of parts and electricity, it's much simpler | than trying to route a connection through the same device multiple | times. | | Is it a router or a bridge now? It is a router. | If a router, you'd probably have to use rtables to trick the stack, | see | | http://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/ I think I read this while researching a week ago; it didn't seem to address what I though I needed. I'll give it a reread. I gather I need to rebuild the kernel to have multiple routing tables, yes? The installed build seems to only have table 0 (based on errors from the "route" command when I say "-T 1" at it). | If you have two spare physical interfaces, a patch cable between them | would be simple and produces non-surprising interaction with pf. Alas, I do not. My setup is actually more complicated. The firewall has two external interfaces: one to the satellite and one to a 3G modem. (The sat has a bigger quota and in principle higher throughput; the 3G is low latency). We route DNS and ssh over the 3G (for low latency) and a few other things (for reliability, given this RST issue I'm trying to work around) - mostly POP, IMAP, SMTP. Everything else goes over the satellite. Can I use "route-to" witjout state? I think it should be ok but haven't tried that. We think web browsers hide a lot of the RSTs on their port 80 connections by retrying, but that SSL and other tools like iTunes and some mail clients are pretty intolerant. Given the app errors we see. | > | However, you can filter statelessly on the internal interface (the | > | states won't match there (wrong direction, if-bound), dropping outgoing | > | TCP RST, passing everything else. | > | > Won't the RST packets shut down the TCP states as they traverse to | > external interface? | | The RST packets will cause the state entries to show up in pfctl -ss | as TIME_WAIT:TIME_WAIT, but that doesn't make them not match further | packets. So the firewall won't start sending RSTs back up the line to the remote server? That would be bad:-) | The only effect is that the entries will time out (when idle!) with | tcp.closed (90s by default) instead of tcp.established (24 hours). | | You can increase tcp.closed, the downside is that the entries will | stay around longer, even you'd want them to be purged. Hmm, ok. That sounds promising. I don't really mind keeping states around longer if I've got the memory and don't run out of ports for NAT. I'll put some time into your suggestion of reworking the rules to be stateless on the LAN interface and see how that plays out. If it works it is far simpler than making bridges and virtual networks. Thanks, -- Cameron Simpson <c...@zip.com.au> I am here by the will of the people ... and I will not leave until I get my raincoat back. - Richard Kadrey, _Metrophage_
