2

I am unable to make port 80 available on the WAN and I am not sure why.

My setup is just my home network acting as the wan and my ‘lab’ as the lan. Wan 192.168.0.0/24 and lan is 192.168.5.0/24. Router wan interface is 192.168.0.113 and the lan interface is 192.168.5.1. The web server is at 192.168.5.17 and I am trying to forward port 80 on 192.168.0.133. to make it available on the wan. I put the current version of the rules and the pf logs below. It looks to me like it is just not redirecting the traffic and I do not know why. Any help is appreciated, if you need more info I would be happy to provide it. Thanks!

Oh and the ssh rule works fine I guess b/c it just uses the wan interface and doesn’t redirect to another machine.

Also also I have tried the last rule with and without port 80 rdr-to 192.168.5.17 and I get the same error

I tried to include the pflog info but stack exchange said it was spam...

#no need to run rules on the loop back int
set skip on lo

#macro to set the external int to em0
ext_if = "em0"

#macro to set the internal int to the other eth int
int_if = "re0"

#macro for the webserver
web_server = "192.168.5.17"

#making table for people that we want to block
table <badguys> persist file "/etc/badguys"
block quick from <badguys>

#naming specific trusted IPs
trusted = "{ 192.168.0.155 }"

#blocking all inbound and outbound ip6 traffic
block inet6

#default policy, remember pf is a last match application unless you use quick
block all

#this is for passing and taging all internal traffic
pass in on $int_if tag ALLOWED

#perform NAT
match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if)

#pass out all of the packets that were tagged
pass out on $ext_if tagged ALLOWED

#allows traffic out from the host
pass out from { ($ext_if),$int_if }

#rule to let in ssh
pass in on $ext_if proto tcp from {192.168.0.0/24 $trusted} to {192.168.0.113} port 22 flags S/SA keep state \
                       (max-src-conn 5, max-src-conn-rate 5/5, \
                                  overload <badguys> flush global)

#trying to forward http

pass log on $int_if from 192.168.5.17 to any binat-to 192.168.0.113
pass in log on $ext_if proto tcp from any to 192.168.0.113 port 80 rdr-to 192.168.5.17
13
  • Jul 24 21:55:12.985868 rule 9/(match) match in on em0: 192.168.0.155.47262 > 192.168.0.113.80: S 570634302:570634302(0) win 64240 <mss 1460,sackOK,timestamp 2569937712 0,nop,wscale 7> (DF) Jul 24 21:55:46.266511 rule 9/(match) match in on em0: 192.168.0.155.47262 > 192.168.0.113.80: S 570634302:570634302(0) win 64240 <mss 1460,sackOK,timestamp 2569970992 0,nop,wscale 7> (DF) Commented Jul 25, 2022 at 17:29
  • There we go, that is the log info Commented Jul 25, 2022 at 17:30
  • I do not think the binat-to rule is really required. What you need is to just redirect http from any to the 0.133:80 to the 5.17:80 which can be expressed by modifying the rdr-to rule (last one). Give it a try! Commented Jul 25, 2022 at 18:53
  • Jul 25 14:40:12.849459 rule 9/(match) pass in on em0: 192.168.0.155.57106 > 192.168.0.113.80: S 1652474580:1652474580(0) win 64240 <mss 1460,sackOK,timestamp 2587618483 0,nop,wscale 7> (DF) Commented Jul 25, 2022 at 19:42
  • I changed the rule to: pass in log on $ext_if proto tcp from any to 192.168.0.113 port 80 rdr-to 192.168.5.17 and got the log entry above but no website. Also thanks for the help! Commented Jul 25, 2022 at 19:43

1 Answer 1

1

You don't need the binat rule.

pass in on $ext_if proto tcp to $(ext_if) port 80 rdr-to 192.168.5.17
pass out on $int_if proto tcp to 192.168.5.17 port 80

should suffice. Note that this last rule is not covered by

pass out from { ($ext_if),$int_if }

because the redirected package does not come from $ext_if's IP address nor from the $int_if.

Since you are more or less in control of what happens on the host, adding a simple pass out rule (i.e. filtering only incoming traffic both on WAN and LAN) and getting rid of all other pass out ... rules might make things simpler, in general.

Using tcpdump on both external and internal interfaces to see whether the packages (and their replies) are actually forwarded and redirected/NATed might help. I also recommend doing the same on the webserver.

Also, lookout for routing issues. Make sure that the webserver knows where to send its replies to. In your example, if it knows that 192.168.5.1 is the gateway for packets destined to 192.168.0.0/24 (or even its default gateway).

4
  • That was it! I will have to remember that I can use tcp dump and do a packet capture rather than just reading the PF logs with it. Thanks! Commented Jul 27, 2022 at 2:29
  • @zé-loff, I am curious about why the second rule is necessary. Does not pf create state allowing reverse way from the first one across the entire device, not limited to the $ext-if ? Commented Jul 27, 2022 at 7:25
  • @BrahimGaabab yes, it does, but its a different interface, you have to explicitly allow it to go out on $int_if. The created states make it unnecessary to create pass out rules for the replies (i.e. out of $ext_if back to the client, and in $int_if from the server), but not for establishing the connections on both _ifs. Commented Jul 27, 2022 at 7:39
  • Thank you @zé-loff. I understand. Filtering in pf happens at interfaces rather on chains as in netfilter! Commented Jul 27, 2022 at 9:06

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.