Firewall → Settings → Advanced → Disable reply-to on WAN rules → check → Save → Apply.

Symptom: a port-forward or WAN rule answers from any internet IP, but from a host that lives in the same subnet as the firewall’s WAN everything times out (SSH, HTTPS, even ping), even though the rule says from any.

With a single WAN this is safe: the firewall stops forcing replies through the gateway and goes back to its routing table.

The setup

1
2
3
4
5
6
7
8

                203.0.113.0/24  (same L2 segment)
   ┌────────────────────┬────────────────────┬────────────────────┐
   │                    │                    │                    │
 gateway             fw01 (OPNsense)      neighbor             internet
 203.0.113.1         WAN 203.0.113.40     203.0.113.50         (via gateway)
                        │ rdr :22 → 192.168.1.10
                        ▼
                     LAN server

• From the internet: ssh -p 22 203.0.113.40 reaches the LAN server. Fine.
• From neighbor (203.0.113.50): every port times out.

What reply-to does

OPNsense generates the rules on WAN-type interfaces (those with a gateway) with reply-to pointing at that gateway:

1

pfctl -sr | grep reply-to

1

pass in quick on vtnet0 reply-to (vtnet0 203.0.113.1) inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

reply-to is a pf option. When a packet comes in and creates a state, pf records in that state that every reply must leave through vtnet0 toward 203.0.113.1. Those replies skip the routing table: pf picks the next hop on its own.

It exists for multi-WAN. If you have two providers and a client comes in on WAN2, the reply must leave through WAN2. If it leaves through the default route (WAN1), it carries a source IP that provider 1 does not recognize and gets lost. reply-to guarantees a symmetric return path without thinking about routes.

Why it breaks neighbors

For an internet client, “reply to the gateway” is exactly what the routing table would do anyway, so nothing looks wrong.

For the neighbor it is different. Its IP (203.0.113.50) is on a connected network of the firewall. Without reply-to, the firewall would ARP for its MAC and answer directly. With reply-to, the SYN-ACK leaves with the gateway’s MAC as destination:

1
2

# on the OPNsense box (csh shell: wrap in sh -c)
sh -c "tcpdump -lnei vtnet0 host 203.0.113.50 and tcp port 22"

1
2

<neighbor-mac> > <fw01-mac>          203.0.113.50.49612 > 203.0.113.40.22: Flags [S]    ← arrives directly
<fw01-mac>     > 00:00:5e:00:01:<vrid> 203.0.113.40.22 > 203.0.113.50.49612: Flags [S.]   ← leaves to the gateway

(00:00:5e:00:01:xx is the VRRP virtual MAC: the gateway was a redundant pair.)

From there it depends on the gateway. To it, the packet arrives on the same interface it would have to leave through, and if it runs a stateful filter it sees a SYN-ACK for a connection whose SYN it never saw. In the lab, the gateway simply did not send it back onto the segment. On the neighbor you only see retried SYNs and no [S.].

The fingerprint on the firewall is a half-open state:

1

pfctl -ss | grep 203.0.113.50

1

all tcp 192.168.1.10:22 (203.0.113.40:22) <- 203.0.113.50:57792   SYN_SENT:ESTABLISHED

The server already answered (ESTABLISHED) and the client is still waiting (SYN_SENT): the reply is lost on the way back, not on the way in. The filter is not blocking anything.

What the fix changes

With Disable reply-to on WAN rules checked, OPNsense regenerates the rules without reply-to:

1

pass in quick on vtnet0 inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

The state no longer pins the next hop, so replies go through the normal routing table:

The last row is the cost. With multi-WAN, do not disable it globally. Instead, drop reply-to only on the affected port-forward’s rule: in the rule, Advanced → reply-to. Check which options your version offers.

Verify

1
2
3

# on the OPNsense box
sh -c "pfctl -sr | grep -c reply-to; grep -n disablereplyto /conf/config.xml"
# expected: 0  and  <disablereplyto>yes</disablereplyto>

1
2

# from the neighbor
nc -z -w5 203.0.113.40 22 && echo open

Traps

• “Disable force gateway” is not this. It sits on the same page with a similar name, but it only affects traffic originated by the firewall itself (DNS, NTP, updates). It does not touch replies to inbound traffic.
• A static route on the gateway does not help. The gateway already has the subnet as connected; the problem is that it will not send the packet back onto the same segment, not that it does not know the way.
• csh shell. Over SSH, OPNsense drops you into csh, and things like 2>/dev/null fail with Ambiguous output redirect. Use sh -c "..." or ssh root@fw01 sh <<'EOF'.
• Test every port, not one. If only one port fails it is a different problem (rule, NAT, service). If they all fail, ping included, and only from the same subnet, suspect reply-to.

See also

• OPNsense docs, firewall settings: https://docs.opnsense.org/manual/firewall_settings.html
• pf.conf(5), route-to / reply-to options: https://man.freebsd.org/cgi/man.cgi?query=pf.conf

1
2
3
4
5
6
7
8
9

pfctl -sT                                    # loaded tables
pfctl -t <table> -T show                     # contents
pfctl -t <table> -T add 192.168.1.10         # add an IP or network (10.20.0.0/16 works too)
pfctl -t <table> -T delete 192.168.1.10
pfctl -t <table> -T test 192.168.1.10        # is it inside? (match / no match)
pfctl -t <table> -T flush                    # empty the table
pfctl -t <table> -T replace -f /path/list    # replace the whole contents from a file

pfctl -t sshguard -T flush                   # pfSense: clear the failed-login lockout

What a table is

A PF table is a set of addresses and networks that rules reference as <name>. It changes live, without reloading the ruleset, and holds thousands of entries with fast lookups; that is why PF uses tables for block lists, bogons, and anything that changes more often than the rules.

In pf.conf:

1
2

table <blocklist> persist file "/etc/pf/blocklist.txt"
block in quick from <blocklist>

persist keeps the table even when no rule uses it at the moment; file loads it from a file (one IP or network per line).

Commands

All in the form pfctl -t <table> -T <command>:

And without -t:

1
2
3
4

pfctl -sT                    # names of all tables
pfctl -vvsT                  # global info per table: entries, evaluations, references
pfctl -T load -f /etc/pf.conf   # reload only the table definitions from pf.conf
pfctl -sr | grep '<name>'    # which rules use a table

Tables on pfSense

• Aliases are tables. A Host, Network, or URL Table alias called Admins exists in PF as <Admins>; pfctl -t Admins -T show shows what pfSense resolved, including the FQDNs it already turned into IPs.
• sshguard: where IPs blocked for failed SSH or webGUI logins land. If you locked yourself out, pfctl -t sshguard -T flush (documented by Netgate under Locked out of the WebGUI).
• virusprot: hosts blocked for exceeding a rule’s Max. src. conn. rate or Max. states limits. pfctl -t virusprot -T show and -T delete <ip> to release one.
• snort2c: Snort/Suricata blocks in legacy mode. -T flush to unblock everything.
• bogons / bogonsv6: the lists that update themselves when you enable Block bogon networks on an interface.
• pfBlockerNG: every list is a pfB_* alias. To know whether an IP is blocked by one: pfctl -t pfB_Top_v4 -T test 203.0.113.7.

On OPNsense the mechanics are the same (pfctl -sT to see the names); the login lockout table is called sshlockout.

What gets lost on reload

Any -T add, -T delete, or -T flush lives until the next filter reload: saving almost anything in the GUI, Filter Reload under Status → Filter Reload, or the alias update cron. At that point pfSense regenerates every table from its alias and your manual changes are gone. To make something permanent, edit the alias; for quick tests and unblocking, pfctl is perfect.

Beyond tables

What gets used most alongside the above:

1
2
3
4
5
6
7

pfctl -sr                    # loaded rules (with -vv, counters and rule numbers)
pfctl -ss                    # state table
pfctl -si                    # global statistics
pfctl -k 192.168.1.10        # kill a host's states
pfctl -F states              # kill all states (cuts every connection)
pfctl -d / pfctl -e          # disable / enable PF (no PF means no NAT: only to get out of a lockout)
pfctl -nf /etc/pf.conf       # syntax check without loading

Full reference: the OpenBSD Handbook’s pfctl cheat sheet and man pfctl on FreeBSD.

Clean option (split DNS): Services → DNS Resolver → Host Overrides → app.example.com → the server’s internal IP (192.168.1.50). LAN clients must use the firewall as their DNS.

NAT reflection option: System → Advanced → Firewall & NAT:

• NAT Reflection mode for port forwards: Pure NAT
• Enable NAT Reflection for 1:1 NAT: ✔
• Enable automatic outbound NAT for Reflection: ✔

Save and test from a LAN client against the public IP.

The problem

The port forward WAN:443 → 192.168.1.50:443 works from the Internet. From a machine on the same LAN, https://app.example.com (which resolves to the public IP) answers with the pfSense GUI, a certificate error, or Potential DNS Rebind attack detected.

The packet leaves the client towards the public IP, reaches the firewall through the LAN interface, and stops there: the port forward rule listens on the WAN, not the LAN, and the destination IP is one of the firewall’s own addresses. It never “goes out and comes back in”.

Option 1: split DNS

This is what Netgate recommends: the name resolves to the internal IP inside and to the public one outside. Traffic goes direct, the server sees the client’s real IP, and the firewall touches nothing.

1. Services → DNS Resolver → Host Overrides → Add: host app, domain example.com, IP 192.168.1.50. If the service has several names, add Additional Names.
2. Clients must use the firewall as DNS (the norm if DHCP hands it out). A client with 8.8.8.8 hardcoded will keep going to the public IP.
3. nslookup app.example.com from the LAN → 192.168.1.50.

Requirement: the internal and external ports must be the same (if outside you forward 8443 → 443, the internal client will have to use 443 directly).

If you run the DNS Forwarder (dnsmasq) instead of the Resolver, the equivalent setting is under Services → DNS Forwarder → Host Overrides.

Option 2: NAT reflection

When you do not control the clients’ DNS, or there are lots of ports, the firewall can “reflect” the connection: it rewrites the destination to the internal IP and, with automatic outbound NAT, the source too, so the reply comes back through the firewall.

System → Advanced → Firewall & NAT, Network Address Translation section:

It can also be enabled per rule: Firewall → NAT → Port Forward → edit → NAT reflection → Enable (Pure NAT), leaving the global setting on Disable.

Costs: the server sees the firewall’s LAN IP as the source (not the client’s), and all that traffic crosses the firewall even when client and server sit on the same switch.

OPNsense

Same idea, other menus:

• Split DNS: Services → Unbound DNS → Overrides → Host Overrides.
• Reflection: Firewall → Settings → Advanced → Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection.

Traps

• DNS rebinding. If instead of a host override you point the Resolver at an external DNS that returns private IPs (an internal DNS at another site, a provider with views), Unbound drops those answers as rebinding protection. Do not untick Disable DNS Rebinding Checks under System → Advanced → Admin Access: add private-domain: "example.com" under Services → DNS Resolver → Custom options and only that domain is exempt.
• A client with hardcoded DNS bypasses split DNS. Either force it through DHCP, catch it with a port 53 NAT rule, or use reflection.
• Pure NAT needs to know the interface and gateway when rules load; with dynamic WANs that change IP, a Filter Reload after the IP change fixes it.
• Different ports inside and outside only work with reflection; split DNS does not translate ports.
• Certificates: with split DNS the browser still sees app.example.com, so the server’s certificate works as is. When reflecting through the public IP, too. The certificate error at the start was the firewall GUI’s, not the server’s.

References: Port Forwards from Local Networks and NAT Reflection in the Netgate documentation.

System → Advanced → Networking → Disable hardware checksum offload ✔ → Save → reboot the VM. The GUI does not say so, but the change does not apply to vtnet interfaces until the reboot.

To test without rebooting (lost at boot):

1
2

ifconfig vtnet0 -rxcsum -txcsum -tso -lro
ifconfig vtnet1 -rxcsum -txcsum -tso -lro

On OPNsense: Interfaces → Settings → Hardware CRC → Disable hardware checksum offload, and the same reboot.

Symptoms

The VM boots, the interfaces are UP, LAN DHCP hands out addresses, and still:

• Hosts behind the firewall cannot reach the Internet, or connections stall halfway (ping passes, TCP hangs).
• From the virtualization host itself or from other VMs on the same host nothing protected by pfSense is reachable, not even the GUI.
• Switching the VM’s NIC to e1000 fixes it on the spot, which confirms the diagnosis.

Why it happens

FreeBSD’s vtnet driver, with checksum offload enabled, hands the network stack packets whose checksum never got computed: between VMs on the same host, and between the host and the VM, traffic never crosses a physical NIC that would do it. FreeBSD sees invalid checksums and drops them (FreeBSD bug 165059). Netgate documents it under VirtIO Driver Support.

pfSense tries to tick the option only when it detects vtnet interfaces at install time. If the VirtIO NIC was added later, if you restored the config.xml from a physical firewall, or if you migrated the VM from another hypervisor with a different NIC type, the option stays off.

Procedure

1. System → Advanced → Networking, Network Interfaces section:

   • Disable hardware checksum offload: tick it.
   • Disable hardware TCP segmentation offload and Disable hardware large receive offload: already ticked by default; leave them.

2. Save.

3. Reboot from Diagnostics → Reboot. Without this step nothing changes on vtnet.

4. Check:

   1	ifconfig vtnet0 | grep options

   Neither RXCSUM nor TXCSUM (nor TSO4, LRO) should show up.

If it is still the same

• All of the VM’s NICs must be the same kind. A vtnet with offload and an e1000 behave differently; check every ifconfig.
• Offload on the host. Netgate notes that sometimes checksums and TSO must also be turned off on the hypervisor. On Proxmox/KVM, on the VM’s tap interface: ethtool -K tap100i0 tx off (the number is the VMID and i0 the NIC). Rarely needed; try it last.
• Plan B: e1000 NIC model on the VM. Less throughput than VirtIO without offload, but none of this bug.

Traps

• The reboot is not optional and the GUI does not ask for it. It is the number one cause of “I ticked it and it still does not work”.
• It is not a rules problem. With offload on, packets are dropped before reaching pf; the firewall log shows nothing.
• e1000 on OPNsense too as plan B; the equivalent setting lives under Interfaces → Settings.
• Multiqueue (queues=N on Proxmox) works fine with vtnet once offload is off; do not mistake it for the cause.