PF Port forwarding not working - how to fix it?

Hi,

I am using a FreeBSD 13.0 box as internet router/gateway. The hardware has two physical NICs, one is for the internal net, the other goes to my DSL connection.

vtnet0 is my internal network interface, tun0 my external for PPPoE.

What I am trying to achieve is to forward all incoming traffic to external ip address TCP port 5060 to an internal host, and this does not work. Firewall used is PF.

What I am missing here in my below rule set? A connection test from an external IP leads to "connection refused", while on the local machine port 5060 definitely is up and running.

Code:
#################################
#### Packet Firewall Ruleset ####
#################################

###################
#### Variables ####
###################

# External interface
ext_if="tun0"

# Internal interface
int_if="vtnet0"

# Follow RFC1918 and don't route to non-routable IPs
# http://www.iana.org/assignments/ipv4-address-space
# http://rfc.net/rfc1918.html
nonroute= "{ 0.0.0.0/8, 20.20.20.0/24, 127.0.0.0/8, 169.254.0.0/16,
        172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 224.0.0.0/3,
        255.255.255.255 }"

# Set allowed ICMP types
# Blocking ICMP entirely is bad practice and will break things,
# FreeBSD applies rate limiting by default to mitigate attacks.
icmp_types = "{ 0, 3, 4, 8, 11, 12 }"

####################################
#### Options and optimizations #####
####################################

# Set interface for logging (statistics)
set loginterface $ext_if

# Drop states as fast as possible without having excessively low timeouts
set optimization aggressive

# Block policy, either silently drop packets or tell sender that request is blocked
set block-policy return

# Don't bother to process (filter) following interfaces such as loopback:
set skip on lo0

# Scrub traffic
# Add special exception for game consoles such as PS3 and PS4 (NAT type 2 vs 3)
# scrub from CHANGEME to any no-df random-id fragment reassemble
scrub on $ext_if all

#######################
#### NAT & Proxies ####
#######################

# Enable NAT and tell pf not to change ports if needed
# Add special exception for game consoles such as PS3 and PS4 (NAT type 2 vs 3)
# ie static-port mapping. Do NOT enable both rules.
# nat on $ext_if from $int_if:network to any -> ($ext_if) static-port
nat on $ext_if from $int_if:network to any -> ($ext_if)

# Redirect ftp connections to ftp-proxy
rdr pass log on $ext_if proto tcp from any to ($ext_if) port 5060 -> 192.168.1.162 port 5060

# Enable ftp-proxy (active connections)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"

# Enable UPnP (requires miniupnpd, game consoles needs this)
# rdr-anchor "miniupnpd"

# Anchors needs to be set after nat/rdr-anchor
# Same as above regarding miniupnpd
anchor "ftp-proxy/*"
# anchor "miniupnpd"

################################
#### Rules inbound (int_if) ####
################################

# Pass on everything incl multicast
pass in quick on $int_if inet all keep state

#################################
#### Rules outbound (int_if) ####
#################################

# Pass on everything incl multicast
pass out quick on $int_if inet all keep state

################################
#### Rules inbound (ext_if) ####
################################

# Drop packets from non-routable addresses immediately
block drop in quick on $ext_if from $nonroute to any

# Allow DHCP
pass in quick on $ext_if inet proto udp to ($ext_if) port { 67, 68 }

# Allow ICMP
pass in quick on $ext_if inet proto icmp all icmp-type $icmp_types

# Allow FTPs to connect to the FTP-proxy
pass in quick on $ext_if inet proto tcp to ($ext_if) port ftp-data user proxy

# Block everything else
block in on $ext_if all

#################################
#### Rules outbound (ext_if) ####
#################################

# Drop packets to non-routable addresses immediately, allow everything else
block drop out quick on $ext_if from any to $nonroute
pass out on $ext_if all
 
You need a pass in/out rule for 5060 on ext_if in addition to the redirect.
Code:
     If the pass modifier is given, packets matching the translation rule are
     passed without inspecting the filter rules:
 
I do understand your quote that since my rule is "rdr pass", that I do not need an extra pass rule for that purpose on incoming. Correct?
That is correct. I personally don't like to use rdr pass because it also skips any and all other rules. It means I can't block the incoming traffic anymore (blacklisted IPs for example). So I always split them up.

In order to easily troubleshoot this learn to use tcpdump(1). Let it capture on the ext_if and verify you're actually receiving a SYN packet, then run tcpdump(1) on the internal interface and check if the packet is properly redirected. If that happens then you'll know your firewall rules are working properly and the issue is somewhere else.

tcpdump -ni tun0 tcp and port 5060; tcpdump -ni vtnet0 tcp and port 5060.
 
I just did the tcpdump analysis.

Code:
tcpdump -ni tun0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
11:25:08.887779 IP 148.251.189.213.40102 > 217.82.58.174.5060: Flags [S], seq 3505946891, win 64240, options [mss 1440,sackOK,TS val 2216073585 ecr 0,nop,wscale 7], length 0
11:25:08.887905 IP 217.82.58.174.5060 > 148.251.189.213.40102: Flags [R.], seq 0, ack 3505946892, win 0, length 0

I got no traffic matching this on vtnet0 though then, so this is why I presume the rules are somewhat faulty, because to me it looks like the gateway itself answers instead of my internal host.
 
I got no traffic matching this on vtnet0 though then, so this is why I presume the rules are somewhat faulty,
If you're not seeing the traffic on vtnet0 then yes, I agree. Did you load the ruleset after you made the changes? pfctl -f /etc/pf.conf

because to me it looks like the gateway itself answers instead of my internal host.
Your NAT rule will make everything look like it came from the gateway host.
 
Yes, I checked my ruleset with pfctl -nf /etc/pf.conf, no errors.

Please note that gateway_enable="YES" is also in my rc.conf, and of course net.inet.ip.forwarding=1 in my sysctl.conf as well.

And rule set is up and running.

Code:
root@gateway:/etc # pfctl -s rule
scrub on tun0 all fragment reassemble
anchor "ftp-proxy/*" all
pass in quick on vtnet0 inet all flags S/SA keep state
pass out quick on vtnet0 inet all flags S/SA keep state
block drop in quick on tun0 inet from <__automatic_ad7a787a_0> to any
pass in quick on tun0 inet proto icmp all icmp-type echorep keep state
pass in quick on tun0 inet proto icmp all icmp-type unreach keep state
pass in quick on tun0 inet proto icmp all icmp-type squench keep state
pass in quick on tun0 inet proto icmp all icmp-type echoreq keep state
pass in quick on tun0 inet proto icmp all icmp-type timex keep state
pass in quick on tun0 inet proto icmp all icmp-type paramprob keep state
pass in quick on tun0 inet proto udp from any to (tun0) port = bootps keep state
pass in quick on tun0 inet proto udp from any to (tun0) port = bootpc keep state
pass in quick on tun0 inet proto tcp from any to (tun0) port = ftp-data user = 62 flags S/SA keep state
block return in on tun0 all
block drop out quick on tun0 inet from any to <__automatic_ad7a787a_1>
pass out on tun0 all flags S/SA keep state
root@gateway:/etc # pfctl -s nat
nat on tun0 inet from 192.168.1.0/24 to any -> (tun0) round-robin
nat-anchor "ftp-proxy/*" all
rdr pass log on tun0 inet proto tcp from any to (tun0) port = sip -> 192.168.1.162 port 5060
rdr-anchor "ftp-proxy/*" all
 
Yes, I checked my ruleset with pfctl -nf /etc/pf.conf, no errors.
That only checks the rules, it doesn't load them.

Please note that gateway_enable="YES" is also in my rc.conf, and of course net.inet.ip.forwarding=1 in my sysctl.conf as we.ll.
gateway_enable sets net.inet.ip.forwarding, so you can remove it from sysctl.conf, you don't need to set it twice.
 
My bad, I was not telling you enough, sorry.

Edit: I did a "service pf reload" to be very sure. Now it seems to make some progress.

tcpdump on external interface delivers this:

Code:
tcpdump -ni tun0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
12:15:52.683840 IP 148.251.189.213.40140 > 217.82.58.174.5060: Flags [S], seq 2606289753, win 64240, options [mss 1440,sackOK,TS val 2219117381 ecr 0,nop,wscale 7], length 0
12:15:52.684313 IP 217.82.58.174.5060 > 148.251.189.213.40140: Flags [S.], seq 1448680432, ack 2606289754, win 28960, options [mss 1460,sackOK,TS val 46903501 ecr 2219117381,nop,wscale 7], length 0
12:15:53.695295 IP 148.251.189.213.40140 > 217.82.58.174.5060: Flags [S], seq 2606289753, win 64240, options [mss 1440,sackOK,TS val 2219118392 ecr 0,nop,wscale 7], length 0
12:15:53.695817 IP 217.82.58.174.5060 > 148.251.189.213.40140: Flags [S.], seq 1448680432, ack 2606289754, win 28960, options [mss 1460,sackOK,TS val 46904513 ecr 2219117381,nop,wscale 7], length 0
12:15:54.078899 IP 217.82.58.174.51905 > 217.0.128.133.5060: Flags [S], seq 462350282, win 29200, options [mss 1460,sackOK,TS val 46904896 ecr 0,nop,wscale 7], length 0
12:15:55.086760 IP 217.82.58.174.5060 > 148.251.189.213.40140: Flags [S.], seq 1448680432, ack 2606289754, win 28960, options [mss 1460,sackOK,TS val 46905904 ecr 2219117381,nop,wscale 7], length 0
12:15:55.707322 IP 148.251.189.213.40140 > 217.82.58.174.5060: Flags [S], seq 2606289753, win 64240, options [mss 1440,sackOK,TS val 2219120404 ecr 0,nop,wscale 7], length 0
12:15:55.707889 IP 217.82.58.174.5060 > 148.251.189.213.40140: Flags [S.], seq 1448680432, ack 2606289754, win 28960, options [mss 1460,sackOK,TS val 46906525 ecr 2219117381,nop,wscale 7], length 0

And this is on vtnet0, internal interface:

Code:
tcpdump -ni vtnet0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:16:52.354512 IP 148.251.189.213.40142 > 192.168.1.162.5060: Flags [S], seq 3747836021, win 64240, options [mss 1440,sackOK,TS val 2219177052 ecr 0,nop,wscale 7], length 0
12:16:52.354931 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46963172 ecr 2219177052,nop,wscale 7], length 0
12:16:53.371684 IP 148.251.189.213.40142 > 192.168.1.162.5060: Flags [S], seq 3747836021, win 64240, options [mss 1440,sackOK,TS val 2219178068 ecr 0,nop,wscale 7], length 0
12:16:53.372162 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46964189 ecr 2219177052,nop,wscale 7], length 0
12:16:54.487824 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46965305 ecr 2219177052,nop,wscale 7], length 0
12:16:55.387636 IP 148.251.189.213.40142 > 192.168.1.162.5060: Flags [S], seq 3747836021, win 64240, options [mss 1440,sackOK,TS val 2219180084 ecr 0,nop,wscale 7], length 0
12:16:55.388112 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46966205 ecr 2219177052,nop,wscale 7], length 0
12:16:57.687688 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46968505 ecr 2219177052,nop,wscale 7], length 0
12:16:59.611505 IP 148.251.189.213.40142 > 192.168.1.162.5060: Flags [S], seq 3747836021, win 64240, options [mss 1440,sackOK,TS val 2219184308 ecr 0,nop,wscale 7], length 0
12:16:59.611986 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46970429 ecr 2219177052,nop,wscale 7], length 0
12:17:04.087583 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46974905 ecr 2219177052,nop,wscale 7], length 0
12:17:07.803059 IP 148.251.189.213.40142 > 192.168.1.162.5060: Flags [S], seq 3747836021, win 64240, options [mss 1440,sackOK,TS val 2219192500 ecr 0,nop,wscale 7], length 0
12:17:07.803555 IP 192.168.1.162.5060 > 148.251.189.213.40142: Flags [S.], seq 3041132690, ack 3747836022, win 28960, options [mss 1460,sackOK,TS val 46978621 ecr 2219177052,nop,wscale 7], length 0

So some progress... I guess I should have a closer look now at the rdr and pass parts again.
 
Did you split it up to separate rules? One rdr and a separate pass rule for it?

Redirection and NAT happen before the rules are processed so you'll need to allow:
Code:
pass in on $ext_if from any to 192.168.1.162 port 5060
It will also need to pass on the outgoing interface (you would need this if you do a block all):
Code:
pass out on $int_if from any to 192.168.1.162 port 5060
 
Did you split it up to separate rules? One rdr and a separate pass rule for it?

Redirection and NAT happen before the rules are processed so you'll need to allow:
Code:
pass in on $ext_if from any to 192.168.1.162 port 5060
It will also need to pass on the outgoing interface (you would need this if you do a block all):
Code:
pass out on $int_if from any to 192.168.1.162 port 5060
You are now coming back to my suggestions......
 
You are now coming back to my suggestions......
No, you suggested to add a pass rule when the OP was using rdr pass. There is a difference in rdr and rdr pass. In the case of a rdr pass then all other rules are ignored. You do need a pass rule with a 'regular' rdr.
 
Thank you. I am sure that what you wrote was what I meant not minding if he had used rdr only or rdr pass. I know rdr only and pass in/out for the IP:pORT works.
 
Thank you. I am sure that what you wrote was what I meant not minding if he had used rdr only or rdr pass. I know rdr only and pass in/out for the IP:pORT works.
I have rdr pass, not rdr only, sorry. The private IP above is a jail I suppose. I have a pass in/out for IP:port in addition to the rdr pass.
 
Code:
     # map daemon on 8080 to appear to be on 80
     rdr on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 port 8080

     If the pass modifier is given, packets matching the translation rule are
     passed without inspecting the filter rules:

     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \
           port 8080
pf.conf(5)
 
Thanks for all your feedback so far, really appreciated.

First I rewrote my file from scratch in order to learn more Pf. It is now listed below, and much more basic at the moment. No block rule yet.

As you can see I have changed "rdr pass" to rdr, as suggested and added the pass in and out rules accordingly as well.

Code:
# WAN interface
ext_if = "tun0"

# PBX IP
PBX = "192.168.1.162"

# Options
set loginterface $ext_if
set skip on lo0

# Incoming SIP forwarding to PBX - no pass, so that other rules are
# evaluated
rdr on $ext_if proto {tcp, udp} from any to ($ext_if) port 5060 -> $PBX port 5060

# NAT/port forwarding rules - must appear before filtering rules
nat on $ext_if from $int_if:network to any -> ($ext_if)

# Filtering rules

# Allow incoming SIP forwarding
pass in on $ext_if proto {tcp, udp} from any to $PBX port 5060

# Allow outgoing SIP, just in case
pass out on $int_if proto {tcp, udp} from any to $PBX port 5060

The rule set loads. Unfortunately the port forwarding still does not work after reloading the rules.

I tried a connection to port 5060 from external. This here is the tcpdump log on the FreeBSD box, WAN interface:

Code:
tcpdump -ni tun0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
22:53:37.917969 IP 148.251.189.213.35110 > 91.11.149.175.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243135333 ecr 0,nop,wscale 7], length 0
22:53:37.918731 IP 91.11.149.175.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171568581 ecr 1243135333,nop,wscale 7], length 0
22:53:38.921500 IP 91.11.149.175.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569584 ecr 1243135333,nop,wscale 7], length 0
22:53:38.934542 IP 148.251.189.213.35110 > 91.11.149.175.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243136350 ecr 0,nop,wscale 7], length 0
22:53:38.935108 IP 91.11.149.175.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569597 ecr 1243135333,nop,wscale 7], length 0
22:53:40.950139 IP 148.251.189.213.35110 > 91.11.149.175.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243138366 ecr 0,nop,wscale 7], length 0
22:53:40.950715 IP 91.11.149.175.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171571613 ecr 1243135333,nop,wscale 7], length 0
22:53:43.321430 IP 91.11.149.175.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171573984 ecr 1243135333,nop,wscale 7], length 0

Same machine same traffic but internal network interface:
Code:
tcpdump -ni vtnet0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:53:37.918064 IP 148.251.189.213.35110 > 192.168.1.162.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243135333 ecr 0,nop,wscale 7], length 0
22:53:37.918560 IP 192.168.1.162.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171568581 ecr 1243135333,nop,wscale 7], length 0
22:53:38.921443 IP 192.168.1.162.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569584 ecr 1243135333,nop,wscale 7], length 0
22:53:38.934622 IP 148.251.189.213.35110 > 192.168.1.162.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243136350 ecr 0,nop,wscale 7], length 0
22:53:38.935074 IP 192.168.1.162.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569597 ecr 1243135333,nop,wscale 7], length 0
22:53:40.950225 IP 148.251.189.213.35110 > 192.168.1.162.5060: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243138366 ecr 0,nop,wscale 7], length 0
22:53:40.950637 IP 192.168.1.162.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171571613 ecr 1243135333,nop,wscale 7], length 0
22:53:43.321353 IP 192.168.1.162.5060 > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171573984 ecr 1243135333,nop,wscale 7], length 0

And finally a tcpdump of the same traffic on the target host:

Code:
tcpdump -ni eth0 tcp and port 5060
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:53:38.600743 IP 148.251.189.213.35110 > 192.168.1.162.sip: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243135333 ecr 0,nop,wscale 7], length 0
22:53:38.600815 IP 192.168.1.162.sip > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171568581 ecr 1243135333,nop,wscale 7], length 0
22:53:39.603521 IP 192.168.1.162.sip > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569584 ecr 1243135333,nop,wscale 7], length 0
22:53:39.617178 IP 148.251.189.213.35110 > 192.168.1.162.sip: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243136350 ecr 0,nop,wscale 7], length 0
22:53:39.617237 IP 192.168.1.162.sip > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171569597 ecr 1243135333,nop,wscale 7], length 0
22:53:41.632854 IP 148.251.189.213.35110 > 192.168.1.162.sip: Flags [S], seq 1708616204, win 64240, options [mss 1440,sackOK,TS val 1243138366 ecr 0,nop,wscale 7], length 0
22:53:41.632917 IP 192.168.1.162.sip > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171571613 ecr 1243135333,nop,wscale 7], length 0
22:53:44.003341 IP 192.168.1.162.sip > 148.251.189.213.35110: Flags [S.], seq 3225545325, ack 1708616205, win 28960, options [mss 1460,sackOK,TS val 171573984 ecr 1243135333,nop,wscale 7], length 0

At first glance it looks quite okay for me, but it does not work yet. It tries to send SYN ACK, but the connection never works.

"pfctl -s stat" lists the connection as follows:
Code:
all tcp 192.168.1.162:5060 (91.11.149.175:5060) <- 148.251.189.213:35112       SYN_SENT:ESTABLISHED
all tcp 148.251.189.213:35112 -> 192.168.1.162:5060       ESTABLISHED:SYN_SENT

Furthermore pfctl -Psn -vv lists this, so it forwarded traffic to the target machine.
Code:
pfctl -Psn -vv
No ALTQ support in kernel
ALTQ related functions disabled
@0 nat on tun0 inet from 192.168.1.0/24 to any -> (tun0) round-robin
  [ Evaluations: 1798      Packets: 1886      Bytes: 1162142     States: 27    ]
  [ Inserted: uid 0 pid 1745 State Creations: 38    ]
@0 rdr on tun0 inet proto tcp from any to 91.11.149.175 port = 5060 -> 192.168.1.162 port 5060
  [ Evaluations: 1350      Packets: 12        Bytes: 720         States: 1     ]
  [ Inserted: uid 0 pid 1745 State Creations: 2     ]
@1 rdr on tun0 inet proto udp from any to 91.11.149.175 port = 5060 -> 192.168.1.162 port 5060
  [ Evaluations: 82        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 1745 State Creations: 0     ]
 
I've gained some new insight: I have started a HTTP server on another host in my network, and created a port forwarding rule as above as well.

The HTTP server answers on external requests. So thanks to all of you the rules are working now, the problem must be either on my PBX host or interaction of that machine with the internet itself.
 
I've gained some new insight: I have started a HTTP server on another host in my network, and created a port forwarding rule as above as well.

The HTTP server answers on external requests. So thanks to all of you the rules are working now, the problem must be either on my PBX host or interaction of that machine with the internet itself.
Setting up PBX like that can be a hell of a problem. We've had luck with running freepbx in VM/jail with the vm-bhyve passthrough for a dedicated network interface on host.
 
Jose: yes, I am. Actually I did it exactly that way, also forwarding RTP port ranges and so far it is working as intended, my PBX works fine now. As does the rest of my network.
 
If you run into fun issues (which you probably will) using SIP/VOIP you might want to add something like this.

Code:
set optimization conservative
set timeout { udp.first 300, udp.single 150, udp.multiple 900 }
scrub on $ext_if all no-df fragment reassemble

I would also highly advice to limit both incoming and outgoing rules to relevant netblocks as there are a lot of attacks against SIP/VOIP devices and servers.
 
Thanks, so far it has been working stable for around a day. I though will consider adding your suggested optimisations, diizzy.

At the moment I've got a far more less pressing issue: Pf starts on reboot and the host connects back to the internet automatically, but Pf reads no rules. I have to login to the host manually, run "service pf reload" and then suddenly it reads my rules.

This is in rc.conf, so a little bit strange. Also nothing suspicious in the log files as well.
Code:
pf_enable="yes"
pf_rules="/etc/pf.conf"
pf_flags=""
 
Are you sure that all interfaces are up when pf starts?
They might not and it's the reason why you have "($ext_if)" (backets) in the template you used from the start.
You can also drop pf_flags although you might want to have pf_logd enabled.

"Surrounding the interface name (and optional modifiers) in parentheses changes this behaviour. When the interface name is surrounded by parentheses, the rule is automatically updated whenever the interface changes ts address." - from man pf.conf
 
Back
Top