Ok, i've tried but failed. Damn

[birdmansdomain]

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.

ext_if="em0"
int_if="re0"
wifi_if="ral0"
local_net="{192.168.0.1/24, 192.168.1.1/24}"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

block drop all
block in quick from <abusers>

pass out on $ext_if proto tcp all flags S/SA keep state
pass out on $ext_if proto { udp,icmp } all keep state

pass in quick inet proto icmp all icmp-type $icmp_types keep state
pass in quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA synpro$
pass in quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, m$
pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }

[robbak]

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.

[jggimi]

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:

# tcpdump -neti pflog0 action block

[birdmansdomain]

Ok, "tcpdump -neti pflog0 action pass" shows my connection from remote location, but nothing under block. Which is good?? I have no other problems passing out data with my current config.

 
ext_if="em0"
int_if="re0"
wifi_if="ral0"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

block drop all
block in quick from <abusers>

pass out on $ext_if proto tcp flags S/SA keep state
pass out on $ext_if proto { udp,icmp } keep state

pass in quick inet proto icmp all icmp-type $icmp_types keep state
pass in quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA synproxy state
pass in quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, max-src-conn-rate 15/5, overload <abusers> flush global)

pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }

[robbak]

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:

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

[birdmansdomain]

i just reposted the pf.conf that got cut earlier my pf.conf is logged. the www traffic isn't being blocked. I tcpdump -neti pflog0 action rdr and i can see the traffic

[robbak]

OK, you can see it hitting the rdr rule, but that 'action rdr" will stop you seeing if the traffic is hitting the block rules.

If that is your pf.conf posted above then you have no log statements anywhere. As far as i am aware, tcpdum pflog should show nothing.

[birdmansdomain]

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.

[jggimi]

i was hoping for more help, but got none.

See d2 in http://www.daemonforums.org/showthread.php?t=596 -- you may find d1, e1, and e2 informative, as well.

Allow me to refer to you to the misc@ mailing list. The OpenBSD community here is relatively tiny in comparison.

[birdmansdomain]

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.

[J65nko]

I don't understand why you are too lazy to post your updated pf.conf. I you want people to help you, you should help those people

The following two rules are enough to redirect ssh traffic.

EXT_IF = bge0

set skip on lo0

rdr on $EXT_IF inet proto tcp  from any to any  port 55555 tag SSH -> 192.168.222.11 port 22

# default policy
block log all

pass in quick on $EXT_IF tagged SSH

When testing redirection there are two issues most people run into:

• Testing from the internal LAN
  
  As explained in http://www.openbsd.dk/faq/pf/rdr.html#reflect accessing the external IP from the internal LAN does not cause redirection to work.
  You, or a friend, really needs to test from the Internet side.
  
• Routing
  
  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.

[BSDfan666]

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.

[jggimi]

Originally Posted by birdmansdomain

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

That expectation is incorrect, in two different ways:

1. 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.
2. 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.

... 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:

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.

[jggimi]

And, while you may have given up, a user on misc@ just reported that his redirection problem was due to using synproxy. Yours might be, also.

His post:
http://marc.info/?l=openbsd-misc&m=124715215831478&w=2

Thread start:
http://marc.info/?l=openbsd-misc&m=124700148528406&w=2

That resolution makes some sense, because http://openbsd.rt.fm/faq/pf/rdr.html says:

...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.

[birdmansdomain]

Testing from the internal LAN

As explained in http://www.openbsd.dk/faq/pf/rdr.html#reflect accessing the external IP from the internal LAN does not cause redirection to work.
You, or a friend, really needs to test from the Internet side.

I have been testing externally the whole time

Routing

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.

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

the original pf.conf i created was from reading the pf man pages.

Isn't "pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA" a dedicated pass rule????

Also i apologise for my attitude this has made me really pissy past day. Anyways heres my pf.conf WITH log put in there for some of you.

ext_if="em0"
int_if="re0"
wifi_if="ral0"
server="{ 192.168.0.10 }"
icmp_types="echoreq"
tcp_flags="flags S/SA keep state"
table <abusers> persist file "/etc/ssh-violate"

set require-order no
set skip on lo
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

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

pass out log on $ext_if proto tcp from any to any flags S/SA
pass out log on $ext_if proto { udp,icmp } from any to any

pass in log quick inet proto icmp all icmp-type $icmp_types
pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA
pass in log quick on $wifi_if proto tcp to ($wifi_if) port ssh $tcp_flags (max-src-conn 8, max-src-conn-rate 15/5, overload <abusers> flush global)

pass quick on { lo, $int_if, $wifi_if }

antispoof quick for { lo, $int_if, $ext_if, $wifi_if }

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33204
priority: 0
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5


re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:18:e7:18:3d:34
priority: 0
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::218:e7ff:fe18:3d34%re0 prefixlen 64 scopeid 0x1


em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:60:47:d3:9c
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet6 fe80::20d:60ff:fe47:d39c%em0 prefixlen 64 scopeid 0x2
inet *.*.*.* netmask 0xfffffc00 broadcast 255.255.255.255


ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:1d:6a:3a:48:66
priority: 0
groups: wlan
media: IEEE802.11 autoselect hostap
status: active
ieee80211: nwid Phreaks chan 2 bssid 00:1d:6a:3a:48:66
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::21d:6aff:fe3a:4866%ral0 prefixlen 64 scopeid 0x3


pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
priority: 0
groups: pflog

[ocicat]

Originally Posted by birdmansdomain

Ummm how come it wouldnt post my post?????????

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.

[birdmansdomain]

yeh tried again and apparently all my posts have to be monitored by an admin now. Though it seems quick reply works.

[Carpetsmoker]

Problem was the spam filter -- False positive.
The first ten posts of new users are scanned for spam.

It seems to dislike message with significant code/config files/shell examples and markes those as spam ...

In any case, your post is displayed now.

[jggimi]

I believe you have two problems. #1:

pass in log quick on $ext_if proto { tcp udp } from any to $server port 80 flags S/SA

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.

#2:

rdr pass on $ext_if proto { tcp udp } from any to any port 80 -> $server port 80

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:

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.

[jggimi]

On second thought, and another review of your pf.conf .... #2 may not be necessary, as you have

pass quick on { lo, $int_if, $wifi_if }

I'm not sure why "lo" works for you without error, your loopback virtual NIC is "lo0". And the set skip rule, if it works, means that the loopback interface need not be included in this pass rule.

If your problem isn't isolated and resolved by someone else today, I will recreate your environment and test your specific pf.conf tonite (US EDT).