How to configure two interfaces (LAN and WLAN)?

Just been looking at pf but can't find a ruleset which will pass all traffic between two interfaces...

Can I use a ruleset of:

Code:
pass in all
pass out all

?
 
That ruleset is a good start, but you need NAT. Read section 32.3.2.1 here:
 
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.
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 ruleset is a good start, but you need NAT. Read section 32.3.2.1 here:
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.

Reading it again I can't work out if I need natd() fot NAT or is the for ipwf.... Can't help thinking I am way out of my depth with all this :(
 
You won't know 'till you give it a shot!

Well I've given it a shot. Spent all day trying to make some sense of it all and don't think I have a clue about how to configure things!

All I want is for one system to pass traffic between one interface and another where the interfaces are on different subnets.
 
By the time you hit Chapter 4 in Peters book you will know about pfNAT.....

Have you tried searching for a copy. This book is very concise. Easy to understand.

Basic pfNAT rules look like this. You must verify your internal and external interfaces.
Code:
ext_if="wlan0"
int_if="em0/igb0"
set skip on lo
nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)

So this sets your Wireless as WAN or External Interface in firewall parlance.
 
You want me to come to your place and set it up don't you? I would have been done years ago.
I used rev2 of 'The book of pf' from 2010. Nothing really has changed much.
 
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. I'm beginning to think what I want to achieve is not doable so am thinking of using a second broadband router.

Thanks for your help but It looks like I'm not going to be able to make this work.
 
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.

It may seem basic, until you understand why you need NAT in order to route traffic between these two different subnets.

Thanks for your help but It looks like I'm not going to be able to make this work.

Not without NAT. So, how does it work, what does it do? Let's try for simple:

inet=192.168.2.x/24
onet=192.168.1.y/24

where inet is inside LAN, onet is outside on the way (via your other router) to internet.

So, pkt arrives from inet to your inside interface (iif), with source address in inet, say 192.168.2.10, and dest addr as (say) 1.1.1.1, via
your .2.x as defaultroute.

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.

So NAT - Network Address Translation - must a) replace pkt source addr with YOUR addr in onet, so router will accept it and knows where to send responses, and b) record the pkt in your NAT table, so it knows where to deliver any response pkts back to inet at the right addr, after replacing this time the pkt destination address.

Once you understand why this needs to happen, then finding out how to do it becomes much easier.

natd (or kernel NAT) is used with ipfw. Likely you'll find more help for pf setups here, hopefully with only minimal protection rules initially to reduce learning stress.

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 ...
 
All I'm trying to do is pass all traffic between ext_if and int_if without any blocking.
If that was true you could disable the firewall and have inet.

I want to encourage you to continue trying. I had 2 months at it. I tried to take shortcuts by copy and pasting rules from others. When that failed I thought I could get security/fwbuilder to build my firewall for me.
Firewall by template. What could go wrong....
Luckily I had a network in mind that it couldn't build with a template. Forcing me to open a book I already owned.
 
These were the last rules that made me really work for it.
Code:
pass in quick on $int_if proto udp from port = 68 to port = 67
pass out quick on $int_if proto udp from port = 67 to port = 68

I was almost to the point of offering money in forum for help.
 
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.
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.*

A second layer of NAT would translate 192.168.2.0/24 addresses onto 192.168.1.0/24 addresses. The Asus router does know what to do with packets bound for that latter network, and everything will work.

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 ...
Yes. I learned this stuff by reading the Crab Book, but it's hopelessly out of date now.

* However, it's more likely that it's just flat dropping packets from an RFC 1918 network address it doesn't know about, just like smithi says.
 
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.

back in 2011, I used some tool desktop shell script with Puppylinux (ShareInternet2.2.6 pet) and iptables, to connect to wifi internet and provide a em0 wired internet network access for another pc on the wired cable. I will search and add comment here later. Information might be lost to bit rot, though. Here I found the shareinternet shell script
https://oldforum.puppylinux.com/viewtopic.php?t=37520&start=75 Linux Test Script for examining iptables and iwconfig setup. Reference forum post: https://oldforum.puppylinux.com/viewtopic.php?t=46797 Linux Test Script

#!
# 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


Share_Internet Script for 2012 PuppyLinux ShareInternet-2.2.6.pet Balanga, Some Linux shell script to read and understand, then modify for your needs in FreeBSD. Download ShareInternet-2.2.6.pet rename file ShareInternet-2.2.6.tar.gz Then extra files and you can examine files and see what is necessary. This might contain "Linux" type tools and uses for iptables. YMMV. I believe this is just a tool, that could be modified to work with FreeBSD.

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.

Welcome comments about setting up a test pc to PXE boot from a wired ethernet connection.
 

Attachments

  • shareInternet_image.png
    shareInternet_image.png
    15.1 KB · Views: 84
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.

Yes.

Destination is on the local network? Yes: deliver. No: forward to gateway.

True 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.

I don't know about pf, but getting ipfw to route packets with RFC-1918 addresses not assigned to an interface requires modifying rules, e.g. /etc/rc.firewall 'simple' ruleset, which might otherwise suit balanga here, with NAT enabled.

Again, I'm hoping that pf experts might help out here, without getting too fancy for beginner comprehension, for a simple NAT-mostly firewall?

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.*

Precisely - but assuming 1.1.1.1 is a real Internet address (it pings, % 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.

Me too, a wonderful book, very well written I thought. Mine was 2nd Ed. I recall, before 2002 anyway.

But I don't think its basic principles are out of date at all, especially for beginners, which I was when I read it.
 
True 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.
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 with gateway_enable="YES" in its /etc/rc.conf. It will happily forward packets to and from RFC 1918 networks.

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 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.
 
Having a management port was a real nice addition suggested to me by by SirDice years ago.
I can't tell you how many times I locked myself out of ssh getting my rules right.
 
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 with gateway_enable="YES" in its /etc/rc.conf. It will happily forward packets to and from RFC 1918 networks.

Sure - and in this case both interfaces are on 192.168.x addresses so it has to.

I had a very similar setup between a wired LAN and USB tethering via a phone, needing surgery on the ipfw ruleset around NAT rules.

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.

True enough. Then when it blows up, it's your fault! :)
 
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 think you misunderstand what I trying to do. My project is to create a PXE server, which I have already actually done and am hoping to provide a script for doing this from scratch. Host 3 is the PXE server and am able to PXE boot host2 from it. I can stop dhcp on host3 if there is any interference from the router (host 1), but there won't be when I want to network boot host2 because there is only a wired connection.

I only discovered by accident that host2 established two connections (wired and wireless) because I hadn't even configured wlan initially on the system. The reason for wanting Internet access on host 3 was so that I could install a few pkgs that I was lacking. I didn't think it would be so complicated.
 
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.
 
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.
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.
 
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.

That's basically what I'm trying to do, ie use the laptop as a bridge to another system which is unable to reach the broadband router directly, only via a LAN connection to the laptop.
 
DHCP can traverse bridges. Host 1 and 3 will interfere with each over a bridge. You definitely need a router.
 
Back
Top