Michael T. Davis wrote:
I posted this request back on 13-MAY, but I haven't received any
responses (private or to the list). If there's some archive material I
can review, please pass along a pointer.
Is there any way to utilize ipnat with ipf when running as a bridge?
In particular, we'd like to redirect various services from one side of the
bridge to a specific address on the other side of the bridge. FWIW, we're
running IPF v3.3.18 under OpenBSD v2.8.
I do it every day in FreeBSD. If you pay close attention to the ipnat
instructions How-To, (which you might find at
http://www.obfuscation.org/ipf/ ), I believe it explains how to get it
to work.
I believe, if memory serves me, the kernel does NAT stuff before
ipfilter stuff. If you think it is the other way around, you will get
your rules wrong. In other words, NAT does its redirection, and a few
milliseconds later ipf filters it (allowing it or denying it).
Here's one of my redirects:
rdr oo0 192.168.1.2/32 port 2222 -> 192.168.0.2 port 80
That redirects an inbound packet from the Internet (interface oo0,
coming in 192.168.1.2) to a web server located on my internal net. This
way, a user going to a secret port 2222 will get an HTTP response.
pass in quick on oo0 proto tcp from any to 192.168.0.2 port = 80 keep state
My ipf.rules simply allows inbound packets to port 80 of the destination
machine. But you may not have the order mixed up. Maybe you need to
rewrite your rdr the way I did. My rdr mentions my firewall's IP on the
left, and my internal web server on the right.
Or, wait, maybe you are specifiying something else....
In ipnat.rules...
>
>rdr <ext-if> <another-IP>/32 port 23 -> <telnet-IP> port 23 tcp
No, I see what you did. The <another-IP> should be your firewall's IP
address to the outside world. Usually a global IP (but in my case, I
have an upstream NAT/Router and my firewall is actually in the
192.168.1.0/24 subnet).
That <another-IP> is not for the ipnat rules. It is only for ipfilter
rules. The NAT router careth not for things of that sort.
Note that my case seems to be a little simpler -- ipnat and ipfilter are
on the same box here (is that your case?). You might need to throw in
some fake or real IP addresses and rewrite your problem if this doesn't
fix it or it's more complicated.
Anyway, anybody on the Internet can visit:
http://wont.tell.you.my.servername.com:2222/ and they will go through my
NAT router, to local 192.168.0.2 port 80 running Apache. And then, back
the other way. The packet routes through a 2-interface ipf/ipnat router
with interfaces on different subnets: 192.168.1.2 (oo0) and 192.168.0.1
(ii0). I could every easily have firewalled all servers but one (which
you probably want).
I should have also mentioned that the firewall is basically a turnkey
system...we can't really upgrade it.
I tried using telnet as a test:
In /etc/ipf.rules...
pass in quick on <ext-if> proto tcp \
from any to <telnet-IP> port = 23 flags S keep state
In ipnat.rules...
rdr <ext-if> <another-IP>/32 port 23 -> <telnet-IP> port 23 tcp
The "<variables>" are just placeholders here for what, in practice, are actual
entities (IP addresses or interfaces). Using `ipnat -l', I can see a session
for the attempt I initiate from outside the firewall to <another-IP>:
RDR <telnet-IP> 23 <- -> <another-IP> 23 [<outside-IP> 2496]
...But the connection doesn't seem to get anywhere. (I don't see the expected
login process initiate and the telnet client eventually times out.) Here,
both <telnet-IP> and <another-IP> are behind (or inside) the firewall, and
<outside-IP> isn't. Assuming this should work, what other diagnostics could I
enlist to help track down the problem?
[...]
Thanks,
Mike
