OPNsense Forum
Archive => 16.1 Legacy Series => Topic started by: peppermint on May 02, 2016, 10:10:44 am
-
Hello,
coming from Pfsense, which runs 2,5 years on Windows 8/10 HyperV with no problems, I installed Opnsense 16.1. First I was not able to read the pfsense config, but after one hour work with paste and copy basic Opnsense worked for me.
But I didn't read this forum before and run into the portforwarding error of Freebsd 10.2 on HyperV which costs me another two hours.
Is the only solution going back to 15.x and is the config file of 16.1 working there?
I prefer to go to 16.7 beta.
Is it based on Freebsd 10.3 and is portforwarding error solved?
Thank you for your help.
-
Hi there,
Can you describe the error for us? Or provide the link? If this is an upstream FreeBSD issue that was fixed in 10.3 then letting us know about it would probably help getting it fixed for an upcoming 16.1.x release and I can have a test kernel out in matter of hours...
Does the error happen when you *not* use the pfSense config parts for NAT setup? It's highly discouraged to use incompatible config.xml files from anything > 2.1.
Cheers,
Franco
-
Furthermore, you're having this problem with OPNsense 16.1.12?
-
Franco, thank you for the quick answer.
NAT from WAN to LAN is not working, which is mentioned in the forum.
What I have done:
Last weekend I closed my virtual pfsense (the last 2.2.x version) and installed the newest opnsense iso in a new hyper-v session.
The test loading the configuration from pfsense failed, so I installed opensense again and manually configured in the gui my network (not using the pfsense config file). Opensense did some updates and all seems running well, except when I tried to reach my network from external (NAT from WAN to LAN is not working).
>Furthermore, you're having this problem with OPNsense 16.1.12?
At the moment I am working from external, so can't see the network, but it was the update from last saturday.
-
The mishap of Hyper-V on FreeBSD 10.2 was actually fixed all the way back in 16.1.2 and was related to LAN not going out into WAN (forwarding of non-local traffic).
The latest image available is 16.1.8 and the current firmware is even newer. The only way you can hit the previous issue is by installing the actual 16.1 image, not the newer one 16.1.8. And even for firmware upgrades it's impossible to upgrade into said HyperV bug coming from 15.7 as it will update to 15.7.25, then directly to 16.1.12... :)
I just want to make sure we're not talking about different things and look into the wrong direction. So I'll need:
o The current OPNsense version, best copied from the system information widget (all lines).
o The exact NAT problem, e.g. what NAT type, possibly a brief description of the network layout.
Cheers,
Franco
-
Thank you Franco,
now back home again, I started new step by step (installed a new hyper-v machine etc.) and it worked!
Could it be, that the "_" sign in aliases is not working?
But now I have a small other problem:
the windows 10 clients get no peer from NTP, if I start the windows time sync, but after a while it seems, that they get the time, may be not from opnsense. The time integration service in hyper-v is switched off.
Thank you for the great product!!
-
Hi peppermint,
Yay, glad to hear. :)
For the NTP, I remember this:
https://github.com/opnsense/core/issues/518
Custom settings may be necessary in order for your peers to be able to sync against the NTP provided by OPNsense.
Cheers,
Franco
-
Hi Franco,
I tried the NTP-settings, but nothing helped, the message of the windows clients ist still no peer or not reachable.
The opnsense console shows some messages, see enclosed pic.
Maybe there is something wrong?
-
It looks like you're running IPS mode, these latter messages regarding netmap are normal as it can be a bit spammy at times.
The early messages are a bit worrisome, because it says that Hyper-V is still forcing a time sync to the VM. Maybe it's better to run an NTP server elsewhere and disable it completely on OPNsense (just remove all remote time servers).
Otherwise Hyper-V must be coerced into not doing any more time syncs for the VM, but I'm no expert on that part and have had customer deployments at my day job that would never stop forcing time on the VM, eventually making NTP give up on syncing time when the drift was too big.
-
Thank you,
you mean the calcru messages? I had them on pfsense too, but they disappeared after the first time sync.
I rebooted opnsense two times and then I tried :
w32tm /resync /nowait
as admin on the windows host.
And now it worked.
-
Oh well ok. :)