OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: peanut on April 05, 2019, 11:42:11 am
-
Hello everyone,
I have a strange problem and I'm not sure where the problem lies.
I'm using OPNsense in front of one of my servers. I have a /27 subnet on the WAN part. The OPNsense box uses 4 of those adresses (1 for the box, 3 Virtual IPs). There are two other firewalls in this subnet which use the other IPs.
I made sure none of the WAN-IPS are assigned multiple times, etc.
I set up NAT on the OPNsense box and it works nicely if I connect from the LAN or from the WAN. With one exception: If I connect from one of the other firewalls, it won't work.
I did a lot of debugging and I think I found the cause of the problem:
Packets from the firewall are directly send to the OPNsense box (since its the same subnet, there is no reason to sent it to the router/gateway first).
Packets from the OPNsense box to the firewall are sent to the gateway/router. The gateway/router routes them into the internet instead of reflecting them back into the WAN subnet. Since the OPNsense box and the firewall are in the same subnet, there is no need to route the packets through the gateway...
Is there a way to change this behaviour in OPNsense? (I can't reconfigure my router/gateway... and the other firewalls work without any problems).
Do you need more information about my configuration?
-
I just realised I'm using 19.7 (because of the wireguard support). Can a moderatore move my thread to the other board or should I repost it there?
[edit] I did another test, this also happens with 19.1 :-/
-
I'm having a similar problem and I'm similarly stumped. No virtual IPs in our case, but on the WAN side, we have a typical "block of 8" assigned by our ISP:
Usable 173.x.x.33 through .37, .38 is the WAN gateway.
.33 is our Web server external address - OPNsense lives here
.34 is for our FTP server (on a completely different firewall -- ClearOS)
.35 is for office Internet access (ClearOS)
.36 is for internal business (ClearOS)
.37 is reserved
On the LAN side, we have a standard 192.168.x.x subnet, port forwarding to a single host (a Web server).
From any WAN IP address *except* for one of the above, we can get into the Web server. From my house, from my phone, people in Chicago, people in NY. Everyone can get in. (This server is on Comcast in Denver.)
From inside the office in Denver, we cannot get onto the Web server. Anyone inside the office will be assigned via DHCP an IP in a 10.x.x.x subnet, using .35 as their external (WAN) address. If they try to go to our Website there in the office, either by host name or directly via IP address, it times out. Web or SSH, neither one works. The firewall is obviously blocking 173.x.x.35.
Any ideas? We've pored over the configuration a half dozen times and don't see anything obvious.
-
I'm posting this here in case anyone else should come across this. Our Webserver originally faced the Internet directly on the 173.x.x.33 address. The default gateway was set to .38 (of course). Mask was /29.
To speed up the move, we set up the OPNsense firewall, ready to go. On the Webserver, we tasked one of the other network interfaces to the 192.168.x.x network, to work on OPN's LAN side. We unplugged the old cable and slipped the OPNsense box in line. So far, so good ...
We of course set up the new default gateway in the Webserver to point to the OPNsense box. What we forgot to do was to take down (deactivate) the old NIC that had the 173.x.x.x config. So ... from inside the office, on a 173.x.x.x network, OPNsense was working fine. The WEBSERVER was then sending its replies through what it thought was the correct (old) interface.
Kill the interface on the WEB server took care of the problem. *Whimper.*
(This is one of those things that makes you slap yourself once you find it.)
The moral of this story: stating the obvious, but routing is routing. Always check everything before assuming that your new shiny firewall might be the problem ...