[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

TCP Reflection (continued)



Hi all- 
I've just completed a new OBSD 3.1 build, and am trying to get some form
of tcp reflection working on this system.  I know that the best choice
would be to create a DMZ... this is not a study in best practices, this
is an effort to get this feature _working_.  I've attempted to get this
working via tcp proxy (nc) and via the convoluted redirect method.  Here
is my network description: 
Internet <----->  (dc0) Firewall (dc1)  <--------->  Server 192.168.1.20
                  10.0/8      192.168.0/16      | 
                                                |->  Client 192.168.1.21
int_if="dc1" 
ext_if="dc0" 
int_net="192.168.1.0/24" 
server="10.109.10.97" 
webserver="192.168.1.20" 
First, I tried to use the following redirection rules as provided by the
OpenBSD FAQ and Daniel himself (thanks Daniel).  I can't even get to
testing them, pfctl complains of a syntax error on the last rule: 
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> $server 
no nat on $int_if proto tcp from $int_if to $int_net 
nat on $int_if proto tcp from $int_net to $server port 80 -> $int_if 
/etc/nat.conf:22: syntax error 
pfctl: syntax error in file: nat rules not loaded 
So, I'm trying to use the tcp proxy method via netcat, but that doesn't
work either.  I first attempted to use the default example as found in
the OBSD FAQ:
(inetd.conf)
127.0.0.1:5000 stream tcp wait nobody /usr/bin/nc nc -w 20 192.168.1.20
80
(nat.conf)
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> 127.0.0.1
port 5000
The client appears to connect to the proxy just fine, based on the
output of "pfctl -ss", netstat, and tcpdump.  However, it appears that
the firewall is not translating the destination, as tcpdump on the
server shows a source address of 127.0.0.1.  I've tried various
redirection/nat rules, and nothing seems to be working.  Best results
end in a flood of S/F packets being sent between the firewall and server
(after a lengthy delay of nothingness)... worst results show a S/SA
connection between the client and firewall, then nothing.
Any suggestions?
TIA,
Jason