FreeBSD Router Clients Cannot Reach the Internet
A FreeBSD 14.0 box acts as the border router for a small office. em0 gets a public address by DHCP from the ISP; em1 is 192.168.50.1/24 and runs dhcpd for clients. pf is enabled in /etc/rc.conf. Clients can ping 192.168.50.1 and can reach the ISP's DNS server by IP, but cannot reach 8.8.8.8 or example.com. From the router itself, ping 8.8.8.8 and DNS lookups work. pfctl -s nat shows no nat rules, and sysctl net.inet.ip.forwarding returns 0. The administrator recently copied a pf.conf from a server that only filtered local traffic, so the ruleset has pass rules for em1 but no translation rule for the LAN. The office needs working NAT and DNS for clients without exposing the router's services.
1. Diagnose why the clients fail while the router succeeds. Give the commands you would use to confirm each layer.
Read the worked answer
The router can reach the Internet because traffic originates locally and does not need forwarding or NAT. The clients fail for two separate reasons: IP forwarding is disabled, so the kernel will not pass packets between em0 and em1, and there is no NAT rule, so private 192.168.50.0/24 addresses would not be translated to the public address even if forwarding were on.
Confirm with sysctl net.inet.ip.forwarding, pfctl -s rules, pfctl -s nat, and pfctl -s info. On the router, run tcpdump -ni em1 icmp while a client pings 8.8.8.8: seeing the request arrive but not leave em0 suggests forwarding or filtering. Check route -n get 8.8.8.8 and the default route. On a client, check the default gateway and DNS settings received from DHCP. The fact that the client can reach the ISP DNS by IP shows basic routing to the gateway works, but that does not prove the router is forwarding.
2. Write the minimal pf.conf changes and the sysctl/rc.conf settings to make NAT work persistently.
Read the worked answer
In /etc/rc.conf, set gateway_enable="YES" and keep pf_enable="YES". That makes the forwarding sysctl persistent across reboots. For the current boot, also run sysctl net.inet.ip.forwarding=1.
A minimal pf.conf addition is:
nat on em0 from 192.168.50.0/24 to any -> (em0)
pass in on em1 from 192.168.50.0/24 to any keep state
pass out on em0 from any to any keep state
The NAT rule must match traffic before it leaves em0, and the interface name must be the actual WAN interface. Validate with pfctl -nf /etc/pf.conf before loading, then load with pfctl -f /etc/pf.conf. Confirm with pfctl -s nat and pfctl -s rules. Do not blindly allow all traffic to the router itself; the pass-in rule should be limited to the LAN subnet, and router services should be protected by the default block policy or explicit rules.
3. After NAT works, clients can ping 8.8.8.8 but cannot resolve example.com. What is the likely cause and how do you fix it?
Read the worked answer
If IP connectivity works but name resolution fails, the problem has moved from forwarding/NAT to DNS. The clients are probably receiving no DNS server, or an unreachable one, through DHCP. Check the client's /etc/resolv.conf and the dhcpd configuration. On FreeBSD dhcpd, the relevant option is typically option domain-name-servers 192.168.50.1; or the ISP resolver address, depending on whether the router runs a local resolver.
If the router is meant to be the DNS server, verify that the resolver is running and listening on 192.168.50.1, and that pf allows DNS from the LAN to the router. If clients should use the ISP resolver directly, ensure the DHCP option hands out that address and that NAT permits the traffic. Test from a client with drill example.com or host example.com, and test the router itself with the same command. Then renew the client lease or restart dhcpd and confirm the new resolv.conf.