It may look daunting, but it's really not complicated. In principle, this is how most WAPs work, at least in terms of providing connected clients Internet access. You won't know 'till you give it a shot!That seems to overcomplicate things.... In essence imagine there are three hosts, one them being a Broadband router/ Internet Gateway - host 1.
Host 2 is just a FreeBSD system with two interfaces where wlan0 gets its IP address via DHCP from host 1 and the other where em0 has a static IP on a different subnet say .2.0. Host 3 is another FreeBSD system where em0 is also static and also on subnet 2.0. All I want to do is to be able to ping 8.8.8.8 from host 3.
If I can setup a transparent bridge on host, would that give me what I want?
I can't honestly see why defaultrouter="192.168.2.20" in host 3's configuration doesn't work.
I've read that section 100 times and it's a clear as mud. It seems to be written by someone who understands everything about pf for someone else who understands everything about pf.That ruleset is a good start, but you need NAT. Read section 32.3.2.1 here:
![]()
Chapter 33. Firewalls
FreeBSD has three firewalls built into the base system: PF, IPFW, and IPFILTER. This chapter covers how to define packet filtering rules, the differences between the firewalls built into FreeBSD and how to use themdocs.freebsd.org
You won't know 'till you give it a shot!
ext_if="wlan0"
int_if="em0/igb0"
set skip on lo
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)
ext_if="wlan0"
int_if="em0/igb0"
The top two lines are macros.
These define your network interfaces for reuse thoughout your ruleset.
It also makes it easy to add interfaces without messing with rules.
All I'm trying to do is pass all traffic between ext_if and int_if without any blocking. This seems like a very basic task yet I have not come across any guides which show this as an example.
Thanks for your help but It looks like I'm not going to be able to make this work.
If that was true you could disable the firewall and have inet.All I'm trying to do is pass all traffic between ext_if and int_if without any blocking.
This is certainly true if the router is running a firewall, but let's consider a plain ol' dumb router, the kind that probably doesn't exist any more.If you take that pkt and just pass it to your router, router sees a source address in the wrong subnet, and rejects it; it only passes pkts from the 192.168.1/24 subnet, maybe only those with valid leases.
Yes. I learned this stuff by reading the Crab Book, but it's hopelessly out of date now.A short self-study course in basic TCP/IP principles would no doubt help you to be more comfortable with these concepts, for your sake and that of others ...
#!
# bash script file test_share_internet.sh
#Make sure the iptables service is started, then run the script
# *Beware /sbin/iptables -F will flush your existing rules if you have any so make sure you run
#/sbin/iptables -L -v -n -line-numbers and see. If you have any rules add them to the script.
# *If you are using a different src and dst IP you will want to enable ip forwarding:
#echo 1 > /proc/sys/net/ipv4/ip_forward
echo "List IPTables to see the port forwarding in action"
/sbin/iptables -L -v --numeric --line-numbers
echo " " ;echo " print the ifconfig "
ifconfig
echo " " ;echo " print wireless iwconfig "
iwconfig
echo " "; echo "See the routes. Is gateway up? "
route -n
echo " " ; echo " is ip_forward = 1? "; cat /proc/sys/net/ipv4/ip_forward
ShareInternet - Share Internet Interface with local Interface V2.2.5
ShareInternet is an application to help in running Puppy as a router. It is designed to be versatile, in that it is agnostic about, but not insensitive to, the types of interfaces that are used. It is meant to be an icon on the desktop that, once you have activated the appropriate interfaces, you click on it and through traffic can flow. A later click on the same icon and through traffic will stop.
When it's icon is clicked, it starts the firewall, suitably configured to protect the Internet interface, but leave the local interfaces alone. The firewall also provides a NAT service so that there are no up-stream routing difficulties. Then it starts dnsmasq suitably configured to provide a dhcp service on the local interface(s).
Once shareInternet is installed, "/root/my-applications/shareInternet" can to be dragged to the desktop to provide an icon. Of course it is also possible to use the icon in "/root/my-applications" directly.
To have ShareInternet started automatically at boot time, delete the "#" from the beginning of the "#[ -x /usr/local/shareInternet/startWithX ] && /usr/local/shareInternet/startWithX &" line in "/root/Startup/shareInternet.sh".
ShareInternet can work with any combination of ethernet, wifi, or ppp interfaces. Interfaces are not configured into ShareInternet, it works with whatever interfaces are active.
So, all the interfaces you intend to use must be "UP", before ShareInternet is started. This can cause problems when ShareInternet is started automatically. Some wifi interfaces apparently take a long time to activate, in this case configure a "BOOT_DELAY".
When ShareInternet is run, it configures the interface that connects to the network that contains the default gateway, as the Internet interface. All other interfaces are considered to be local interfaces.
This is certainly true if the router is running a firewall, but let's consider a plain ol' dumb router, the kind that probably doesn't exist any more.
That kind of router wouldn't care about the source address, just the destination. If the destination is on a network that this dumb router is directly connected to, it would forward the packet directly to the host that has address 1.1.1.1. If it's not, the router would forward it to its default router, and so on, until you reached some router that knew about 1.1.1.1. That's probably the way things worked back in the early Internet. It's a lot more complicated now, but the same principles apply.
Destination is on the local network? Yes: deliver. No: forward to gateway.
Balanga's problem is on the way back from the destination. The target machine says, OK, I gotta respond to 192.168.2.10, is that on my local network? Yes: deliver. No: forward. The process repeats until we make it all the way back to 192.168.2.10. But there's no return path for 192.168.2.10 because the Asus router has no route to 192.168.2.0/24.*
% drill -x 1.1.1.1
says it's a PTR to "one.one.one.one"!) then no way a pkt via any other router along the way would not just be dropped.Yes. I learned this stuff by reading the Crab Book, but it's hopelessly out of date now.
The RFC requires that packets to or from private network addresses have to be dropped in the public Internet. However, this does not apply to a Freebsd host on your network that you've configured withTrue enough as a general principle, but any router out there on the real internet, including one's ISP if not clueless, must drop packets from unrouteable source addresses, knowing there's no way to return them.
gateway_enable="YES"
in its /etc/rc.conf. It will happily forward packets to and from RFC 1918 networks.The rule set is trivial. Spoon feeding it would be counterproductive. Chances are there will be other problems, and the spoon-fed person will have no chance at troubleshooting them because they don't understand the basics.Again, I'm hoping that pf experts might help out here, without getting too fancy for beginner comprehension, for a simple NAT-mostly firewall?
The RFC requires that packets to or from private network addresses have to be dropped in the public Internet. However, this does not apply to a Freebsd host on your network that you've configured withgateway_enable="YES"
in its /etc/rc.conf. It will happily forward packets to and from RFC 1918 networks.
The rule set is trivial. Spoon feeding it would be counterproductive. Chances are there will be other problems, and the spoon-fed person will have no chance at troubleshooting them because they don't understand the basics.
if the end goal is to make host 3 boot from PXE and then have access to download freebsd packages from the internet. I used Freshtomato.org (or look at advanced Tomato https://advancedtomato.com/ ) to load a netgear 2500 router with new freshtomato firmware to support handing off a TFTP server IP address to a PXE client. The standard Netgear router software could not perform this use case.
Balanga, I am interested to follow your progress and network setup for booting host 3 using PXE boot.
Welcome comments about setting up a test pc to PXE boot from a wired ethernet connection.
I'd suggest looking at PXE Booting Utilities With FreeBSD. I used that as a basis for setting up a PXE server many years ago although I used pfSense to perform some of the functionality. This guide is a bit out of date, so I'm hoping to provide a script which build the whole thing, once I find the time.I am looking forward to seeing those scripts here and me learning from those scripts you have created and tested, Balanga. simple pictures of the network connections are nice to have also. Fred Finster aka wb7odyFred
What can I do to help out? I do want to be a tester of your scripts and network setup for PXE booting host2 from PXE server host3.
All of that said, I have to ask -- are you using this laptop to bridge an isolated LAN to a larger network? If that's the case, rather than setting up NAT and DHCPD, it might be simpler to configure your laptop to act as a transparent bridge between the WiFi network and the ethernet network to which it connects.
You mean I need to turn host 2 into a router?DHCP can traverse bridges. Host 1 and 3 will interfere with each over a bridge. You definitely need a router.