Hi,
I have a bit of a problem. First of all, my network is set up like this: DSL Modem---OpenBSD router (mars)---hub. One of the computers that's connected to the hub is pluto. However, all of the computers connected to the hub are behind NAT and I only have one IP address.

I'm setting up an IRC server on pluto that's not compatible with NAT. I've tried all sorts of port forwarding from mars to pluto, but nothing works. Is it possible, with OpenBSD ipnat, to forward everything to blah.aboutpcs.com (aboutpcs.com is my domain) to the host on my LAN pluto (10.160.31.5)?

At first I was sure this was impossible, but some people say it's possible. My DNS is hosted by someone else, and they'll make changes for me, which these people said was important for this whole thing to work.

So, anyone have any idea? Thanks in advance!!

Originally posted by qslack
... Is it possible, with OpenBSD ipnat, to forward everything to blah.aboutpcs.com (aboutpcs.com is my domain) to the host on my LAN pluto (10.160.31.5)?

At first I was sure this was impossible, but some people say it's possible. My DNS is hosted by someone else, and they'll make changes for me, which these people said was important for this whole thing to work.



If I understand your firewall architecture correctly, I do not agree that you can do what 'some people' have said you can do. You might want to ask them for more details. If you could post what you find here, I'd be interested as I also run OpenBSD as my firewall.

ipnat and ipf are notoriously bad with applications (such as ftp and irc) that use multiple ports for data and control connections. ftp proxy support has been added to ipnat to get around the problem with ftp, but I do not recall seeing anything about irc proxy support in ipnat.

Here is a thread that may be helpful http://www.false.net/ipfilter/2000_12/0198.html


just curious, what are you going to call the tenth box on your network?

DNS is a red herring. IPnat is also a red herring. (oops, that's a bit unclear: what I mean is that you should only be running ipnat after you've separated off packets destined for the IRC server).

Assuming you can set up packet filters to catch all the packets you want forwarded to the internal server you're going to want to set up the firewall as (approximately) a transparent bridge.

Originally posted by cperciva
... what I mean is that you should only be running ipnat after you've separated off packets destined for the IRC server...



Yup, that's the problem. How is it solved?

Originally posted by Mike the newbie
Yup, that's the problem. How is it solved?

That's exactly what I was wondering, too...

cperciva...can you enlighten us? :D

Ok I'm more familiar with FreeBSD than I am with OpenBSD so you might have to translate this slightly, but here's what I'd do under FreeBSD:

1. Compile your kernel with the BRIDGE, IPFIREWALL, and IPFIREWALL_DEFAULT_TO_ACCEPT, and IPDIVERT options.

2. Add net.link.ether.bridge=1 and net.link.ether.bridge_ipfw=1 to /etc/sysctl.conf

3. Add gateway_enable="YES", firewall_enable="YES", firewall_type="/etc/ipfw.rules", natd_enable="YES", natd_interface="fxp0", and natd_flags="" into /etc/rc.conf. (Substitute your external interface for fxp0 above).

4. Create /etc/ipfw.rules which looks something like this (with 1.2.3.4 being your public IP):
#rules to bridge incoming IRC traffic
add 100 pass ip from any to 1.2.3.4 6667 in via fxp0

#rules to bridge outgoing IRC traffic
add 200 pass ip from 1.2.3.4 6667 to any out via fxp0

#you probably want to add some firewall rules here for security purposes

#divert everything else coming through fxp0 to natd
add 300 divert natd all from any to any via fxp0

#allow everything else through
add 400 pass all from any to any

5. Reboot.

And that should do it. The main point is that with bridge_ipfw=1 packets get sent through thw ipfw rules prior to being bridged, and with the appropriate rules we can split off the packets we want to NAT and hand those over to natd for processing.

Originally posted by cperciva
Ok I'm more familiar with FreeBSD than I am with OpenBSD so you might have to translate this slightly, but here's what I'd do under FreeBSD:....


Port 6667 is the control channel for IRC. The IRC connection then sets up a data channel on a different port (much like ftp). How does that data channel get sent to 1.2.3.4?

If I read your message correctly, it appears that the data channel traffic on the other port will be sent through the NAT translation and firewall, not to the IRC server.


(this is all new to me, so be please be patient whilst I learn :) )

That's why I said "something like this". Yes you'll need other rules to filter the other IRC traffic; but whatever rules you use you have to "pass" those packets while you "divert natd" the other packets.

Originally posted by cperciva
That's why I said "something like this". Yes you'll need other rules to filter the other IRC traffic; but whatever rules you use you have to "pass" those packets while you "divert natd" the other packets.

OK, there's the rub.

What you originally suggested can be done in OpenBSD ipnat by placing an rdr (redirect) command for port 6667 before the map (network address translation) commands in the ipnat.rules file. Any traffic for port 6667 will be sent to the IRC box internally, and all the other traffic will be sent through the ipnat mapping to the internal network IP address(es). This can be done with the default (GENERIC) OpenBSD kernel.

The difficulty that arises with IRC (and FTP) is that once the control port connection is established, then another high-numbered port is opened up. The number of that port changes with each new connection. In order to pass the IRC data connection through, you would have to redirect all the high-numbered ports to the IRC box. If all you want to do is IRC, then that is fine, but other protocols (like FTP) want to use those high-numbered ports as well, and that traffic may not want to go to the IRC box.

ipf/ipnat has a built-in proxy for ftp that handles this situation for ftp, but it does not [yet] have a built-in proxy for irc. Hence the problem....

The advantages of using a hybrid bridge/natd are twofold: First, the IRC server knows what its public IP address is; depending upon how intelligent the software is this might solve problems. Second, ipfw is far more general than simply being able to redirect specific ports: You can also filter based on source address and port (or based on tcp flags, etc.).

Essentially what it comes down to is this: If *you* can identify which packets belong to IRC and should be sent to that box, then you can almost certainly do it with ipfw rules. If you can't work out which packets are supposed to go where... well then there's no way any computer will be able to.

Originally posted by cperciva
Essentially what it comes down to is this: If *you* can identify which packets belong to IRC and should be sent to that box, then you can almost certainly do it with ipfw rules. If you can't work out which packets are supposed to go where... well then there's no way any computer will be able to.



The problem to be solved remains the same, you only know which packets to send to the IRC box on a session by session basis. The ports involved change with each session. As such, your 'routing' rules need to be very dynamic; too dynamic for a file-driven filter.

So a different approach is needed. With ftp, ipf solved the problem by implementing an ftp proxy in the firewall software. The proxy effectively changes the 'routing' rules dynamically on a session by session basis. Supposedly an irc proxy is likely for version 4 of ipf. Time will tell if that provides the solution.