New pull request was created.  This time I created a branch to work on and then merged that back to my personal master before submitting the pull request.  That feels like the right way to do it.

EDIT: I found another article that explained what I should have done with my previous repo.  If I fall into that issue again I will try this route…

git checkout -b {my_pull_request_feature_branch} upstream/master
git cherry-pick {sha1_of_first_commit_for_feature_X} [sha1_of_another_commit_for_feature_X] …
git push origin {my_pull_request_feature_branch}

from: http://stackoverflow.com/questions/16984169/github-how-to-submit-individual-pull-request-in-case-of-multiple-commits

If you switch architectures it won't automatically reboot in some cases, so what you hit is expected.

It does seem like it was just the current snapshot at the time. I'm running the latest snapshot and it seems to be acting normal again. Should it start acting up again I'll report back.

@susamlicubuk:

pfSense on hyper-v ethernet problem (Windows hyper-v server 2008,2008r2,2012,2012r2)
solution.
1- add legacy network adapter

You don't need to use legacy adapters and that startup script with version 2.2 if you use the synthetic network adapters. Or you can install the drivers on 2.1 for the faster adapter.

@stephenw10:

0.1s is more like it.  :)
I guess you're using a SATA interface, the transfer speed is a lot higher.

Steve

Sata interface with a Marvel converter to Compact Flash.

Yup, should have checked redmine.  ::)
Thanks.

Steve

No SSH, GUI or Console? Probably not.

If you have any one of the three you could run an update. SSH or console use option 13, then option 1, try 'auto' if that fails try the auto URL but with http instead of https.

Otherwise you'll need to get a new snap and then reinstall/reload the OS.

It's now fixed. Thanks!

jimp,

Thanks for that. My brain was getting confused with the terminology rather than looking at what is happening when these settings are set and applying the correct perspective. I have confirmed that this works.

Am I correct in my assumption that in a 1:1 rule the ip or subnet entered in the "Destination" section is really source or destination depending on what end initiates the connection? Therefore if I only want this rule to apply when traffic is to or from 172.21.0.0/24, I would enter 172.21.0.0/24 in the "Destination" section, correct.

Now is there a way to create a directional NAT to do the same without being limited to specific ports and protocols?

Thanks,

Rhongomiant

Thanks. Pretty much as I thought it was likely a PEBCAK issue. I'll try a new update over the weekend and see what falls out the other side.

Apart from this hiccup for me, considering the alpha status, it's been rock solid on Hyper-V…

It seems to be working fine for me.  I have changed a lot of things in the gui and haven't seen any issues with it or php-fpm locking up either.  Thanks!  That certianly makes running the Alpha easier.

EDIT: removed sshd info.  That is handled in another thread and is working in the current release now from 7am this morning.

It's there in the OS, but we haven't fixed the GUI's input validation to account for it, as it may need other adjustments along the way. As far as I know it's still on the todo list but hasn't made its way around to the spotlight.

I found the issue and pushed a fix few minutes ago. Please wait the new snapshot

Now that's done. Running the snapshot from today.

However it seems that it have broken some other stuff like webinterface etc so can't access it anymore from work!

// Markus