Questions on the way to a FreeBSD-DSL-Router-Gateway with PF

G

getopt

␢
First here is the link to pfSense-Wiki so no one should have a need pointing to existing webinterface solutions. If this is what you like, stop reading here and use it! I tried it and still want to have my own thing - period.

This is what I want to build and talk about here:
Code: 
          ISP   
        dyn.IP
           |
     +-----+-----+    +-------+
     | DSL Modem |    |  DMZ  |
     +----+------+    +---+---+
          |               |
          |               |
   +------+---------------+-------------------------+
   |     if0             if1                        |
   |  PPPoE                                         |
   |    Gateway   /  Routing                        |
   |                                DNS   / NTP     |
   |      Packet Filter PF        unbound  server   |
   |                                                |
   |     if2             if3                        |
   +------+---------------+-------------------------+
          |               |
          |               |
      +---+----+      +---+--+
      | Switch |      | WLAN |
      | managed|      |  AP  |
      +01234567+      +------+
       | | |  |
       clients
Before starting with my questions soon,
any comments / hints so far?
 
So, you need a box with 4 interfaces. Your DSL modem should be in bridge mode. Routing is not important since everything will be statically connected. I would put the NTP/UNBOUND (servers) in the DMZ but that might be a luxury.
 
gkontos said:
Routing is not important since everything will be statically connected.
Click to expand...
Nice to hear that at this early stage, I expected it worse ;)
but it adds some confusion, because I thought with routing NAT might be unneccessary.

1. Can routing replace NAT? What applies to my settings? What should I use here for a completly static IPv4 LAN/VLAN?

2. Next thing to choose is going with "onboard" ppp.conf or netgraph(4) based net/mpd5? Mpd5 is said to be more PF-friendly, is it? PPPoE dialing should be triggered automatically on demand without human interaction.

So these are mainly the two points making my headaches for now :)
 
getopt said:
Nice to hear that at this early stage, I expected it worse ;)
but it adds some confusion, because I thought with routing NAT might be unneccessary.

1. Can routing replace NAT? What applies to my settings? What should I use here for a completly static IPv4 LAN/VLAN?

2. Next thing to choose is going with "onboard" ppp.conf or netgraph(4) based net/mpd5? Mpd5 is said to be more PF-friendly, is it? PPPoE dialing should be triggered automatically on demand without human interaction.

So these are mainly the two points making my headaches for now :)
Click to expand...

1. Routing has nothing to do with NAT. By enabling the box to act as a gateway, then your routing issues are solved. Unless of course, your inside LAN contains other routers where in that case you solve it by adding static routes or by using a dynamic routing protocol. By the term static, we mean interfaces that are directly connected to the firewall.
NAT on the other hand is something that you need in order for your inside, DMZ, etc, to have Internet access. Since the clients use a private non routable IP address, then it has to be translated with the IP address of the firewall. Also, if you want to expose a service from the DMZ to the Internet, then you need NAT again.

2. I usually use the native onboard PPP. But you might want to check out the other options.
 
As many of us, I am also running a FreeBSD box as the gateway to my home network. However, I never felt the need to setup a dedicated DMZ. I had always 1 to 3 services behind a stateful firewall in the LAN that I opened to the public internet by the way of NAT redirection, though.

What additional benefit would we gain with a DMZ in comparison to NAT redirection for a handful of ports?
 
obsigna said:
What additional benefit would we gain with a DMZ in comparison to NAT redirection for a handful of ports?
Click to expand...

The purpose of the DMZ is to enforce a different security policy. Most servers in the DMZ do not have access to the internal network. Therefore, if you have a security breach in the DMZ, the intruder will not have access to your LAN.
 
Depending on the services you want to offer to the local networks or "the internets", it might be wise to further segregate the DMZ into internal and external zone.
E.g. I'm running several jailed TOR-relays at home - these jails are all connected to a heavily constrained "ext_DMZ" with no access to the local networks. The privoxy proxies that use these tor instances for outgoing connections, as well as the squid that is doing the load-balancing between the proxies, all reside in a "loc_DMZ", which can be accessed from the LAN, but has very tight rules for egress connections.
This can be achieved either on multiple hosts via VLANs or even on a single host by using bridge interfaces to which the jails are connected. E.g. I'd put the DNS in a jail and either connect it only to the DMZ or (on a bigger network) to all networks but use separate views for each.

While this might be overkill if you only have a desktop and your laptop on your local network, I can highly recommend multiple WLAN networks (VLANs) even for small home Networks - one for your trusted devices (e.g. your laptop) with access to resources within your local networks (fileserver/NAS) and another one for guests, smartphones/-TVs and other dodgy devices you want to keep a bit more confined. I generally only allow http(s) and mail to egress from this guest network (and maybe some android- or blackberry-specific connections) and redirect all DNS-traffic to the local server.

Depending on the number of wireless clients, I'd aggregate 2 NICs as uplink to the switch, connect the AP to the switch put its mgmt-interface and SSIDs into their own VLANs. Of course, this requires an access point that can advertise multiple SSIDs and has VLAN support, but almost any mid-range AP I've seen in the last few years already has these capabilities (I like the linksys LAPN/LAPAC series - they offer a lot of enterprise-features and very strong MIMO-radio with beam-forming for a very reasonable price).
 
You must log in or register to reply here.
Back
Top