Allow LAN -> OPT, not reverse

  • This doesn't seem possible, at least not from the GUI, but I may be missing something.

    I have LAN, OPT and WAN interfaces, standard setup with NAT on WAN.  LAN is, OPT is

    I want to be able to initiate connections from LAN to OPT (and have OPT respond), but not have OPT establish connections to LAN first.

    Basically, I want to put devices with web management interfaces in OPT and manage them from LAN, but not allow hosts in OPT to connect to anything in LAN.  And just blocking/allowing specific addresses won't help – I may need to contact any arbitrary OPT host from LAN.

  • you only need one additional rule at opt (give that the defalut lan to any rule is still present):
    at opt interface create one rule "pass proto any, source opt subnet, destination NOT lan subnet".
    This way your opt clients can go anwhere except LAN. Make sure there is no other rule below this one that is allowing access.

    Another way to do it is to have first a
    "block proto any, source any, destination lan subnet" at opt and a
    "pass proto any, source opt subnet, destination any" below that.

  • Well, that's what I thought I was supposed to do, but it didn't seem to work when I tried it last night.  It appeared to break everything, but I just tried it again and it works just fine, at least for ICMP.  I must have been too tired to see clearly the first time.

    Now to figure out how to get 3, preferrably 4, interfaces on my single-LAN Mini-ITX.  I added a PCI Ethernet to my production firewall for the second interface.  I thought the simplest, cheapest thing to do was use USB-Ethernet adapters, but neither a Linksys or D-Link would work on the ITX, though the D-Link works fine on the big PC I was using to test these rules.

  • I don't recommend using USB nics and you should be aware that those most likely won't be supported by altq so you don't have no trafficshaper support on these but I'm using a pair of these at a platform with limited other bus systems: . They use the aue-driver. Also USB-nics don't offer good performance.

  • Thanks for those tips.  I had looked for that Belkin the other day in stores nearby but couldn't find it.  Found a different Belkin but it wasn't on the HCL, so I passed it up.

    I see that one is USB 1.1.  I may need to try it; the two I had trouble with on the EPIA 5000 were both 2.0.  Both gave an error message on boot.  On the full-size PC which has 2.0 ports they use the axe driver.  Though I don't recall specifically what the error was, it seemed to have something to do with timing.

    Throughput doesn't bother me much.  I would not use them for significant LAN-LAN traffic.  Most LAN-LAN is via a back-end gigabit switches, not through the firewall and my broadband WAN is only 6Mbps.  ("Only 6Mbps" – how far we come in half a decade!!)

    The "right" answer it to spring for a dual-LAN ITX and one PCI NIC, but that's $160 plus new memory.  I've not convinced myself it's worth that much ... yet.  Soon to occur, no doubt.

  • Even if you use these "only" for WAN, you won't have traffis chaping with those.

  • That'd be okay.  I'd use them only for 1 or 2 OPT subnets.  And so far, no need for traffic shaping, since it's just for home.

    But I continue leaning further toward the EPIA CL6000 with two LANs, even as we "speak".