Port forwarding through pf

tedbell

Active Member

Reaction score: 115
Messages: 238

I am using Trihexagonals pf.conf ( https://forums.FreeBSD.org/threads/firewall-for-home-user.63277/post-365628) but I want to forward ports through it while keeping his bulletproof settings. Does my conf look okay? I am not sure if I am using rdr correctly.

Code:
### Macro name for external interface
ext_if = "wlan0"
netbios_tcp = "{ 22, 23, 25, 80, 110, 111, 123, 512, 513, 514, 515, 6000, 6010 }"
netbios_udp = "{ 123, 512, 513, 514, 515, 5353, 6000, 6010 }"

### Macros to define the set of TCP and UDP ports to open.
### Add additional ports or ranges separated by commas.
### UDP 60000-60010 is mosh control http://mosh.mit.edu/
myservices = "{ 54304, 54305 }"
#icmp_types = "echoreq"
mycomp="127.0.0.1"

### Modulate the initial sequence number of TCP packets.
### Broken operating systems sometimes don't randomize this number,
### making it guessable.
tcp_state="flags S/SA keep state"
udp_state="keep state"

### Don't send rejections. Just drop.
set block-policy drop

### Reassemble fragmented packets
scrub in on $ext_if all fragment reassemble

rdr pass log on $ext_if proto { tcp } from any to any port $myservices -> $mycomp
#rdr pass log on $ext_if proto { tcp, udp } from any to any port $myservices -> $mycomp

### Default deny everything
block log all

### Pass loopback
set skip on lo0

### Block spooks
antispoof for lo0
antispoof for $ext_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $ext_if from any to 255.255.255.255
block in log quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any

### Block all IPv6
block in quick inet6 all
block out quick inet6 all

### Block to and from port 0
block quick proto { tcp, udp } from any port = 0 to any
block quick proto { tcp, udp } from any to any port = 0

### Block specific ports
block in quick log on $ext_if proto tcp from any to any port $netbios_tcp
block in quick log on $ext_if proto udp from any to any port $netbios_udp

### Keep and modulate state of outbound tcp, udp and icmp traffic
pass out on $ext_if proto { tcp, udp, icmp } from any to any modulate state

### Drop broadcast requests quietly.
block in quick on $ext_if from any to 255.255.255.255

Thanks
 

Trihexagonal

Daemon

Reaction score: 1,321
Messages: 1,933

I'm glad you're happy with it and hopes it works well for you, but Sir Dice or someone else will have to give you the right answer. I work to keep them out and have never used port forwarding and disallow portmap from /etc/rc.conf.

portmap_enable="NO"
 
OP
tedbell

tedbell

Active Member

Reaction score: 115
Messages: 238

OK thanks. It seems to be working ok for me. Just wanted to make sure with the experts. :)
 

Deviant0ne

New Member

Reaction score: 3
Messages: 11

Using your configuration file as an example, my port forwarding rule is slightly different (though your rule should work fine):

Code:
rdr on $ext_if proto tcp from any to ($ext_if) port $myservices -> $mycomp
 

Mjölnir

Daemon

Reaction score: 1,148
Messages: 1,657

IIRC it's common to deny x11/6000+ a handfull, because your X11 greeter opens the next port for each network session. This could easily happen on accidental misconfiguration, doesn't have to be yours, could be the port maintainer's mistake or upstream. Thus I'd recommend to include the full official list 6000-6063 (maybe even 6000-6100) in you lists of delicate ports falsely named netbios_xxx. The latter is a minor flaw, you can easily rename the lists. Names are nothing but smoke and mirrors.
 
OP
tedbell

tedbell

Active Member

Reaction score: 115
Messages: 238

IIRC it's common to deny x11/6000+ a handfull, because your X11 greeter opens the next port for each network session. This could easily happen on accidental misconfiguration, doesn't have to be yours, could be the port maintainer's mistake or upstream. Thus I'd recommend to include the full official list 6000-6063 (maybe even 6000-6100) in you lists of delicate ports falsely named netbios_xxx. The latter is a minor flaw, you can easily rename the lists. Names are nothing but smoke and mirrors.
Thanks for that. I didn't know that. I will add those ports and change the macro names. :)
 
OP
tedbell

tedbell

Active Member

Reaction score: 115
Messages: 238

Using your configuration file as an example, my port forwarding rule is slightly different (though your rule should work fine):

rdr on $ext_if proto tcp from any to ($ext_if) port $myservices -> $mycomp
Cool. I will try your solution and see the results.

EDIT: My ports only opened up when I had "rdr pass log on..." Is that normal?

Code:
rdr pass log on $ext_if proto tcp from any to ($ext_if) port $myservices -> $mycomp
 

Mjölnir

Daemon

Reaction score: 1,148
Messages: 1,657

If you did not already, you may want to take an hour or two -- I recommend to read all again a 2nd time after a day or two -- to RTFM pf.conf(5). The invaluable benefit is the feeling of enlightenment when you can explain to yourself the questions you had yesterday. It's like sex, but lasts much longer. Excerpt:
TRANSLATION
Translation rules modify either the source or destination address of the
packets associated with a stateful connection. A stateful connection is
automatically created to track packets matching such a rule as long as
they are not blocked by the filtering section of pf.conf. The
translation engine modifies the specified address and/or port in the
packet, recalculates IP, TCP and UDP checksums as necessary, and passes
it to the packet filter for evaluation.

Since translation occurs before filtering, the filter engine will see
packets as they look after any addresses and ports have been translated.
Filter rules will therefore have to filter based on the translated
address and port number. Packets that match a translation rule are only
automatically passed if the pass modifier is given, otherwise they are
still subject to block and pass rules.


EDIT it's perfectly normal to not understand all completely on the 1st read, maybe not on the 2nd or 3rd. And if it's still all Greek to you, we'll help you anyway.
 
OP
tedbell

tedbell

Active Member

Reaction score: 115
Messages: 238

If you did not already, you may want to take an hour or two -- I recommend to read all again a 2nd time after a day or two -- to RTFM pf.conf(5). The invaluable benefit is the feeling of enlightenment when you can explain to yourself the questions you had yesterday. It's like sex, but lasts much longer. Excerpt:
TRANSLATION
Translation rules modify either the source or destination address of the
packets associated with a stateful connection. A stateful connection is
automatically created to track packets matching such a rule as long as
they are not blocked by the filtering section of pf.conf. The
translation engine modifies the specified address and/or port in the
packet, recalculates IP, TCP and UDP checksums as necessary, and passes
it to the packet filter for evaluation.

Since translation occurs before filtering, the filter engine will see
packets as they look after any addresses and ports have been translated.
Filter rules will therefore have to filter based on the translated
address and port number. Packets that match a translation rule are only
automatically passed if the pass modifier is given, otherwise they are
still subject to block and pass rules.


EDIT it's perfectly normal to not understand all completely on the 1st read, maybe not on the 2nd or 3rd. And if it's still all Greek to you, we'll help you anyway.
Wow thanks for that. :D
They weren't kidding about how powerful this firewall is!
 

Trihexagonal

Daemon

Reaction score: 1,321
Messages: 1,933

That was just the name I gave the macros when I created the ruleset, I have no idea how many years ago. He just changed it a little to suit his purposes.

ConSeal PC Firewall, a ruleset based Win98 firewall, was the first piece of software I loved and what I thought of in the macro naming. The port 0 rule carried over from my ruleset then to pf.
 
Top