cod3fr3ak
March 20th, 2003, 14:38
Hi all I am new to these boards. i hope someone here can help me.


I can not access my website via the external ip. Is there any reason I should not be able to do this? I can access the webpage from work or a friends house with no problems.
Also how should I implement ftp? I have a server installed on the $netsrv machine. i would like people to be able to access it from outside my network - but I would also like to be able to access it from my internal $int_network addresses as well. I also have several laptops that i would like to place on a separate network.

Also what is with the <escape> key and these boards. Everytime I hit it it wipes out eevrything I type. This is my third time typing this after inadvertantly hittig the <esc. key after a line (i am a unix admin - its a vi habit).
Thanks in advance.


[code:1:9cdf133597]
# $OpenBSD: pf.conf,v 1.6 2002/06/27 07:00:43 fgsch Exp $
#
# See pf.conf(5) for syntax and examples
#
#
# Debug your rules:
#
# To view the logfiles:
# tcpdump -n -e -ttt -r /var/log/pflog
#
# To tail -f the logfile:
# tcpdump -n -e -ttt -i pflog0
#
# Use pfctl -s nat to show the effective nat-rules.
# Use pfctl -s rules to show your effective pf-rules.
#

##############################
# Begin Custom Configuration #
##############################

# Optimization
set optimization aggressive
set timeout tcp.established 3600
set timeout { tcp.opening 30, tcp.closing 120 }
set limit { states 20000, frags 20000 }

# Define variables for the network interfaces

ext_if = "dc0" # Untrusted External Interface (from cable modem)
int_if = "dc1" # Trusted Internal Interface (outgoing from 192.168.1.0)
int_wap_if = "dc2" # Trusted Internal Wireless Interface
private_addr = "{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }"
ftp_port = 46968 # Non-standard FTP port
ftp_data = 46967 # Non-standard FTP data channel
ftp_allowed = "192.168.0.0/16" # Trused IPs from FTP access
ext_ip = "68.50.8.115" # External IP
int_network = "192.168.0.0/16" # Internal network address space
netsrv = "192.168.1.101" # Win2k Network Server


# Statistics logging for on external interface
set loginterface $ext_if

# Normalize: reassemble fragments and resolve or reduce traffic ambiguities
scrub in on $ext_if all fragment reassemble

# Begin NAT and redirect rules

# NAT on the External interface
nat on $ext_if from $int_network to any -> ($ext_if)

# redirect port 80
rdr on $ext_if proto tcp from any to 0.0.0.0/0 port 80 -> $netsrv port 80

# redirect port 25
rdr on $ext_if proto tcp from any to 0.0.0.0/0 port 25 -> $netsrv port 25


# Begin filtering rules

# default pf rules, made explicit:
pass in all
pass out all

# don't filter any loopback interface traffic:
pass in quick on lo0 all
pass out quick on lo0 all

# *** TCP ***
# stop everything inbound, then open up the ports we want seen:
block return-rst in on $ext_if proto tcp from any to any
pass in quick on $ext_if proto tcp from any to $netsrv port { ssh, smtp, http } keep state

# Keep state on outgoing TCP connections:
pass out quick on $ext_if proto tcp from any to any keep state

# *** UDP ***
# Stop everything inbound. We want no externally visible UDP ports:
block return-icmp in on $ext_if proto udp from any to any

# Keep state for desired outbound UDP connections:
pass out quick on $ext_if proto udp from any to any port { domain, ntp } keep state

# allow WWW access:
#pass in quick on $ext_if proto tcp from any to $netsrv port 80

# allow mail access:
#pass in quick on $ext_if proto tcp from any to $netsrv port 25
[/code:1:9cdf133597]

Also this is just a preliminary config. I got so frustrated with pf i started all over entering one command at a time.

soup4you2
March 20th, 2003, 14:48
pass in quick on $ext_if proto tcp from any to YOURHOSTNAME port = 81 flags S keep state

how about something like that? i dont really know the diffrences in pf and ipf

cod3fr3ak
March 21st, 2003, 11:55
hey this thing dropped my post?

cod3fr3ak
March 21st, 2003, 11:56
Anyway. I said i already have a line lie you mentioned soup:
[code:1:49c0438e73]
pass in quick on $ext_if proto tcp from any to $netsrv port { ssh, smtp, http } keep state
[/code:1:49c0438e73]

It seems to work fine as long as I connect to the internal address (192.x.x.x).

elmore
March 21st, 2003, 11:57
What post did it drop?

elmore
March 21st, 2003, 11:58
Wierd looks like your post came back after I posted? Freaky. Haven't seen that one before.

As far as the escape key goes I have that issue sometimes, it's fairly sparactic and is a bug with the parser. It's due to be fixed in the next release of phpBB. That should be out sometime in the near future, I hope anyways. I know it can be annoying, as I have the same problem being used to vi.

As for your ruleset, here's what I use on my webserver.

[code:1:001d845064]
# Define useful variables
ExtIF="xl0" # External Interface
Loop="lo0" # loopback rules
sshHost="xxx.xxx.xxx.xxx" # Allow ssh from a specific host
NoRouteIPs="{ 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

# Clean up fragmented and abnormal packets
scrub in all

#loopback rules
pass in quick on $Loop
pass out quick on $Loop

# don't allow anyone to spoof non-routeable addresses
block in log quick on $ExtIF from $NoRouteIPs to any
block out log quick on $ExtIF from any to $NoRouteIPs

# block various nmap shyte
block in log quick on $ExtIF inet proto tcp from any to any flags FUP/FUP
block in log quick on $ExtIF inet proto tcp from any to any flags SF/SFRA
block in log quick on $ExtIF inet proto tcp from any to any flags /SFRA
block in log quick on $ExtIF inet proto tcp from any to any flags F/SFRA
block in log quick on $ExtIF inet proto tcp from any to any flags U/SFRAU
block in log quick on $ExtIF inet proto tcp from any to any flags P
block in log on $ExtIF all

# only allow our machines to connect via ssh
pass in on $ExtIF inet proto tcp from $sshHost to any port = 22 keep state

# Allow web traffic
pass in log quick on $ExtIF proto tcp from any to any port = 80 keep state

pass in log quick on $ExtIF proto tcp from any to any port = 443 keep state

# Allow mail
pass in log quick on $ExtIF proto tcp from any to any port = 25 keep state

# Allow FTP
pass in log quick on $ExtIF proto tcp from any to any port = 21 keep state

# Allow DNS
pass in log quick on $ExtIF proto udp from any to any port = 53 keep state

# and let out-going traffic out and maintain state on established connections
# pass out all protocols, including TCP, UDP and ICMP, and create state,
# so that external DNS servers can reply to our own DNS requests (UDP).
block out on $ExtIF all
pass out on $ExtIF inet proto tcp all flags S/SA keep state
pass out on $ExtIF inet proto udp all keep state
pass out on $ExtIF inet proto icmp all keep state
[/code:1:001d845064]

A couple of notes, If your box is a webserver and you run internal DNS with the same domain name, you're liable not to be able to resolve, you domain name unless you include a spcl.domainname file in your DNS config. If this is the case I have a non-authoritative DNS how-to in the how-to section that covers this.

Of course your ruleset is on a firewall with three interfaces, it looks like anyways, so you'll be a little different. It looks pretty good to me man, Nothing really obvious pops out. Of course I am also the board idiot, so perhaps someone else will be gracious enough to look at it as well. :roll:

cod3fr3ak
March 21st, 2003, 18:02
Weird.

Another question: Do i need a rdr rule and a pass in filter rule in order to get traffic to my webserver - if it is on a different box?
Also do you have any problems accesing your webserver via your external ip?

Thanks I'll take another look at my config file to see if i missed anything.

cod3fr3ak
March 22nd, 2003, 09:52
Figured out the rdr question. I read that rdr does not imply filtering. So if I have rdr rule it may get blocked if there is not a matching pass rule.

I am still researching the www access issue.

elmore
March 22nd, 2003, 11:40
yeah that right so it you have a rule like

rdr on port 80 from any to 10.0.0.1/32

or whatever that syntax is a little off I'm sure, you'll need to have a filter rule is you use a default deny ruleset that says

pass in quick on port 80

or something similar, again that syntax might not be quite correct. But you get the general idea.

|MiNi0n|
March 22nd, 2003, 16:53
# redirect port 80
rdr on $ext_if proto tcp from any to 0.0.0.0/0 port 80 -> $netsrv port 80

# redirect port 25
rdr on $ext_if proto tcp from any to 0.0.0.0/0 port 25 -> $netsrv port 25

I'd watch your syntax on these rdr rules.... use any instead of 0.0.0.0/0. And as elmore suggested, each rdr rule will need an equivalent pf rule.

cod3fr3ak
March 25th, 2003, 14:35
Okay here is my pf.conf new and improved. But I am still having some issue. take a look at the file:

[code:1:b55302c461]
# Optimization:
set optimization aggressive
set timeout tcp.established 3600
set timeout { tcp.opening 30, tcp.closing 120 }
set limit { states 20000, frags 20000 }

#### Define variables for the network interfaces

no_route="{ 127.0.0.1/18, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 255.255.255
.255/32 }"
ext_if="dc0" # Untrusted External Interface (from cable modem)
ext_ip="68.x.x.x" # Untrusted External Ip Address (supplied by Comcast)
int_if="dc1" # Trusted Internal Ethernet Interface
int_ip="192.168.1.1" # Trusted Internal Gateway IP Address
int_wap_if="dc2" # Trusted Internal Wireless Interface
int_wap_ip="192.168.2.1"# Trusted Internal Wireless Gateway IP
pvt_net="192.168.0.0/16"# Internal Private Network
ftp_port="8500" # Non-standard FTP port
ftp_data="8499" # Non-standard FTP data channel
websv="192.168.1.101" # Webserver on neuromancer interface
dhs_net="207.x.x.x/24"# DHS Network for SSH access from work

# Statistics logging for on external interface:
set loginterface $ext_if

# Normalize: reassemble fragments and resolve or reduce traffic ambiguities
scrub in on $ext_if all fragment reassemble
scrub out on $ext_if all fragment reassemble

# Begin NAT and translation rules #

# NAT on the External interface:
nat on $ext_if from $pvt_net to any -> ($ext_if)

# Redirect port 80
rdr on $ext_if proto tcp from any to any port 80 -> 192.168.1.101 port 80

# redirect for my ssh access from work (temp)
rdr on $ext_if proto tcp from $dhs_net to any port 443 -> 192.168.1.1 port 22

# Begin filtering rules #

# Default pf rules, made explicit:
#pass out all # I am not sure if I need this rule since futher down I let out TCP, ICMP, and UDP stuff
block in all

# crush spoofed addresses
block in log quick on $ext_if from $no_route to any

# smash IP options
# Need a better rule for this option

# Services and Special rules
# allow mail services:
pass in quick on $ext_if proto tcp from any to $websv port { smtp, pop3 } keep s
tate

# allow WWW:
pass in quick on $ext_if proto tcp from any to $websv port 80

# allow SSH access thru port 443:
pass in quick on $ext_if proto tcp from $dhs_net to any port 22 keep state

# Cleanup
# keep states and pass out traffic
block out on $ext_if all
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out on $ext_if inet proto udp from any to any port { domain, ntp } keep state
pass out on $ext_if inet proto icmp all keep state
[/code:1:b55302c461]

Problem is now I can not ping any internal addresses. Which means the pass in line to my webserver doesn't work either. Is there something I am doing wrong? I would like to go with a default deny ruleset - just because I am using Comcast and they like to scan and arp all the time.
Using pftop I was able to see all my requests being blocked by the block in rule even though there are other rules that specify letting certain traffic in. I can also see my udp packets go out when I do a ping.

cod3fr3ak
March 25th, 2003, 15:05
I think I fixed it.

My default deny was:
[code:1:d2218060ce]
block in all
[/code:1:d2218060ce]

Which i think made the frewall dump everything no matter what.
I changes this line to:
[code:1:d2218060ce]
block in on $ext_if all
[/code:1:d2218060ce]

And things seem to be working again. Please look over my pf.conf though, as I am sure thre are some thing in it that could be better.

elmore
March 25th, 2003, 15:11
So can you access your webserver form inside your home net now? Wasn't that part of your initial problem?

cod3fr3ak
March 25th, 2003, 15:27
Okay here is my final cut:

[code:1:5c1654b486]
# Optimization:
set optimization aggressive
set timeout tcp.established 3600
set timeout { tcp.opening 30, tcp.closing 120 }
set limit { states 20000, frags 20000 }

#### Define variables for the network interfaces

no_route="{ 127.0.0.1/18, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 255.255.255.255/32 }"
ext_if="dc0" # Untrusted External Interface (from cable modem)
ext_ip="68.x.x.x" # Untrusted External Ip Address (supplied by Comcast)
int_if="dc1" # Trusted Internal Ethernet Interface
int_ip="192.168.1.1" # Trusted Internal Gateway IP Address
int_wap_if="dc2" # Trusted Internal Wireless Interface
int_wap_ip="192.168.2.1"# Trusted Internal Wireless Gateway IP
pvt_net="192.168.0.0/16"# Internal Private Network
ftp_port="8500" # Non-standard FTP port
ftp_data="8499" # Non-standard FTP data channel
websv="192.168.1.101" # Webserver on neuromancer interface
dhs_net="207.x.x.x/24"# DHS Network for SSH access from work

# Statistics logging for on external interface:
set loginterface $ext_if

# Normalize: reassemble fragments and resolve or reduce traffic ambiguities
scrub in on $ext_if all fragment reassemble
scrub out on $ext_if all fragment reassemble

# Begin NAT and translation rules #

# NAT on the External interface:
nat on $ext_if from $pvt_net to any -> ($ext_if)

# Redirect port 80
rdr on $ext_if proto tcp from any to any port 80 -> 192.168.1.101 port 80

# redirect for my ssh access from work (temp)
rdr on $ext_if proto tcp from $dhs_net to any port 443 -> 192.168.1.1 port 22

# Begin filtering rules #

# crush spoofed addresses
block in log quick on $ext_if from $no_route to any

# Default pf rules, made explicit:
#pass out all # I am not sure if I need this rule since futher down I let out TC
P,ICMP, and UDP stuff
block in on $ext_if all

# smash IP options
# Need a better rule for this option

# Services and Special rules
# allow mail services:
pass in quick on $ext_if proto tcp from any to $websv port { smtp, pop3 } keep state

# allow WWW:
pass in quick on $ext_if proto tcp from any to $websv port 80

# allow SSH access thru port 443:
pass in log quick on $ext_if proto tcp from $dhs_net to any port 22 keep state

# Cleanup
# keep states and pass out traffic
block out log on $ext_if all
pass out on $ext_if inet proto tcp all flags S/SA keep state
pass out on $ext_if inet proto udp from any to any port { domain, ntp } keep state
pass out on $ext_if inet proto icmp all keep state
[/code:1:5c1654b486]

Comments?

Elmore,
Nope access from my internal to external back to internal still doesn't work. I got a hold of some folks at the SanFran OpenBSD group who say that although ipf can not handle this type of stuff pf can. However the rules to do it are actually pretty complex. So I have two options access it via another interface (need to reconfigure the httpd.conf for this), or figure out the pf rules myself. For the time being I'll just access the site via internal addrssing. Should I get the info I'll post it. Thanks.

|MiNi0n|
March 25th, 2003, 17:14
Nope access from my internal to external back to internal still doesn't work.

Can you clarify that a bit for me? Does that mean you can't see the webpage from your internal net?

cod3fr3ak
March 25th, 2003, 17:28
I can see the web site via the internal ip. I can not see it using the external ip.

|MiNi0n|
March 25th, 2003, 18:18
from where??? need more deets if you want more help. Does this mean you can access it from inside your network but not from the outside world? Does it mean you can access it from inside your network when you use the internal ip address but not when you use the external address?

It's really a fairly standard non-complex setup so there should be no issue with getting the pf rules to work. I'm sure we can have you up and running in no time :lol:

cod3fr3ak
March 25th, 2003, 23:23
okay here is the deal. I can acess the website via 192.168.x.x address from my win XP box (which is also on the 192.168.x.x subnet). I can not access the website by using the external ip (68.x.x.x) from within my network (192.168.x.x) If I access the site from another machine (at work or at a friends) I can see the web-site via the external ip address. I deny 192.168.x.x by default.
At first this frustrated me alot because on one hand I could see the site locally but was unsure if it was being published externally.

cod3fr3ak
April 5th, 2003, 12:20
No Ideas yet?

|MiNi0n|
April 5th, 2003, 13:43
okay here is the deal. I can acess the website via 192.168.x.x address from my win XP box (which is also on the 192.168.x.x subnet). I can not access the website by using the external ip (68.x.x.x) from within my network (192.168.x.x) If I access the site from another machine (at work or at a friends) I can see the web-site via the external ip address. I deny 192.168.x.x by default.
At first this frustrated me alot because on one hand I could see the site locally but was unsure if it was being published externally.

Ok, well that sounds like an issue with your XP config. If other boxes on the 192 subnet are able to see it and you're not it's very unlikely to be a PF problem. Do all your boxes on 192 DHCP addresses or do some have manual addy's?

Check things like subnet mask, DNS (using nslookup), traceroute (tracert in Winbloze) on your XP box. Problem likely lies there.

cod3fr3ak
April 5th, 2003, 14:02
It doesn't work from any of the 192.x boxes even the server on which the www server resides! :-(

|MiNi0n|
April 5th, 2003, 14:28
I can not access the website by using the external ip (68.x.x.x) from within my network (192.168.x.x) If I access the site from another machine (at work or at a friends) I can see the web-site via the external ip address.

Sorry, I interpreted that to mean another box on 192 :roll:

Anyhow, it's really a moot point I gotta say. If you can see it internally on the 192 and externally on the 68 then that's all you need! You're right that it has to do with the blocking 192. If you think about it, your config is set up so that you rdr on the ext interface to the 192. You also state to block out and in anything destined for 192 on the external interface. So coming in from the outside works because traffic won't be coming from a noroute IP like the 192.

However, when the traffic originates on the 192 subnet, it hits the external interface before the rdr happens. The rules on the ext if drop those packets.

What you want is to set up DNS internally to point to the 192 address and obviously leave the external DNS as is.

bsdjunkie
May 7th, 2003, 17:53
This problem has been addressed in the latest version of the pf faq ;)

http://www.openbsd.org/faq/pf/rdr.html

Redirection and Reflection
Often, redirection rules are used to forward incoming connections from the Internet to a local server with a private address in the internal network or LAN, as in:

server = 192.168.1.40

rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80

But when the redirection rule is tested from a client on the LAN, it doesn't work. The reason is that redirection rules apply only to packets that pass through the specified interface ($ext_if, the external interface, in the example). Connecting to the external address of the firewall from a host on the LAN, however, does not mean the packets will actually pass through its external interface. The TCP/IP stack on the firewall compares the destination address of incoming packets with its own addresses and aliases, and detects connections to itself as soon as they have passed the internal interface. Such packets do not physically pass through the external interface, and the stack does not simulate such a passage in any way. Thus, PF never sees these packets on the external interface, and the redirection rule, specifying the external interface, does not apply.

Adding a second redirection rule for the internal interface does not have the desired effect either. When the local client connects to the external address of the firewall, the initial packet of the TCP handshake reaches the firewall through the internal interface. The redirection rule does apply and the destination address gets replaced with that of the internal server. The packet gets forwarded back through the internal interface and reaches the internal server. But the source address has not been translated, and still contains the local client's address, so the server sends its replies directly to the client. The firewall never sees the reply and has no chance to properly reverse the translation. The client receives a reply from a source it never expected, and drops it. The TCP handshake then fails and no connection can be established.

Still, it's often desirable for clients on the LAN to connect to the same internal server as external clients and to do so transparently. There are several solutions for this problem:

Split horizon DNS

It's possible to configure DNS servers to answer queries from local hosts differently than external queries so that local clients will receive the internal server's address during name resolution. They will then connect directly to the local server, and the firewall isn't involved at all. This reduces local traffic, since packets don't have to be sent through the firewall.

Moving the server into a separate local network

Adding an additional network interface to the firewall and moving the local server from the client's network into a dedicated network (DMZ) allows redirecting of connections from local clients in the same way as the redirection of external connections. Use of separate networks has several advantages, including improving security by isolating the server from the remaining local hosts. Should the server (which in our case is reachable from the Internet) ever become compromised, it can't access other local hosts directly, as all connections have to pass through the firewall.

TCP proxying

A generic TCP proxy can be setup on the firewall, either listening on the port to be forwarded or getting connections on the internal interface redirected to the port it's listening on. When a local client connects to the firewall, the proxy accepts the connection, establishes a second connection to the internal server, and forwards data between those two connections.

Simple proxies can be created using inetd(8) and nc(1). The following /etc/inetd.conf entry creates a listening socket bound to the loopback address (127.0.0.1) and port 5000. Connections are forwarded to port 80 on server 192.168.1.10.

127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80

The following redirection rule forwards port 80 on the internal interface to the proxy:

rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000

RDR and NAT combination

With an additional NAT rule on the internal interface, the lacking source address translation described above can be achieved.

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

This will cause the initial packet from the client to be translated again when it's forwarded back through the internal interface, replacing the client's source address with the firewall's internal address. The internal server will reply back to the firewall, which can reverse both NAT and RDR translations when forwarding to the local client. This construct is rather complex, as it creates two separate states for each reflected connection. Care must taken to prevent the NAT rule from applying to other traffic, for instance connections originating from external hosts (through other redirections) or the firewall itself. Note that the rdr rule above will cause the TCP/IP stack to see packets arriving on the internal interface with a destination address inside the internal network. To prevent the stack from issuing ICMP redirect messages (telling the client that its destination is reachable directly, breaking the reflection), disable redirects on the gateway, using

# sysctl -w net.inet.ip.redirect=0
# sysctl -w net.inet6.ip6.redirect=0 (if using IPv6)

In general, the previously mentioned solutions should be used instead.

cod3fr3ak
May 8th, 2003, 07:09
I am forever in your debt. Let me mull over all that info before I decide on what to do. I had left this issue alone figuring it would figure itsellf out. Thanks B.

cod3fr3ak
May 9th, 2003, 18:35
Ok now that I have had a couple of days to think a little more about this I think I will go with option one first and see how that works out. I have a windows 2000 machine (the www server in question) that I also would like to setup as a local DNS server. I'll try that first. Anyone know of any good DNS server work Win32? :lol: I initially had pegged an older laptop running OBSD for this duty but that is proving to be another issue in and of itself. It doesn't have a cdrom an the network card I was using kept crapping out on me. I even tried using my buddy's car, a Xircom, but that had an issue where the card would time out when I tried to apply an IP address to it. The laptop would be great for this function. Its still in the works but I am not holding my breath on that one.
Oh and thanks again bsdjunkie - that was a very concise explanation and it really helped a lot.