OPNsense Forum
English Forums => General Discussion => Topic started by: a2zit on December 10, 2019, 06:22:27 pm
-
I installed Opnsene as VM on VirtualBox with 2 NICs (Bridged As WAN, Internal Network As LAN). (attachment: firewall-nics)
LAN (em1) -> v4:192.168.1.1/24
WAN (em0) -> v4/DHCP4: 192.168.3.200/24
I have another windows 10 VM with 1 NIC ( Internal Network As LAN). LAN : 192.168.1.100. I use it to manage Opnsene VM through the LAN NIC
I done the following to the firewall:
1) Added a rule to allow anything coming from WAN to firewall (Attachment: Firewall-rules)
2) Enabled SSH, WEBGUI on the firewall to be accessible from both LAN and WAN
3) Unblocked both private and bogon networks
I am trying to access OPnsene from my computer hosting VM (192.168.3.0/24). I can ping firewall from my computer (ICMP works), BUT both SSH and Web GUI are not working. on firewall live log it show no block(attachment: firewall-log)
I tired everything and cannot tell what is wrong, I tried same setup with PFsense and it work with no issue
Please advice ! :'(
-
Note: if i disable the OPNsense Firewall ( pfctl -d ) i can access both SSH and WebGUI with now issues
Any advice why i am having this issues !
-
Note: if i disable the OPNsense Firewall ( pfctl -d ) i can access both SSH and WebGUI with now issues
Any advice why i am having this issues !
for anyone whom might have same issue, I found a similar case in below forums and they resolve the issue by
disable reply-to globally for Firewall (Firewall: Settings: Advanced).
Not sure if that's the correct way or not but it works !
https://forum.opnsense.org/index.php?topic=8833.0
https://forum.opnsense.org/index.php?topic=8841.0
-
Could it be possible that you have the block private network check box active on your WAN interface?
-
i have block private network disabled on WAN ans still having same issue
-
Note: if i disable the OPNsense Firewall ( pfctl -d ) i can access both SSH and WebGUI with now issues
Any advice why i am having this issues !
for anyone whom might have same issue, I found a similar case in below forums and they resolve the issue by
disable reply-to globally for Firewall (Firewall: Settings: Advanced).
Not sure if that's the correct way or not but it works !
https://forum.opnsense.org/index.php?topic=8833.0
https://forum.opnsense.org/index.php?topic=8841.0
I can confirm the disabling of reply-to is indeed required for a WAN rule, however it's best to disable it in the actual rule and not globally.
There's not much detail in the aforementioned threads so more digging will be required to understand the logic, however keep in mind that setting has been made the default for a reason, and disabling it selectively instead of globally is the better option.
-
It looks like you are performing double nat on the network in question, so I am thinking what has happened is the request is entering a different interface than it exits when it is fulfilled. This would likely happen with any services sharing the same address range as the wan link, excluding the gateway device set in opnsense. Disabling the global rule would then in effect only be more insecure than a per rule basis that you opted to perform if any of the devices on the WAN range became untrusted or compromised. Since you (probably) have an additional firewall performing nat as the gateway for these devices it is unlikely to be a concern. I would only imagine this global setting to be an issue if you need to communicate with all of the devices on the WAN range regularly with the OPNsense vm which I imagine would not be common. An alternative to not having to set any special rules at all would be to add a second IP address in the lan range to the host running the VM and accessing the webgui over the LAN interface. I have a similar setup at home with double NAT.
P
-
No double NAT, client machine and WAN Interface IP are in the same /24 network
-
No double NAT, client machine and WAN Interface IP are in the same /24 network
How does your OPNsense vm get internet access then if there is no upstream router with a public ip address and (presumably) providing NAT for clients behind it? 192.168.3.x is not a publicly accessible network.
-
Hi allebone,
You appear to get distracted by your own assumptions, which aren't on topic here and wrong in this case. :)
The easiest way to reproduce it is as follows:
1) In your preferred virtual environment have a linux live and a fresh OPNsense install with the WAN on the same network as the linux live. (OPNsense LAN is utterly irrelevant for this exercise and the interface can be missing altogether)
2) OPNsense console, Option 8, pfctl -d
3) With the firewall temporarily disabled you'll get to https://WAN_IP and start configuring it
4) On Rules - Wan add a Pass TCP rule Source Linux_IP dest WAN_Address:443 and disable reply-to (it's hidden in the Advanced section of the rule)
5) Save the rule, the FW will be enabled again and you'll be able to configure it on the WAN
6) Don't do any of the above over the Internet :)
-
Apologies. As a test did you actually remove the LAN interface so it only had one interface when testing this issue?
-
Same principle applies everywhere, virtual environment or not, and yes, you can have your test VM with a single NIC that is assigned as WAN.
-
Ok will test again on Monday with the interface removed and see that happens :)
-
Again, the presence of a LAN/VLANs are irrelevant here. :)
-
I have just tested this and could not reproduce the issue. I used virtualbox which was what the OP used. I added 2 bridged adapters and made LAN an address on the 193.168.3.x range. I made WAN an address on the 192.168.2.x range. I installed leaving as much default as possible (disable reply to is not checked globally nor in the firewall rule).
I enabled 2 rules on the WAN. ICMP from any to any so I could ping it and check it was up, and a port 80 rule as it was configured for http.
I made sure I could access the web gui on both the lan and the wan ranges from my host machine running the virtualbox vm. I then reconfigured my host machines network ip to only have an IP on the WAN range. I could still access the web gui.
As everything was still working I then added a rule for https and changed the web gui to run over https. Again, everything worked.
As I was unable to recreate the issue, I am thinking something else must be different. Is there anything I might have overlooked? Its mostly an out the box install as I just installed it and didnt change much so not sure where to go from here to get it to be like what happened to you?
P
Edit: forgot to mention I obviously deselected block bogon and private networks on the WAN as my ip ranges I am testing with are private ranges.
-
You were using one NIC of everything, that's not what was discussed here.
To reproduce the issue put the two interfaces on the Internal Network in VBox, absent DHCP assign manually two IPs on the WAN and Linux VMs in the same network range.
-
Actually I set it up as per the screenshot in the OP, so it emulates the OPs description.
-
I just double checked what he said and verified my setup is similar to what was said here:
“installed Opnsene as VM on VirtualBox with 2 NICs (Bridged As WAN, Internal Network As LAN). (attachment: firewall-nics)
LAN (em1) -> v4:192.168.1.1/24
WAN (em0) -> v4/DHCP4: 192.168.3.200/24”
2 nics on host machine - check
Each nic seperately bridged - one nic bridged for lan and other nic bridged for wan to VM guest - check.
Screenshot of guest console is the same - check
He is trying to access firewall from machine hosting VM and had a problem. I test this and do not have the same problem.
“ I am trying to access OPnsene from my computer hosting VM ”
My setup is the same yet issue is not present.
P
-
Bridging is an entirely different conversation that I haven't addressed.
There's a false assumption in the original thread which implies a ping reply "must be" originating from a firewall that happens to be running there, yet there's no way of knowing for sure it is not the TCP/IP stack on the host that answers the ping.
Everything else I wrote in this thread still stands, yet it has nothing to do with bridged NICs whatsoever.
-
I setup a test as per the OP who started the post with a problem. If you are talking about something other than the OP’s original setup then I wouldnt be able to follow that unless you post how you want me to perform the test to generate the issue as per how you have it setup. If you want me to change some settings I would be happy to do so and test again with different settings, it is no problem at all.
-P