So i've been working for past couple hours to get pf to forward to webserver on internal net,but no luck. I can nmap and get an open port from remote location but if i try to enter ip it just sits there for quite a while. I've read the debugging guide and still having trouble. I run tcpdump on both ext and int and they both show the packets on both passing though, so i guess the pf in is working but no out maybe??? Anyways heres my pf.conf any help would be great as there might be a whole pile hair under my chair by the time i figure this out.

firstly, log all your drops, and check the logs to see if you are dropping the packets.

I'm not sure if "rdr pass' is valid - it probably is, mind you, it's just that I don't know - but the pass will be immediately overridden by the following 'block drop all'. It just depends on whether the pass in quick ...to $server... line is right. You haven't put a 'keep state' line there, but I think pf assumes keep state now.

Anyway, if those mutterings don't help you, add 'log' to your block lines, check the log (there's an example of how to check them in the 'pflog' man page), and post back with your findings.

__________________The only dumb question is a question not asked.
The only dumb answer is an answer not given.

Your pf.conf was damaged when you copied and pasted. Note your "synproxy" got cut, as well as what appears to possibly have been a "modulate state". Next time, copy and paste plain text between [ code ] [ /code ] tags.

I'll guess, for two solutions:

1) You have no pass out for your internal network(s). Remember, PF doesn't know which of your interfaces connect to the Internet. It just knows interfaces, and the direction of traffic. The "rdr pass" only passes the incoming packets, you still need a pass rule for the outgoing packets on your local LANs.

2) If you have not already confirmed it, make sure you have enabled IPv4 packet forwarding in /etc/sysctl.conf.

Robbak is right: put "log" on every blocking filter rule, and use tcpdump.. You might also consider logging all pass rules, too. To watch for blocked traffic, use something like:

You haven't set logging on any rules yet, so you won't see anything on pflog.
At the least, set logging on the block rules like this:

Code:

block drop log all
block in log quick from <abusers>

The log statement goes directly after the direction keyword (in or out) or after the action keyword (block, pass, rdr etc) if you aren't stating a direction. Then you will find out what is happening to your packets.
Unless you are handling gigabytes per second through your firewall, you should always log blocked packets

__________________The only dumb question is a question not asked.
The only dumb answer is an answer not given.

well i don't have the time, patience, or hair to be trying to figure this out, i was hoping for more help, but got none. I have a new cable connection being installed next week and imma just run web server from that connection, that way i dont have to waste my time. BTW like i said i didnt post my updated pf.conf thats shows i have log put in every rule.

i'm not here to become an expert and i know you dont have to help me. I've tried the best to my ability to resolve this issue, which i cant. I've read many online texts and have read the PF man many times. I figure seeing as how many of you are sitting on the answer to my issue, i didn't realize that anyone had a issue with helping someone with less knowledge. Like i said i'm not trying to become an expert, i have better things to do with my time, i just wanted a lil more help than these cryptic answers. I really thought this forum was better than this elitist attitude i got.

The default gateway of the box receiving the redirected traffic should be correct.

If you redirect traffic to the internal LAN, the internal NIC of the firewall should be set as the default gateway.
In case you use a DMZ the DMZ NIC of the firewall is the default gateway.

If you forget this, like I did a couple of times, tcpdump will not show any blocked packets. Running tcpdump on the server NIC will even show the packets coming in.The server just doesn't know how to route the it's answer packets.

__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

I don't understand why so many people who are new to OpenBSD/pf create(..copy&paste) unimaginably complex rulesets without first confirming they work in their specific setup.

You should always start simple, which will be beneficial.. especially if you're just learning.

Please don't insult people birdman, if you're just going to criticize support from volunteers.. there are other less social ways to learn about pf, I managed to create my first ruleset by reading the man pages, the pf FAQ.. and Peter's tutorial.

I figure seeing as how many of you are sitting on the answer to my issue...

That expectation is incorrect, in two different ways:

No one is holding back knowledge from you. There is no single answer to a particular PF configuration problem, ever. And the information you posted has been limited, and misleading. The latter may have been unintentional, but your repost of a configuration that could not possibly be used with tcpdump, along with a summary of tcpdump results was confusing. It confused robbak, and it confused me. I assume it was confusing to others reading the thread as well.

There aren't *many* OpenBSD users here. The number of OpenBSD users who regularly answer OpenBSD-related questions on this forum number around a dozen people. And none of them camp on the forum 7x24 waiting for problem reports to appear, so I would bet that only a handful of the regulars have even seen your thread. (That's not to say that FreeBSD users who are also PF users couldn't provide assistance, with the understanding that the PF implementations of the two OSes are actually quite different.) This is one of the reasons I recommended misc@ -- your post would be seen by thousands of users, with perhaps hundreds who could assist you, rather than the tiny community here.

Quote:

... i didn't realize that anyone had a issue with helping someone with less knowledge... I really thought this forum was better than this elitist attitude i got...

None of us mind helping others; that's why we're here. Unfortunately, you are misinterpreting confusion over your problem description, our attempts to uncover more about the problem, and our suggestions for additional problem source identification, in order to assist you, as "elitist attitude." You misunderstand, and your expectations of our abilities are also unrealistic.

A post by Nick Holland on misc@ just a couple of hours ago, to another user who also had unmet expectations, is apropos. Nick said to him:

Quote:

Don't waste people's time. As the asker of the question, expect to spend AT LEAST as much time (and more likely, many times as much time) investigating and describing your problem as you expect others to spend helping you for free.

...However, if you want to enable more specific filtering options such as synproxy, modulate state, etc. you'll still have to use a dedicate pass rule as these options don't fit into redirection rules.

The default gateway of the box receiving the redirected traffic should be correct.

If you redirect traffic to the internal LAN, the internal NIC of the firewall should be set as the default gateway.
In case you use a DMZ the DMZ NIC of the firewall is the default gateway.

If you forget this, like I did a couple of times, tcpdump will not show any blocked packets. Running tcpdump on the server NIC will even show the packets coming in.The server just doesn't know how to route the it's answer packets.

I have 2 internal nics, 1 wireless other wired on initial setup if my gateway was setup for the wired nic IP the wireless would not access internet but wired would. I changed gateway to other nic's IP and both were able to access internet. That problem was solved. Should i set my gateway to the IP of external nic???? not sure of the implications of doing so, so i haven't.

Quote:

I don't understand why so many people who are new to OpenBSD/pf create(..copy&paste) unimaginably complex rulesets without first confirming they work in their specific setup.

You should always start simple, which will be beneficial.. especially if you're just learning.

I didnt think this was that complex considering the scope of PF's abilities. BTW i didnt copy and paste either so thank you for the assumption. This pf.conf has been working for me for quite a while and the only thing that was added was the
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80
pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA

You mention that it was a large message which probably means that you had spent some amount of time to construct it. vBulletin (the forum software used here...), will drop connections which lie dormant for some amount of time. I don't know what is the exact amount of time which times out connections, but you can save your work going back one page (typically with the Back button...), followed by cutting & pasting into yet another new message.

I don't believe this rule will ever match a packet. The incoming traffic is destined for the IP address of your OpenBSD router on em0; there will normally never be an incoming packet from em0 (the Internet) destined for 192.168.0.10, that is an RFC 1918 address.

This should cause a redirect of TCP and UDP traffic on em0, with a destination port 80, towards 192.168.0.10, as you intended. That traffic is passed IN, as you intend, due to the "pass" in the rdr rule. (If I recall correctly, UDP is not used with http protocol, so any UDP traffic will be ignored by the web server. You should be able to safely remove UDP from your rdr rule.)

However, the redirected traffic needs its own pass rule. That's because you are running NAT, which changes the destination address from your IP address on the Internet to 192.168.0.10. I would add a rule something like:

Quote:

pass out log on $int_if from any to $server port 80

As I stated initially, PF doesn't know which of your interfaces is internal or external, and "in" and "out" are directions in and out of your NICs. This outbound pass rule goes *out* of your OpenBSD router, but towards your internal LAN.