I have 4 vlans, only 2 of which are in question in this situation. I have a guest vlan (vlan 200) and a server vlan (vlan 306).
By nature I want to block guest vlan access to the server vlan. However, there are websites hosted on the server vlan that users of the guest vlan may need access to. The websites are port forwarded and accessible via the wan. However, when I reject access from the guest vlan to server vlan, users on guest vlan cannot access the websites. This doesnt make sense to me because the website is accessible via the wan and dns records are on a public dns server. The traffic to access the websites shouldnt be going through the vlans, but through the wan. This is making me pull my hair out.
You have to pass traffic to the private addresses and ports you want passed before blocking access to the server VLAN on the firewall rules on the GUEST interface.
So if your web server is 192.168.1.100 ports 80 and 443 you would do something like this on the GUEST interface:
As a trailer I would also say it would be better to pass traffic to "this firewall" that they need access to (like DNS) then block everything else to "this firewall" instead of just blocking the management ports.
That way things can change (like changing the webgui port) and you are still secure without having to remember to change that alias.
As a pretty advanced admin, I must say, that is a pretty simple fix and almost seemed too obvious so I didn’t bother trying it before. Oops.
In regards to blocking traffic to the firewall, clients only need it for captive portal- not even dns. So I’ll reject all traffic to if except for the portal
It doesnt work for me using a single ip of the host. Especially because unifi uses 8443, I would like to allow 8443 just to unifi instead of the entire vlan but it still rejects it using aliases?
If it works with SERVER Net and not specific addresses I would posit you are using the wrong addresses.
You might want to post the actual port forwards and firewall rules. Should only be necessary to post the GUEST rules.
I added an alias for "exchange". It is only resolvable by internal dns. Pfsense is pointed to the internal dns servers.
exchg1.ds.smith114.com is resolvable to the 10.3.20.x local address by ALL machines on the network when no restricting firewall rules are present.
Pfsense cannot resolve that address for some reason. It is pointed to the dns servers holding the record for exchg1
I assume the firewall is using itself as dns before the other servers. This is probably the issue but I am not sure how to fix it.
I also assume I can enter the ip of the server instead of the local fqdn, but I prefer to do it with dns (if it will work)
I realise that since pfSense is based on FreeBSD 8.1 new code from 8.2 or 9 would only be included if it was specifically ported. However what about bug fixes from 8 stable?
Looking through the pfSense source code (https://github.com/bsdperimeter/pfsense) it's obvious that not all of the FreeBSD code is there. Does that mean it gets pulled from the FreeBSD repo at build time?
The new code was merged with both 8 stable and 7 stable but does that mean it will find it's way into pfSense automatically? ???
There is no way to run something like freebsd-update to follow build revisions as there is with a full install of FreeBSD. PFSense does not do a compile at install time and all the packages are prebuilt.
I believe that when it reaches release status it is frozen and the incremental releases contain any updates the team feel are needed. If all the FreeBSD code was pulled down at build it would effectively be a FreeBSD box which sort of defeats the point.
Right but presumably it is compiled at build time. I.e. the snapshot server is compiling the pfSense source each day to generate to current build. Since the github repo doesn't appear to have all the code necessary to do that, just the additional pfSense stuff and patches, some of the code must be pulled from FreeBSD. No?
Now it may be that code is pulled from a source that is frozen in which case no updates would get through.
I take it that the answer to my original question is; no, the driver patches will not automatically get into pfSense?
Perhaps someone would be kind enough to outline what steps I might take to generate a new kernel module.
So I update the source code and make a newer version. The new code has been backported to 8.2, will it run on 8.1?
Hmm, well this post looks promising. However there seem to be a few typos in there which are killing me.
It didn't work for me as is but with a few tweaks it compiled. However I think I've probably ended up with something compiled for 8.2. We'll see…
What were you most recently trying to compile: msk from 8.2? msk from head? What is the revision information in the file? Have you applied your own patches? How did you get your file(s)?
I don't immediately have access to a FreeBSD system (maybe tomorrow) to investigate the undefined symbols but from the look of them I would expect them to have been standard definitions for some time. Maybe the definition location moved in the 8.1 to 8.2 transition.
I haven't applied any patches. The source code was checked out from /stable/8/ using SVN two days ago.
I have attempted to replicate the process used in the linked post however I now realise that a number of those steps are specific to that driver.
I have created a new folder holding the msk code as well as some other files to build in. Mostly I assume that was done so as not to corrupt the source tree of either the 8.1 or stable/8/ code.
If you would rather I delete everything and start again to avoid any confusion I'm more than happy to do that. ;)
Edit: As a test I attempted to replicate the procedure outlined in the link FreeNAS post exactly (creating a vte module) but resulted in a similar list of errors. I believe it's likely I'm modifying the Makefile incorrectly. Or things have changed dramatically since January.
IFM_ETH_RXPAUSE, IFM_ETH_TXPAUSE, BMSR_DEFCAPMASK, MII_OFFSET_ANY and MII_FORCEPAUSE are not defined in the FreeBSD 8.1 source tree. (I didn't check the other undefined symbols reported.) IFM_ETH_RXPAUSE and IFM_ETH_TX_PAUSE are now defined in sys/net/if_media.h
From the comments in the revision history it appear some driver specific code for handling PHYs was made more generic: kernel interfaces changed in the 8.1 to 8.2 transition.
I expect you will have to hand edit the change you want back to the 8.1 release code. In the CVS web interface revision 1.64.2.20.2.1 was the revision for 8.1 release, 1.64.2.27 is the current head of the 8.x branch and seems to have invisible changes (e.g. spaces to tabs) from 1.64.2.26. Revision 1.64.2.23 looks to have the changes for the generic PHY support. Its possible subsequent changes rely on new (to 8.2) kernel interfaces.
It's interesting then that I couldn't get the VTE driver to compile, replicating the steps on the FreeNAS forum, since that post was in Jan 2011 and the 8.2 release was in Dec 2010. :-
In that post it was also necessary to include the relevant PHY code. That would certainly tie in with a mii re-write.
I'm still unsure about the Makefile. I seem to be unable to find a good resource describing the function of the different lines. Clearly if more code has to be included/compiled/built then the Makefile needs to be modified in order to automate that process.
They shouldn't. You are extrapolating too much from the template you are using. The template is for building a module from sources of a completely new driver that didn't exist in the FreeBSD source tree. You are wanting to build an driver (msk) that already exists in the FreeBSD src tree.
rdcphy.c now exists in the FreeBSD source tree in src/sys/dev/mii. A quick examination shows it claims to be support code for the RDC R6040 10/100 phy. As best I know that phy has nothing to do with msk so don't complicate your challenge by adding stuff you don't need.
Yes, I realise that rdcphy.c is nothing to do with the msk driver (which appears to use e1000phy) I was just using that as an example.
I expected to be able to compile the if_vte.ko module as per those instructions since the code change between now and Jan doesn't seem so dramatic. Since I cannot compile that then either I doing it wrong (very likely) or the code has changed much more than I realise. Or it never worked in the first place and that poster was making the whole thing up! The only part of those instructions that confused me was modifying the Makefile.
It seems likely that some other files will need building as well and adding them to the Makefile seems like the right way to do it.
I appreciate all your help and patience with this. Clearly this is beyond my usual level of tinkering!
I expected to be able to compile the if_vte.ko module as per those instructions since the code change between now and Jan doesn't seem so dramatic.
A "simple" code change can hide considerable complexity. For example, a change in the name of a function called at first seems a simple change. However the "new name" function may exist in the "new" kernel but not the "old". The "new" function may call quite a number of other "new" functions. What appears at first to be a simple backport problem has now become a much more challenging backport problem.
Your compile of vte driver might have proceeded rather further if you had checked out its sources as of the date of the post rather than "now".
Reading through the threads for the various bug reports that went into the driver patch for msk it seems that in fact there are samples of code in many of them and a lot dating from around the time of 8.1 rel. I think, as you said, I need to find exactly which code change is relavent to my NIC and patch the 8.1 source manually.
There is also a possibility of updating the 'firmware' in the nic to remove the problem condition in the first place. I'm looking into it.
The new site annoys me. They start asking for spirit stones since ch 12. Even QI started after hundred of chapters. No idea if it'll unlock automatically like in QI when a day passed, or if we could earn free spirit stones. It's still too early to start with the payment though.
I just couldn't understand why the sect treated their disciple who got crippled in their mission this way. It's like telling everyone that once they are crippled, they're totally on their own with no compensation at all, while wanting to keep the member's loyalty. No sane person would want to make sacrifice for a sect like that.
The jade beauty is realistic (lol), I hope she won't play victim and get vindictive if she got crippled and her boyfriend abandoned her. Talk about double standard.
Haven't read it but 'elixir field' would be the herb garden he was supposed to protect but got destroyed....
I thought so at first but it's actually his dantian with different name that got destroyed, making him a waste who can no longer cultivate.
That's pretty silly then ,maybe that's how it came up on machine translation or something similar and translator confused it due to context. (just reading the synopsis on stories on that site feels even lower quality than Qidian translations, it's like xianxiaworld expanded or something).
Well I didn't have trouble reading it. Normally when reading mltl I get a massive headache in trying to understand the story, as well as the emotional content in it and the garbled grammars. So the story so far feels kinda like the beginning of martial world only time will tell how the rest of the story will turn out.
Seriously, QI usually locks their chapters after 200+, ad it's still way better than this new site (a knock-off of Chinese product).
BTW, I peaked at the RAW. The chapters posted on that QI clone are divided into half of the original. It's actually 1/2 chapter for every chapter posted on Novel Universe. This is quite despicable imho. So ch 1-2 on that site is ch 1 in RAW, ch 9-10 is ch 5 in RAW. The numbering and naming in "table of contents" is misleading us into thinking that we really read a fully translated chapter when it's actually 1/2 chapter.
Better than qi dian no you have just 3 sword and you wait one week for 7 chapter no everyone day chapter etc for me i prefer qi dian !!!!
That's pretty silly then ,maybe that's how it came up on machine translation or something similar and translator confused it