Reply-to on WAN by default is bogus

[oddjarle]

Ad, you are right it is not 802.3. It is RFC1122 (Requirements for Internet Hosts -- Communication Layers
). Specifically in section 3.3.1.1.

https://tools.ietf.org/html/rfc1122#page-47

My interpretation is that OPNsense's implementation of the "reply-to" feature appears to be overriding the local/remote decision as described in rfc1122 section 3.3.1.1.

I've been trying to solve something that I believe is the same or similar issue that ctminime describes.

What I am experiencing is that originating traffic (90.90.90.90) from the Internet is passed through a NAT port foward rule that translates the destination IP from the public IP of OPNsense # 1 (100.100.100.100) to a private IP of an internal server (172.20.20.20).

This traffic is then passed through an OpenVPN tunnel to another OPNsense firewall also connected to the Internet  (200.200.200.200). The traffic is then routed to the server LAN on the second OPNsense instance and arrives at the server (172.20.20.20). The server responds with the destination of the originating public IP (90.90.90.90), but the second OPNsense instance insists on replying out it's default gateway (200.200.200.1) instead of sending it back through the OpenVPN tunnel to the first OPNsense instance. The packet is dropped at the WAN interface since that traffic is not allowed by default.

If I add a firewall rule at OPNsense # 2 (200.200.200.200) for the server interface to send all traffic to a different gateway, the OpenVPN tunnel, all outgoing traffic from the internal server is sent correctly out via OpenVPN and out at OPNsense # 1's WAN interface as it should. Outgoing traffic from the internal server works fine.

However incoming traffic via OPNsense # 1 (100.100.100.100) going through the OpenVPN tunnel still wants to take it's return path via OPNsense # 2's (200.200.200.200) default gateway and interface.

Adding a firewall rule on OPNsense # 2 to allow the traffic results in that the traffic is then passed back through OpenVPN, but destination translated with OPNsense # 2's IP-address. The result is of course that the traffic is discarded at the Internet client side as the sender address doesn't match any outgoing states.

No matter what I try I cannot make OPNsense not insist on sending the traffic out OPNsense # 2's WAN, perform an outgoing NAT and pass the packet back through the tunnel. I believe it should be passed back through the tunnel unaltered and not via the WAN interface before sending it back via the tunnel.

Client (90.90.90.90) <---> (100.100.100.100) OPNsense # 1 (10.20.30.1 tunnel IP) <---->  (10.20.30.2 tunnel IP) OPNsense # 2 (172.20.20.1) <---> (172.20.20.20) Server

ISP (200.200.200.1) <---> (200.200.200.200) OPNsense # 2 (172.20.20.1) <---> (172.20.20.20) Server



OPNsense # 1

WAN : 100.100.100.100 /24 gateway 100.100.100.1
LAN : 192.168.100.1 /24
OpenVPN-server listening on WAN (OpenVPN tunnel IP 10.20.30.1)

Allow anything in/out on OpenVPN interface
Allow udp/53 in on WAN
NAT udp/53 in on WAN to 172.20.20.20


OPNsense # 2

WAN : 200.200.200.200 /24 gateway 200.200.200.1
LAN : 192.168.200.1 /24
SERVERS: 172.20.20.1 /24
OpenVPN-client with 100.100.100.100 (OpenVPN tunnel IP 10.20.30.2)

Allow anything in/out on OpenVPN interface
Allow anything in/out on SERVERS interface


Logs show in order from oldest to newest entries:

OPNsense # 1 firewall log


pass WAN         <   90.90.90.90:60872  172.20.20.20:53   udp   Allow DNS
pass OPENVPN  <   90.90.90.90:60872  172.20.20.20:53   udp   let out anything from firewall host itself


OPNsense # 2 firewall log


pass OPENVPN     >   90.90.90.90:11595     172.20.20.20:53           udp   Allow DNS
pass SERVERS     <   90.90.90.90:11595     172.20.20.20:53           udp   let out anything from firewall host itself
block INTERNET   >   172.20.20.20:53        192.168.1.100:11595    udp    Default deny rule
block INTERNET   >   172.20.20.20:53        192.168.1.100:11595    udp    Default deny rule


Adding the following rule at OPNsense # 2 allows return traffic, but with wrong source IP:

Interface: INTERNET
pass   IPv4   172.20.20.0/24   any port   to   any destination   and   any port    GATEWAY 10.20.30.1   any time


OPNsens # 1 new firewall log


pass   INTERNET   > 90.90.90.90:25537    172.20.20.20:53               udp Allow DNS
pass   OPENVPN    < 90.90.90.90:25537    172.20.20.20:53               udp let out anything from firewall host itself
pass   OPENVPN    > 172.20.20.20:53       200.200.200.200:25537     udp


Note that the last entry has a destination of 200.200.200.200 (firewall 2 WAN IP) instead of 90.90.90.90 (client public IP).

I've tried adding a NO NAT rule in many shapes and forms on OPNsense # 2's INTERNET interface with no change in the results.

Coming across this "route to" thread I tried to disable and enable that on OPNsense # 2 as well. No change.

I don't have multi-WAN, and my Multi-WAN settings are:

• Disabled "Sticky connections"
• Disabled "Shared forwarding"
• Enabled "Disable force gateway" (tried disabling it too)
• Enabled "Disable reply-to" (tried disabling it too)

OPNsense # 2's WAN is usually DHCP assigned, but I tried to set a static IP on it instead and a static default route instead of the DHCP-supplied default route. No changes.

Is it impossible to override that the traffic returning from the SERVERS network has to exit the INTERNET WAN interface, before returning via the OpenVPN tunnel?

Enabling NAT on OPNsense # 1s traffic using 10.20.30.2 as the source translated IP, before passing it through the OpenVPN-tunnel, makes everything work from 90.90.90.90.

[alh]

I have a similar issue as @oddjarle.

Is there any solution to this problem?

[mimugmail]

Just dont use an upstream gateway in Interface : WAN

[alh]

I believe oddjarle's problem is different than the OP. The reply simply travels via default route. removing the gateway from wan won't change that, will it? Maybe continue here:

https://forum.opnsense.org/index.php?topic=20843.0