Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - gnsinfo

#1
Quote from: OPNenthu on March 22, 2026, 06:07:44 PM@gnsinfo if you have the time, a couple questions to help us with the other cases where this isn't working:

- If you disable the 'Disable reply-to' global option (double negatives are very confusing) and then revert the rule back to its original configuration, does it still work?

- Are you using Firewall->Rules or Firewall->Rules [new]?

Thanks for your concern.
I'm using Firewall-> Rules.
Anyway, I'm now using the OPNsense very well.
No problem I have.
Thanks again all.
#2
Quote from: OPNenthu on March 21, 2026, 11:26:26 PM
Quote from: gnsinfo on March 21, 2026, 04:33:53 PM- How can I ensure that traffic entering via a specific WAN interface is always forced to exit through that same interface's gateway,

This has been a hot question lately.  The 'reply-to' option is supposed to handle this, or so I think, but you are not the only one seeing that the default route is always chosen for reply traffic.

https://forum.opnsense.org/index.php?topic=50882.0
https://github.com/opnsense/core/issues/9702

OPNsense 26.1 has a new flow in the setup Wizard which asks whether or not to optimize the system for Multi-WAN (source-based policy routing).  I did a comparison of two config files with and without this setting and the difference was only two things.  In the Multi-WAN optimized setup, the global firewall options 'Disable force gateway' and 'Disable reply-to' were both disabled (unchecked).  They were the exact opposite in the setup for single gateway, which favors the default system route.

There appears to be some mysterious X factor affecting Multi-WAN that we haven't discovered yet.

(Or, it's above my skillset and no one is patient enough to point it out.)


It works!!!
I can't find Disable reply-to, anyway, in the Reply-to option, I selected WAN interface.
After that, it is no longer blocked email traffic and etc.
Thanks for your effort. (",)(__)...

Have good times all in all.
#3
Greetings,
For the good communication, I am using AI power.TT

I am seeking advice on a routing issue in a Multi-WAN environment using a Gateway Group on OPNsense.

Topology & Environment:
- Setup: Dual WAN (SKT and SKB) configured in a Gateway Group (Load Balancing).
- Interface: SKT (WAN_GW, Priority 40) / SKB (OPNsenseSKB, Priority 50).
- Service: Caddy/Mail server running on OPNsense host (or behind NAT).
- Topology Link: [https://cloud.gnsinfo.mooo.com/s/QJagCtWLeQqVKRF]

The Issue:
1.  A packet arrives at the SKT WAN interface and is processed (NAT/Port Forward).
2.  The server/service generates a return packet (Reply).
3.  Instead of exiting through the same interface (SKT), OPNsense routes this return packet to the other gateway (SKB).
4.  The other gateway (SKB) drops the packet due to an invalid state or IP mismatch.

What I've observed:
- The system seems to favor the default gateway in the routing table even for inbound connection replies.
- The connection times out for external users attempting to access the service via SKT.

Question:
- How can I ensure that traffic entering via a specific WAN interface is always forced to exit through that same interface's gateway,
- especially when a Gateway Group is active for LAN traffic?
- I've looked into `Reply-to` settings but would like to know the best practice for this specific Multi-WAN scenario.

Thank you in advance for your help!
#4
Quote from: meyergru on March 19, 2026, 09:02:30 PMToo little information given here. Sounds like a router-behind-router setup. See this, especially points 1, 4 and 16.

And BTW: There is no such thing as "lo0 routing".



Thanks, solved.
I add Firewall rule to LAN.
I can ping 192.168.55.127.^^*
#5
Thanks for all the reply.
To archive good communication, I used AI skills.


I finally found why I couldn't ping **192.168.55.127** and **.254** from my LAN client (**192.168.55.51**).

The issue is related to the **Gateway Group** configuration for Multi-WAN redundancy.
When I specify the Gateway Group in the "Gateway" field of the LAN firewall rule, OPNsense stops responding to ICMP and DNS queries directed to itself.

**Diagnostic Findings:**

1. According to the firewall logs, traffic from **.51** to **.127** is being **NATed on the WAN interface**.
   
2. It seems that because of Policy-Based Routing (PBR), the firewall forces local traffic out through the WAN gateway instead of routing it locally.
   
3. I switched Outbound NAT from "Automatic" to "Hybrid" and added a "No NAT" rule for LAN-to-LAN traffic. Now the traffic passes the firewall, but there is still **no reply**.
   

**My Question:**

Where is my traffic going, and why isn't the firewall intercepting traffic destined for its own interface when a Gateway Group is active?

How can I properly use Gateway Load Balancing/Failover while ensuring that traffic destined for the LAN Gateway or Virtual IPs (VIPs) is excluded from the Policy-Based Routing?

Thanks for all of your effort.
Good days all in all.
#6
Greeting.
I'm newbie on opnsense.
Which is my problem; Routing, NAT, Rules?

opnsense version : 26.1.4

I configured below;
- Interface : Virutal IP 192.168.55.127, master .254, backup .1
- Gateway : Group WAN_GW1, WAN_GW2
- High Availability : Service sync Caddy, Unbound DNS
- Firewall : Destination NAT, Outbound NAT, Reflection for destination NAT, Sticky Connection
- VPN : OpenVPN
- Service : Caddy, Kea DHCP, Unbound DNS, Zabbix Agent

Now I have problem is I can't ping 192.168.55.127 and 192.168.55.254.
And I can't query to Unbound DNS.
But I can ping 1.1.1.1, and use DNS.
And DNAT function are working properly.

How to get icmp reply from opnsense and how to use dns?
On this problem I checked live log, and there is no block.
To avoid NAT, I configured Hybrid outbound NAT and add rule.
Lastly, I adjusted lo0 routing.
All of my effort to solve it, the opnsense doesn't accept me.

Please show me the way to use opnsense properly.
Thanks for your time.

Good days all in all.