Show Posts
1
20.1 Legacy Series / Re: Reply-to on WAN by default is bogus
« on: June 03, 2020, 08:09:00 pm »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.